[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: patch labels in CG manual

From: James
Subject: Re: patch labels in CG manual
Date: Tue, 7 Jun 2016 14:04:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0


On 05/06/16 23:24, David Kastrup wrote:
Carl Sorensen <address@hidden> writes:


On 5/20/16 10:15 AM, "James" <address@hidden> wrote:
One thing to realise and I think people have forgotten is that the
Patchy-testing scripts (rather than Patchy-merge scripts) no longer work
as they were written to scrape the old Google tracker and don't work
with Allura.

So Patch testing is 100% manually done - i.e. lots of clicking and
typing commands - and that includes me having to download the raw *diff
file from Rietveld via my browser and then running the commands, albeit
serially, in a CMD window completely unscripted. Then making sure I
manually clean my out of tree build and the tree in its current state
after a patch test.
I certainly had forgotten this.  I'm amazed that you've continued this
long with manual patch application.  You're an all-star!

I will commit to helping get the Patchy-testing scripts working, so
this manual procedure is no longer needed, or is at least simplified.
Having had quite a bit of refactoring done in a number of issues this
weekend, I am pretty sure that James would appreciate a return of the
automated testing procedures, so that he can just go through visual
checks of a whole batch when he has time.

I feel kind of bad for the amount of involved issues but they are
basically all independently testable and I would want to avoid queueing
them as one bunch when they might have individual problems that are
masked when combined.

Yes we do need to run the tests on a per-issue basis and, if memory serves patchy-test could take an issue number as an argument or if you just ran it without and argument it did each 'new; issue, one at a time. I am sure the old code will tell you this.

The logs (or just the reg tests) were stored in their own-issue named temp dir so that I could leave them all running and come back to them later when I reviewed the reg test diff. As long as I didn't reboot, because by default the working dir was in /tmp which was useful mostly, but occasionally I'd forget and lose my diffs but it takes relatively small amounts of time to run a test (20-25 mins or so).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]