> On 09 May 2017, at 07:31, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Lars Schneider <larsxschneider@xxxxxxxxx> writes: > >> The Git for Windows CI web app sometimes returns HTTP errors of >> "502 bad gateway" or "503 service unavailable" [1]. We also need to >> check the HTTP content because the GfW web app seems to pass through >> (error) results from other Azure calls with HTTP code 200. >> Wait a little and retry the request if this happens. >> >> [1] https://docs.microsoft.com/en-in/azure/app-service-web/app-service-web-troubleshoot-http-502-http-503 >> >> Signed-off-by: Lars Schneider <larsxschneider@xxxxxxxxx> >> --- >> >> Hi Junio, >> >> I can't really test this as my TravisCI account does not have the >> extended timeout and I am unable to reproduce the error. >> >> 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. 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. - Lars