пт, 8 мая 2020 г. в 12:26, Willy Tarreau <w...@1wt.eu>:

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

Reply via email to