Re: [PATCH v2] travis-ci: retry if Git for Windows CI returns HTTP error 502 or 503

From: Junio C Hamano <gitster@pobox.com>
Date: May 9, 2017, 23:50 UTC
Message-ID: <xmqqmvalzj1b.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1ADD08FD-1DC0-4AC5-9E69-AC1A5DCBED83@gmail.com>

Lars Schneider <larsxschneider@gmail.com> writes:

Show 14 quoted lines

>>> It would be great if we could test this is a little bit in pu.
>> 
>> This has been in 'pu' for a while.  
>> 
>> As the patch simply discards 502 (and others), it is unclear if the
>> failing test on 'next' is now gone, or the attempt to run 'pu'
>> happened to be lucky not to get one, from the output we can see in
>> https://travis-ci.org/git/git/jobs/229867212
>> 
>> Are you comfortable enough to move this forward?
>
> Yes, please move it forward. I haven't seen a "502 - Web server 
> received an invalid response" on pu for a while. That means the
> patch should work as expected.

Will do, thanks.

Show 20 quoted lines

> Unrelated to this patch I have, however, seen two kinds of timeouts:
>
> (1) Timeout in the "notStarted" state. This job eventually finished
> with a failure but it did start only *after* 3h:
> https://travis-ci.org/git/git/jobs/230225611
>
> (2) Timeout in the "in progress" state. This job eventually finished
> successfully but it took longer than 3h:
> https://travis-ci.org/git/git/jobs/229867248
>
> Right now the timeout generates potential false negative results. 
> I would like to change that and respond with a successful build 
> *before* we approach the 3h timeout. This means we could generate
> false positives. Although this is not ideal, I think that is the better 
> compromise as a failing Windows build would usually fail quickly 
> (e.g. in the compile step).
>
> What do you guys think? Would you be OK with that reasoning?
> If the Git for Windows builds get more stable over time then
> we could reevaluate this compromise.

I'd rather see a false breakage on Windows build (i.e. "this might have succeeded given enough time, but it didn't finish within the alloted time") than a false sucess (i.e. "we successfully launched and the build is still running, so let's assume the test succeeds"). Because I do not pay attention to what the overall build page [*1*] says about a particular branch tip, and I instead look at the summary list of the indiviaul "Build Jobs", e.g. [*2*]), seeing errored/failed on [*1*] does not bother me personally, if that is what you are getting at.

[References]

*1* https://travis-ci.org/git/git/builds/ *2* https://travis-ci.org/git/git/builds/230235081