auto testing

[Martin Nowak]

On Sat, 17 Dec 2011 20:54:24 +0100, Brad Roberts <braddr at puremagic.com>  
wrote:

> On 12/17/2011 4:56 AM, Robert Clipsham wrote:
>> On 17/12/2011 06:40, Brad Roberts wrote:
>>> On 12/16/2011 1:29 PM, Brad Anderson wrote:
>>>> On Thu, Dec 15, 2011 at 6:43 PM, Brad  
>>>> Roberts<braddr at puremagic.com<mailto:braddr at puremagic.com>>  wrote:
>>>>
>>>>
>>>>      Left to do:
>>>>
>>>>       1) deploy changes to the tester hosts (it's on 2 already)
>>>
>>> done
>>>
>>>>       2) finish the ui
>>>
>>> very ugly but minimally functional:  
>>> http://d.puremagic.com/test-results/pulls.ghtml
>>>
>>>>       3) trigger pull rebuilds when trunk is updated
>>>
>>> partly implemented, but not being done yet
>>
>> Idea: I noticed most pull requests were failing when I looked at it,  
>> due to the main build failing - that's a lot of
>> wasted computing time. Perhaps it would be a good idea to refuse to  
>> test pulls if dmd HEAD isn't compiling? This would
>> be problematic for the 1/100 pull requests designed to fix this, but  
>> would save a lot of testing.
>>
>> An alternative method could be to test all of them, but if the pull  
>> request previously passed, then dmd HEAD broke, then
>> the pull broke, stop testing until dmd HEAD is fixed.
>>
>
> Yeah.  I know I need to do something in that space and just haven't  
> yet.  This whole thing is only a few evenings old
> and is just now starting to really work.  I'm still focused on making  
> sure it's grossly functional enough to be useful.
>  Optimizations and polish will wait a little longer.
>
> Thanks,
> Brad

Another optimization idea. Put pull request that fail to merge on an  
inactive
list, send a comment to github and wait until the submitter does something  
about them.

martin