пт, 8 мая 2020 г. в 11:35, Martin Grigorov <martin.grigo...@gmail.com>:

> 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 <w...@1wt.eu> 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

Reply via email to