Lars Schneider <larsxschnei...@gmail.com> writes: >>> 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. > 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
