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.

> 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.

> 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 ?

Thanks,
Willy

Reply via email to