пт, 8 мая 2020 г. в 11:35, Martin Grigorov <[email protected]>:
> Hi, > > I think I understand why it started failing. > It must have started failing when you updated the version of OpenSSL. > .travis.yml caches ~/opt folder between builds. After the update to 1.1.1f > the build doesn't see the OpenSSL binaries in the cache anymore and tries > to download it and build it. > But as I've noticed in my attempt to build HAProxy with Docker+QEMU the > build of OpenSSL is taking too long. > The build of OpenSSL is wrapped with travis_wait to reduce the writes to > stdout but the default time for travis_wait is 20 mins and this is not > enough to build OpenSSL. > Due to > https://travis-ci.community/t/output-is-truncated-heavily-in-arm64-when-a-command-hangs/7630 > TravisCI > does not properly report that the problem is at build_ssl() step but shows > the last chunk of the buffered response and this confuses us all. > I think the build will become green if we extend travis_wait to a higher > value ( > https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received). > I don't remember where I have read it but I think the upper limit is 120 > mins. > @Willy: could you please change > https://github.com/haproxy/haproxy/blob/master/.travis.yml#L112 to: > > travis_wait 120 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat > build-ssl.log && exit 1) > > i.e. add '120' after travis_wait > https://travis-ci.com/github/chipitsine/haproxy/jobs/329528056 - as you can see full openssl build took 640s it is longer than 10 minutes > > This should give it the time to download and install OpenSSL 1.1.1f and to > cache it. If the build passes once then the next builds should be much > faster because OpenSSL will be used from the cache. > > Regards, > Martin > > On Fri, May 8, 2020 at 9:18 AM Willy Tarreau <[email protected]> wrote: > >> Hi Martin, >> >> On Fri, May 08, 2020 at 08:56:07AM +0300, Martin Grigorov wrote: >> > Unfortunately it is not good: >> > https://travis-ci.com/github/haproxy/haproxy/jobs/329657180 >> >> Indeed it's still not fixed on Travis' side. However what Ilya did >> actually worked, in that the status is not reported as a global >> build failure anymore. This allows us to continue to monitor if >> and when this issue finally resolves on the build infrastructure. >> It's also possible that they're not aware of the problem due to >> too few people using arm64. If someone has contacts there it might >> be worth checking with them. All we know for now is that it seems >> to stop moving while setting up libpcre2. Maybe there's a bug in >> a script in this package, resulting in a prompt for a question >> which never gets a response :-/ But that's something we can't >> check since we don't have access to an interactive shell there >> to diagnose. >> >> Willy >> >
