пт, 8 мая 2020 г. в 12:26, Willy Tarreau <[email protected]>: > On Fri, May 08, 2020 at 09:34:32AM +0300, Martin Grigorov wrote: > > 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. > > That's very likely indeed. >
it is not :) I provided link to my fork, openssl build takes 640 sec > > > 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. > > Ah, excellent, precisely what I was looking for. And some indicate > that the buffering further causes issues in the build system itself! > > > 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 > > We could, but 120 (2 hours) seems a bit extreme. It also means we can steal > 2 hours of CPU there in case something goes wrong. > travis-ci limits build at 60 min. > > > 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. > > I'm wondering why instead we don't fallback on an already packaged version > of OpenSSL for this platform. I mean, sure it's convenient to test the > latest version but it's already tested on x86 and we could very well use > any other version already packaged on the distro present there. This would > solve the problem and even increase versions coverage. > > Ilya, what do you think ? > yes, there are few options to think about. I also provided options (numbered 1..4), Hopefully, I think on your suggestions, Martin will think on my suggestion ... and we will decide what next would be. > > Thanks, > Willy >
