Re: [PATCH] enable arm64 builds in travis-ci
Hi Willy, On Fri, May 15, 2020 at 6:07 PM Willy Tarreau wrote: > Ilya, > > > also, I'd suggest to purge travis-ci cache (if you are build in your own > > fork). > > some travis related issue might be related when something is took from > > cache (which was not supposed to happen) > > Could you please handle Martin's patch, possibly cut it into several > pieces if relevant and add a commit message indicating what it does > (and why) ? Martin is not at ease with Git (which is not a problem), > and it seems only him and you understand how the reasons of the changes > in his patch. At least it's totally unclear to me why there's a new > install target for arm64 and why there's a special "make" invocation > there. > Let me explain the change. At https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L113-L117 you may see the default 'install' phase. At https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L12-L19 is the default environment. They are used by every job from the matrix ( https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L35 ). But each job can override the default environment and any of the phases (before_install, install, after_install, script). For the ARM64 build I overwrote the 'install' phase by copying the default one and removing the execution of the build_ssl() function (the one that builds OpenSSL from source) and I also overwrote the environment to update the values of SSL_INC and SSL_LIB variables. 'openssl' and 'libssl-dev' packages are already installed in the Ubuntu image used by TravisCI so there is nothing to install manually.. I've added a comment ( https://github.com/haproxy/haproxy/blob/a8dbdf3c4b463a3f3e018f0cd02fa0d8d179bc07/.travis.yml#L47) to remind us how it works. > Feel free to add your "purge cache" change as an extra patch if needed. > But in any case, please make sure it's still possible to follow the > impact of each change, because we've touched many things blindly for > a while on this arm64 issue and most of the changes were basically > "let's see if this helps", which is a real mess :-/ > > Thanks! > Willy >
Re: [PATCH] enable arm64 builds in travis-ci
Thank you for applying the patch! The ARM64 build passed at https://travis-ci.com/github/haproxy/haproxy/jobs/335338296 ! But it passes only for the builds which have 'haproxy-mirror' : https://travis-ci.com/github/haproxy/haproxy/builds I am not sure what exactly "haproxy-mirror" is in the TravisCI config. The builds which do not have "haproxy-mirror" next to the branch name also do not have ARM64 build at all, e.g. https://travis-ci.com/github/haproxy/haproxy/builds/166573019. One thing that I notice is that the successful link above has *jobs *and the failing one: *builds *before the job/build id. On Fri, May 15, 2020 at 9:53 PM Willy Tarreau wrote: > On Fri, May 15, 2020 at 11:44:48PM +0500, ??? wrote: > > commit message adjusted > > Many thanks for this, Ilya, now pushed! > > Willy >
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 15, 2020 at 11:44:48PM +0500, ??? wrote: > commit message adjusted Many thanks for this, Ilya, now pushed! Willy
Re: [PATCH] enable arm64 builds in travis-ci
commit message adjusted
пт, 15 мая 2020 г. в 22:02, Илья Шипицин :
>
>
> пт, 15 мая 2020 г. в 20:07, Willy Tarreau :
>
>> Ilya,
>>
>> > also, I'd suggest to purge travis-ci cache (if you are build in your own
>> > fork).
>> > some travis related issue might be related when something is took from
>> > cache (which was not supposed to happen)
>>
>> Could you please handle Martin's patch, possibly cut it into several
>> pieces if relevant and add a commit message indicating what it does
>> (and why) ? Martin is not at ease with Git (which is not a problem),
>> and it seems only him and you understand how the reasons of the changes
>> in his patch. At least it's totally unclear to me why there's a new
>> install target for arm64 and why there's a special "make" invocation
>> there.
>>
>> Feel free to add your "purge cache" change as an extra patch if needed.
>> But in any case, please make sure it's still possible to follow the
>> impact of each change, because we've touched many things blindly for
>> a while on this arm64 issue and most of the changes were basically
>> "let's see if this helps", which is a real mess :-/
>>
>
> I will resend a patch with detailed information.
>
>
> as for "purge a cache", it was a suggestion to Martin to purge it manually
> in his own travis-ci project.
> it usually helps to find caveats (for example, you still get files from
> cache which is not desireable)
>
> it's just for pre-checkin test.
>
>
>
>>
>> Thanks!
>> Willy
>>
>
From 98849dc14e08f1c1fb8899145e1ed24118bb1d8b Mon Sep 17 00:00:00 2001
From: Martin Tzvetanov Grigorov
Date: Fri, 15 May 2020 23:34:46 +0500
Subject: [PATCH] CI: travis-ci: switch arm64 builds to use openssl from distro
there are ongoing arm64 failures in travis-ci. we suspect that
build stucks on scripts/build-ssl.sh which is called during build.
let us try to use openssl from ubuntu distro and not build it
ourselves. to achive that we add "install" section without
build-ssl.sh
---
.travis.yml | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index ea7168624..e2a32a2b7 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -44,14 +44,15 @@ matrix:
compiler: clang
env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9
- os: linux
+# The ARM64 build uses openssl and libssl-dev from Ubuntu repository. They come preinstalled by TravisCI!
arch: arm64
if: type == push
compiler: clang
-env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9
-addons:
- apt:
-update: true
-packages: [ liblua5.3-dev, libsystemd-dev, clang-9, socat ]
+env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9 SSL_LIB=/usr/lib SSL_INC=/usr/include
+install:
+ - git clone https://github.com/VTest/VTest.git ../vtest
+ # Special flags due to: https://github.com/vtest/VTest/issues/12
+ - make -C ../vtest FLAGS="-O2 -s -Wall"
- os: linux
arch: s390x
if: type == push
@@ -113,7 +114,7 @@ install:
- git clone https://github.com/VTest/VTest.git ../vtest
# Special flags due to: https://github.com/vtest/VTest/issues/12
- make -C ../vtest FLAGS="-O2 -s -Wall"
- - travis_wait 60 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat build-ssl.log && exit 1)
+ - travis_wait bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat build-ssl.log && exit 1)
script:
- if [ "${CC%-*}" = "clang" ]; then export FLAGS="$FLAGS USE_OBSOLETE_LINKER=1" DEBUG_CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address"; fi
--
2.26.2
Re: [PATCH] enable arm64 builds in travis-ci
пт, 15 мая 2020 г. в 20:07, Willy Tarreau : > Ilya, > > > also, I'd suggest to purge travis-ci cache (if you are build in your own > > fork). > > some travis related issue might be related when something is took from > > cache (which was not supposed to happen) > > Could you please handle Martin's patch, possibly cut it into several > pieces if relevant and add a commit message indicating what it does > (and why) ? Martin is not at ease with Git (which is not a problem), > and it seems only him and you understand how the reasons of the changes > in his patch. At least it's totally unclear to me why there's a new > install target for arm64 and why there's a special "make" invocation > there. > > Feel free to add your "purge cache" change as an extra patch if needed. > But in any case, please make sure it's still possible to follow the > impact of each change, because we've touched many things blindly for > a while on this arm64 issue and most of the changes were basically > "let's see if this helps", which is a real mess :-/ > I will resend a patch with detailed information. as for "purge a cache", it was a suggestion to Martin to purge it manually in his own travis-ci project. it usually helps to find caveats (for example, you still get files from cache which is not desireable) it's just for pre-checkin test. > > Thanks! > Willy >
Re: [PATCH] enable arm64 builds in travis-ci
Ilya, > also, I'd suggest to purge travis-ci cache (if you are build in your own > fork). > some travis related issue might be related when something is took from > cache (which was not supposed to happen) Could you please handle Martin's patch, possibly cut it into several pieces if relevant and add a commit message indicating what it does (and why) ? Martin is not at ease with Git (which is not a problem), and it seems only him and you understand how the reasons of the changes in his patch. At least it's totally unclear to me why there's a new install target for arm64 and why there's a special "make" invocation there. Feel free to add your "purge cache" change as an extra patch if needed. But in any case, please make sure it's still possible to follow the impact of each change, because we've touched many things blindly for a while on this arm64 issue and most of the changes were basically "let's see if this helps", which is a real mess :-/ Thanks! Willy
Re: [PATCH] enable arm64 builds in travis-ci
that should work indeed. also, I'd suggest to purge travis-ci cache (if you are build in your own fork). some travis related issue might be related when something is took from cache (which was not supposed to happen) пт, 15 мая 2020 г. в 15:26, Martin Grigorov : > Those are set to new values at > https://github.com/haproxy/haproxy/pull/630/files#diff-354f30a63fb0907d4ad57269548329e3R51 > > On Fri, May 15, 2020 at 1:11 PM Илья Шипицин wrote: > >> or we'd better move SSL_LIB, SSL_INC to build-ssl.sh script >> >> пт, 15 мая 2020 г. в 15:09, Илья Шипицин : >> >>> probably, you also need to unset SSL_LIB and SSL_INC >>> >>> >>> >>> btw, I got an answer how to grant travis-ci rights (for triggering build >>> manually) >>> >>> https://travis-ci.community/t/undocumented-require-admin-permissions/8530 >>> >>> >>> пт, 15 мая 2020 г. в 14:57, Martin Grigorov : >>> Hi, I've created https://github.com/haproxy/haproxy/pull/630 With this change the build passed successfully for 5 mins and 7 secs for ARM64. Please let me know if you prefer me to send it as an attached .patch file here. (I haven't used `git format-patch` before :-/). Martin On Mon, May 11, 2020 at 12:38 PM Илья Шипицин wrote: > > > сб, 9 мая 2020 г. в 11:45, Willy Tarreau : > >> On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote: >> > ? 8 mai 2020 14:25 +02, Willy Tarreau: >> > >> > >> > Let's increase the timeout to see if it has a chance to >> finish, no ? >> > >> > >> > >> >> > >> yes >> > > >> > > OK now pushed. It's really annoying to work blindly like this. The >> > > build model Travis uses is broken by design. Requiring to commit >> > > something for testing is utterly wrong. And doing so within the >> > > project that's supposed to being test is further wrong. We already >> > > have 44 patches only on .travis.yml! If this continues like this, >> > > I predict that a "pre-CI" solution will appear to test if your >> > > change is likely to trigger a travis error before it gets >> merged... >> > >> > You can push changes to a (throwable) branch instead. >> >> Good point, that can also be a solution. But it remains completely >> hackish. It's basically abusing a versioning system to use it as a >> messaging system to indicate "please build with this". >> >> Willy >> > > > I created several topics (no answer yet). > > as for travis-ci rights, it's totally undocumented. but I suspect > travis grants > rights based on github rights. i.e. github admin becomes travis admin > as well. > > https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529 > > > https://travis-ci.community/t/undocumented-require-admin-permissions/8530 > > > https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528 > >
Re: [PATCH] enable arm64 builds in travis-ci
Those are set to new values at https://github.com/haproxy/haproxy/pull/630/files#diff-354f30a63fb0907d4ad57269548329e3R51 On Fri, May 15, 2020 at 1:11 PM Илья Шипицин wrote: > or we'd better move SSL_LIB, SSL_INC to build-ssl.sh script > > пт, 15 мая 2020 г. в 15:09, Илья Шипицин : > >> probably, you also need to unset SSL_LIB and SSL_INC >> >> >> >> btw, I got an answer how to grant travis-ci rights (for triggering build >> manually) >> >> https://travis-ci.community/t/undocumented-require-admin-permissions/8530 >> >> >> пт, 15 мая 2020 г. в 14:57, Martin Grigorov : >> >>> Hi, >>> >>> I've created https://github.com/haproxy/haproxy/pull/630 >>> With this change the build passed successfully for 5 mins and 7 secs for >>> ARM64. >>> >>> Please let me know if you prefer me to send it as an attached .patch >>> file here. (I haven't used `git format-patch` before :-/). >>> >>> Martin >>> >>> On Mon, May 11, 2020 at 12:38 PM Илья Шипицин >>> wrote: >>> сб, 9 мая 2020 г. в 11:45, Willy Tarreau : > On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote: > > ? 8 mai 2020 14:25 +02, Willy Tarreau: > > > > >> > Let's increase the timeout to see if it has a chance to finish, > no ? > > >> > > > >> > > >> yes > > > > > > OK now pushed. It's really annoying to work blindly like this. The > > > build model Travis uses is broken by design. Requiring to commit > > > something for testing is utterly wrong. And doing so within the > > > project that's supposed to being test is further wrong. We already > > > have 44 patches only on .travis.yml! If this continues like this, > > > I predict that a "pre-CI" solution will appear to test if your > > > change is likely to trigger a travis error before it gets merged... > > > > You can push changes to a (throwable) branch instead. > > Good point, that can also be a solution. But it remains completely > hackish. It's basically abusing a versioning system to use it as a > messaging system to indicate "please build with this". > > Willy > I created several topics (no answer yet). as for travis-ci rights, it's totally undocumented. but I suspect travis grants rights based on github rights. i.e. github admin becomes travis admin as well. https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529 https://travis-ci.community/t/undocumented-require-admin-permissions/8530 https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528 >>>
Re: [PATCH] enable arm64 builds in travis-ci
or we'd better move SSL_LIB, SSL_INC to build-ssl.sh script пт, 15 мая 2020 г. в 15:09, Илья Шипицин : > probably, you also need to unset SSL_LIB and SSL_INC > > > > btw, I got an answer how to grant travis-ci rights (for triggering build > manually) > > https://travis-ci.community/t/undocumented-require-admin-permissions/8530 > > > пт, 15 мая 2020 г. в 14:57, Martin Grigorov : > >> Hi, >> >> I've created https://github.com/haproxy/haproxy/pull/630 >> With this change the build passed successfully for 5 mins and 7 secs for >> ARM64. >> >> Please let me know if you prefer me to send it as an attached .patch file >> here. (I haven't used `git format-patch` before :-/). >> >> Martin >> >> On Mon, May 11, 2020 at 12:38 PM Илья Шипицин >> wrote: >> >>> >>> >>> сб, 9 мая 2020 г. в 11:45, Willy Tarreau : >>> On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote: > ? 8 mai 2020 14:25 +02, Willy Tarreau: > > >> > Let's increase the timeout to see if it has a chance to finish, no ? > >> > > >> > >> yes > > > > OK now pushed. It's really annoying to work blindly like this. The > > build model Travis uses is broken by design. Requiring to commit > > something for testing is utterly wrong. And doing so within the > > project that's supposed to being test is further wrong. We already > > have 44 patches only on .travis.yml! If this continues like this, > > I predict that a "pre-CI" solution will appear to test if your > > change is likely to trigger a travis error before it gets merged... > > You can push changes to a (throwable) branch instead. Good point, that can also be a solution. But it remains completely hackish. It's basically abusing a versioning system to use it as a messaging system to indicate "please build with this". Willy >>> >>> >>> I created several topics (no answer yet). >>> >>> as for travis-ci rights, it's totally undocumented. but I suspect travis >>> grants >>> rights based on github rights. i.e. github admin becomes travis admin as >>> well. >>> >>> https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529 >>> >>> https://travis-ci.community/t/undocumented-require-admin-permissions/8530 >>> >>> >>> https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528 >>> >>> >>
Re: [PATCH] enable arm64 builds in travis-ci
probably, you also need to unset SSL_LIB and SSL_INC btw, I got an answer how to grant travis-ci rights (for triggering build manually) https://travis-ci.community/t/undocumented-require-admin-permissions/8530 пт, 15 мая 2020 г. в 14:57, Martin Grigorov : > Hi, > > I've created https://github.com/haproxy/haproxy/pull/630 > With this change the build passed successfully for 5 mins and 7 secs for > ARM64. > > Please let me know if you prefer me to send it as an attached .patch file > here. (I haven't used `git format-patch` before :-/). > > Martin > > On Mon, May 11, 2020 at 12:38 PM Илья Шипицин > wrote: > >> >> >> сб, 9 мая 2020 г. в 11:45, Willy Tarreau : >> >>> On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote: >>> > ? 8 mai 2020 14:25 +02, Willy Tarreau: >>> > >>> > >> > Let's increase the timeout to see if it has a chance to finish, >>> no ? >>> > >> > >>> > >> >>> > >> yes >>> > > >>> > > OK now pushed. It's really annoying to work blindly like this. The >>> > > build model Travis uses is broken by design. Requiring to commit >>> > > something for testing is utterly wrong. And doing so within the >>> > > project that's supposed to being test is further wrong. We already >>> > > have 44 patches only on .travis.yml! If this continues like this, >>> > > I predict that a "pre-CI" solution will appear to test if your >>> > > change is likely to trigger a travis error before it gets merged... >>> > >>> > You can push changes to a (throwable) branch instead. >>> >>> Good point, that can also be a solution. But it remains completely >>> hackish. It's basically abusing a versioning system to use it as a >>> messaging system to indicate "please build with this". >>> >>> Willy >>> >> >> >> I created several topics (no answer yet). >> >> as for travis-ci rights, it's totally undocumented. but I suspect travis >> grants >> rights based on github rights. i.e. github admin becomes travis admin as >> well. >> >> https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529 >> >> https://travis-ci.community/t/undocumented-require-admin-permissions/8530 >> >> >> https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528 >> >> >
Re: [PATCH] enable arm64 builds in travis-ci
Hi, I've created https://github.com/haproxy/haproxy/pull/630 With this change the build passed successfully for 5 mins and 7 secs for ARM64. Please let me know if you prefer me to send it as an attached .patch file here. (I haven't used `git format-patch` before :-/). Martin On Mon, May 11, 2020 at 12:38 PM Илья Шипицин wrote: > > > сб, 9 мая 2020 г. в 11:45, Willy Tarreau : > >> On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote: >> > ? 8 mai 2020 14:25 +02, Willy Tarreau: >> > >> > >> > Let's increase the timeout to see if it has a chance to finish, no >> ? >> > >> > >> > >> >> > >> yes >> > > >> > > OK now pushed. It's really annoying to work blindly like this. The >> > > build model Travis uses is broken by design. Requiring to commit >> > > something for testing is utterly wrong. And doing so within the >> > > project that's supposed to being test is further wrong. We already >> > > have 44 patches only on .travis.yml! If this continues like this, >> > > I predict that a "pre-CI" solution will appear to test if your >> > > change is likely to trigger a travis error before it gets merged... >> > >> > You can push changes to a (throwable) branch instead. >> >> Good point, that can also be a solution. But it remains completely >> hackish. It's basically abusing a versioning system to use it as a >> messaging system to indicate "please build with this". >> >> Willy >> > > > I created several topics (no answer yet). > > as for travis-ci rights, it's totally undocumented. but I suspect travis > grants > rights based on github rights. i.e. github admin becomes travis admin as > well. > > https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529 > > https://travis-ci.community/t/undocumented-require-admin-permissions/8530 > > > https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528 > >
Re: [PATCH] enable arm64 builds in travis-ci
сб, 9 мая 2020 г. в 11:45, Willy Tarreau : > On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote: > > ? 8 mai 2020 14:25 +02, Willy Tarreau: > > > > >> > Let's increase the timeout to see if it has a chance to finish, no ? > > >> > > > >> > > >> yes > > > > > > OK now pushed. It's really annoying to work blindly like this. The > > > build model Travis uses is broken by design. Requiring to commit > > > something for testing is utterly wrong. And doing so within the > > > project that's supposed to being test is further wrong. We already > > > have 44 patches only on .travis.yml! If this continues like this, > > > I predict that a "pre-CI" solution will appear to test if your > > > change is likely to trigger a travis error before it gets merged... > > > > You can push changes to a (throwable) branch instead. > > Good point, that can also be a solution. But it remains completely > hackish. It's basically abusing a versioning system to use it as a > messaging system to indicate "please build with this". > > Willy > I created several topics (no answer yet). as for travis-ci rights, it's totally undocumented. but I suspect travis grants rights based on github rights. i.e. github admin becomes travis admin as well. https://travis-ci.community/t/arm64-fails-with-non-clear-reason/8529 https://travis-ci.community/t/undocumented-require-admin-permissions/8530 https://travis-ci.community/t/undocumented-operation-requires-create-request-access-to-repository/8528
Re: [PATCH] enable arm64 builds in travis-ci
On Sat, May 09, 2020 at 08:11:27AM +0200, Vincent Bernat wrote: > ? 8 mai 2020 14:25 +02, Willy Tarreau: > > >> > Let's increase the timeout to see if it has a chance to finish, no ? > >> > > >> > >> yes > > > > OK now pushed. It's really annoying to work blindly like this. The > > build model Travis uses is broken by design. Requiring to commit > > something for testing is utterly wrong. And doing so within the > > project that's supposed to being test is further wrong. We already > > have 44 patches only on .travis.yml! If this continues like this, > > I predict that a "pre-CI" solution will appear to test if your > > change is likely to trigger a travis error before it gets merged... > > You can push changes to a (throwable) branch instead. Good point, that can also be a solution. But it remains completely hackish. It's basically abusing a versioning system to use it as a messaging system to indicate "please build with this". Willy
Re: [PATCH] enable arm64 builds in travis-ci
❦ 8 mai 2020 14:25 +02, Willy Tarreau: >> > Let's increase the timeout to see if it has a chance to finish, no ? >> > >> >> yes > > OK now pushed. It's really annoying to work blindly like this. The > build model Travis uses is broken by design. Requiring to commit > something for testing is utterly wrong. And doing so within the > project that's supposed to being test is further wrong. We already > have 44 patches only on .travis.yml! If this continues like this, > I predict that a "pre-CI" solution will appear to test if your > change is likely to trigger a travis error before it gets merged... You can push changes to a (throwable) branch instead. -- Make it clear before you make it faster. - The Elements of Programming Style (Kernighan & Plauger)
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 08, 2020 at 06:14:28PM +0500, ??? wrote: > > You can avoid this by making changes to .travis.yml directly in Travis UI. > > At the right-top part of the page there is "More options" menu. Select > > "Trigger build" and in the dialog you can paste "Custom config". Once you > > are happy with the outcome you can push it in your Git repo. Awesome, thanks Martin! I wish we'd found this earlier! > that's nice idea. > Willy, can you grant me rights (in travis) to do so ? It requires "admin" > travis permissions I wish I could. I've visited all visible menus and even settings under my face, and couldn't find anything related to user management nor permissions :-( It's fairly possible it's hidden somewhere, I'm not good at spotting hidden menus in modern interfaces. So for now I'm a bit stuck :-( Willy
Re: [PATCH] enable arm64 builds in travis-ci
пт, 8 мая 2020 г. в 18:04, Martin Grigorov : > > > On Fri, May 8, 2020 at 3:25 PM Willy Tarreau wrote: > >> On Fri, May 08, 2020 at 05:04:43PM +0500, ??? wrote: >> > > Let's increase the timeout to see if it has a chance to finish, no ? >> > > >> > >> > yes >> >> OK now pushed. It's really annoying to work blindly like this. The >> build model Travis uses is broken by design. Requiring to commit >> something for testing is utterly wrong. And doing so within the >> project that's supposed to being test is further wrong. We already >> have 44 patches only on .travis.yml! If this continues like this, >> I predict that a "pre-CI" solution will appear to test if your >> change is likely to trigger a travis error before it gets merged... >> > > You can avoid this by making changes to .travis.yml directly in Travis UI. > At the right-top part of the page there is "More options" menu. Select > "Trigger build" and in the dialog you can paste "Custom config". Once you > are happy with the outcome you can push it in your Git repo. > > that's nice idea. Willy, can you grant me rights (in travis) to do so ? It requires "admin" travis permissions > Back to the main topic: > Now it fails with totally new reason. It doesn't even start installing the > dependencies. > it does start. you can see in "raw logs" https://api.travis-ci.com/v3/job/329899528/log.txt > It started failing this way since: > https://github.com/haproxy/haproxy/commit/8d76af55e10f018ab3d482125433be4992884372 > You can try the "manual approach" by reverting this change! ;-) > > >> >> Willy >> >
Re: [PATCH] enable arm64 builds in travis-ci
пт, 8 мая 2020 г. в 17:25, Willy Tarreau : > On Fri, May 08, 2020 at 05:04:43PM +0500, ??? wrote: > > > Let's increase the timeout to see if it has a chance to finish, no ? > > > > > > > yes > > OK now pushed. It's really annoying to work blindly like this. The > build model Travis uses is broken by design. Requiring to commit > something for testing is utterly wrong. And doing so within the > project that's supposed to being test is further wrong. We already > have 44 patches only on .travis.yml! If this continues like this, > I predict that a "pre-CI" solution will appear to test if your > change is likely to trigger a travis error before it gets merged... > usual way of doing so is pull request > > Willy >
Re: [PATCH] enable arm64 builds in travis-ci
пт, 8 мая 2020 г. в 16:45, Willy Tarreau : > On Fri, May 08, 2020 at 04:17:18PM +0500, ??? wrote: > > as far as I understand, arm64 is run inside containers. something like > > docker or lxd. > > > > "Processing triggers for dbus (1.12.2-1ubuntu1.1) ..." > > > > > > dbus is not supposed to be available from container, right ? > > No idea but if it works on your repo it should there as well. I > really think that the logs are just shown a bit further as Martin > and I predicted :-) > > Let's increase the timeout to see if it has a chance to finish, no ? > yes > > Willy >
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 08, 2020 at 04:17:18PM +0500, ??? wrote: > as far as I understand, arm64 is run inside containers. something like > docker or lxd. > > "Processing triggers for dbus (1.12.2-1ubuntu1.1) ..." > > > dbus is not supposed to be available from container, right ? No idea but if it works on your repo it should there as well. I really think that the logs are just shown a bit further as Martin and I predicted :-) Let's increase the timeout to see if it has a chance to finish, no ? Willy
Re: [PATCH] enable arm64 builds in travis-ci
as far as I understand, arm64 is run inside containers. something like docker or lxd. "Processing triggers for dbus (1.12.2-1ubuntu1.1) ..." dbus is not supposed to be available from container, right ? пт, 8 мая 2020 г. в 16:15, Илья Шипицин : > another travis-ci bug. > UI does not show full log: > https://api.travis-ci.com/v3/job/329873686/log.txt > > > > пт, 8 мая 2020 г. в 15:58, Willy Tarreau : > >> On Fri, May 08, 2020 at 03:29:26PM +0500, ??? wrote: >> > I attached a patch >> >> Pushed, thanks. Next step in 10 minutes :-) >> > > > it did not uncover any truth. > let us set bigger timeout, I guess it does not matter 60 or 120, build > will be limited to 60 anyway/\ > > >> >> Willy >> >
Re: [PATCH] enable arm64 builds in travis-ci
another travis-ci bug. UI does not show full log: https://api.travis-ci.com/v3/job/329873686/log.txt пт, 8 мая 2020 г. в 15:58, Willy Tarreau : > On Fri, May 08, 2020 at 03:29:26PM +0500, ??? wrote: > > I attached a patch > > Pushed, thanks. Next step in 10 minutes :-) > it did not uncover any truth. let us set bigger timeout, I guess it does not matter 60 or 120, build will be limited to 60 anyway/\ > > Willy >
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 08, 2020 at 03:29:26PM +0500, ??? wrote: > I attached a patch Pushed, thanks. Next step in 10 minutes :-) Willy
Re: [PATCH] enable arm64 builds in travis-ci
пт, 8 мая 2020 г. в 15:09, Willy Tarreau : > On Fri, May 08, 2020 at 03:07:51PM +0500, ??? wrote: > > ??, 8 ??? 2020 ?. ? 14:55, Willy Tarreau : > > > > > On Fri, May 08, 2020 at 01:59:57PM +0500, ??? wrote: > > > > > We don't know how long it gets cached so if we increase it we'll > have > > > to > > > > > leave it. > > > > > > > > > > > > > it is cached forever, until cache is purged manually or some cache > key > > > > (e.g. openssl version) is changed > > > > > > OK, so do you want me to try increasing to 60 minutes before changing > > > anything else ? > > > > > > > I would start with disabling pcre2. It should change output and uncover > > truth. I will send a patch in couple of days (if that won't help, we'll > > play with timeouts) > > I'm pretty convinced it will only truncate on next line but sure, we > can try :-) > I attached a patch > Willy > From da6a92a4c71d97a0a3bd5963b7fbe96c51c78da4 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Fri, 8 May 2020 15:25:56 +0500 Subject: [PATCH] CI: travis-ci: skip pcre2 on arm64 build currently arm64 stuck with some error related to pcre2. while we beleive pcre2 is not related to error itself, we can try not to install it --- .travis.yml | 4 1 file changed, 4 insertions(+) diff --git a/.travis.yml b/.travis.yml index 0d7268791..59f3450fb 100644 --- a/.travis.yml +++ b/.travis.yml @@ -48,6 +48,10 @@ matrix: if: type == push compiler: clang env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1f CC=clang-9 +addons: + apt: +update: true +packages: [ liblua5.3-dev, libsystemd-dev, clang-9, socat ] - os: linux arch: s390x if: type == push -- 2.25.4
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 08, 2020 at 03:07:51PM +0500, ??? wrote: > ??, 8 ??? 2020 ?. ? 14:55, Willy Tarreau : > > > On Fri, May 08, 2020 at 01:59:57PM +0500, ??? wrote: > > > > We don't know how long it gets cached so if we increase it we'll have > > to > > > > leave it. > > > > > > > > > > it is cached forever, until cache is purged manually or some cache key > > > (e.g. openssl version) is changed > > > > OK, so do you want me to try increasing to 60 minutes before changing > > anything else ? > > > > I would start with disabling pcre2. It should change output and uncover > truth. I will send a patch in couple of days (if that won't help, we'll > play with timeouts) I'm pretty convinced it will only truncate on next line but sure, we can try :-) Willy
Re: [PATCH] enable arm64 builds in travis-ci
пт, 8 мая 2020 г. в 14:55, Willy Tarreau : > On Fri, May 08, 2020 at 01:59:57PM +0500, ??? wrote: > > > We don't know how long it gets cached so if we increase it we'll have > to > > > leave it. > > > > > > > it is cached forever, until cache is purged manually or some cache key > > (e.g. openssl version) is changed > > OK, so do you want me to try increasing to 60 minutes before changing > anything else ? > I would start with disabling pcre2. It should change output and uncover truth. I will send a patch in couple of days (if that won't help, we'll play with timeouts) Martin, can you please try to contact travis support ? > > > build-ssl.sh is called from "install" section. we just need to add > separate > > "install" section for arm64 > > OK! > > > > I think we can do it directly from the build-ssl script if needed. > > > Basically something ugly more or less like this: > > > > > >if [ "$(uname -m)" = "aarch64" ]; then > > > apt install ... > > > ln -s /usr/lib64 $HOME/opt/lib > > > ln -s /usr/inculde $HOME/opt/include > > > exit 0 > > >fi > > > > > > > please, no :) > > I'm pleased to see I'm not the only one not liking ugly stuff :-) > > Willy >
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 08, 2020 at 01:59:57PM +0500, ??? wrote: > > We don't know how long it gets cached so if we increase it we'll have to > > leave it. > > > > it is cached forever, until cache is purged manually or some cache key > (e.g. openssl version) is changed OK, so do you want me to try increasing to 60 minutes before changing anything else ? > build-ssl.sh is called from "install" section. we just need to add separate > "install" section for arm64 OK! > > I think we can do it directly from the build-ssl script if needed. > > Basically something ugly more or less like this: > > > >if [ "$(uname -m)" = "aarch64" ]; then > > apt install ... > > ln -s /usr/lib64 $HOME/opt/lib > > ln -s /usr/inculde $HOME/opt/include > > exit 0 > >fi > > > > please, no :) I'm pleased to see I'm not the only one not liking ugly stuff :-) Willy
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 08, 2020 at 11:09:50AM +0300, Martin Grigorov wrote: > I still believe the problem is in the time needed to build OpenSSL, not in > apt[-get]. I agree that it's the most likely. > We can increase temporarily the travis_wait to 60 just to cache the build > of 1.1.1f and then remove '60' again. We don't know how long it gets cached so if we increase it we'll have to leave it. > Although if this is the problem then > 'travis_wait 60 ...' won't do any harm for the next builds because it will > use the cache and return in few secs. Sure. > I like the idea to install openssl with apt but I am not sure whether we > can do this *only* for ARM64. I think we can do it directly from the build-ssl script if needed. Basically something ugly more or less like this: if [ "$(uname -m)" = "aarch64" ]; then apt install ... ln -s /usr/lib64 $HOME/opt/lib ln -s /usr/inculde $HOME/opt/include exit 0 fi Willy
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 8, 2020 at 10:54 AM Илья Шипицин wrote: > > > пт, 8 мая 2020 г. в 12:26, Willy Tarreau : > >> 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. > I still believe the problem is in the time needed to build OpenSSL, not in apt[-get]. We can increase temporarily the travis_wait to 60 just to cache the build of 1.1.1f and then remove '60' again. Although if this is the problem then 'travis_wait 60 ...' won't do any harm for the next builds because it will use the cache and return in few secs. I like the idea to install openssl with apt but I am not sure whether we can do this *only* for ARM64. > > >> >> Thanks, >> Willy >> >
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 08, 2020 at 12:54:14PM +0500, ??? wrote: > > > 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 But we don't even know if we all end up on the same build nodes, and it's likely that it's not the case since yours finishes. > > 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. OK. > > 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. Well, for #1 I don't think that changing pcre2 will have any impact there because it's obvious that we're facing output buffer truncation and that the problem happens after though we don't know how far after. For #2, not using travis' apt, maybe we'd gain slightly better control, but it's not even certain and it's possible we might not benefit from certain caches, so I'm having doubts. For #3, interacting with their support channel, why not, if you're willing to engage into this. If at least they can bring us a complete untruncated output of a failed build, that would help. I continue to think that avoiding building standard packages in the VMs should be the priority. Our goal is not to test if openssl can be built and used there but if haproxy can be built and used there. When it's the only option to test integration with certain components, that's fine. Here I think that openssl is sufficiently covered on other platforms so we don't necessarily need to rebuild it ourselves and we can use the distro's version. Thanks, Willy
Re: [PATCH] enable arm64 builds in travis-ci
пт, 8 мая 2020 г. в 12:26, Willy Tarreau : > 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 >
Re: [PATCH] enable arm64 builds in travis-ci
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
Re: [PATCH] enable arm64 builds in travis-ci
пт, 8 мая 2020 г. в 11:35, Martin Grigorov : > 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 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 >> >
Re: [PATCH] enable arm64 builds in travis-ci
пт, 8 мая 2020 г. в 11:27, Willy Tarreau : > On Fri, May 08, 2020 at 11:12:00AM +0500, ??? wrote: > > btw, in my fork it is green > > https://travis-ci.com/github/chipitsine/haproxy/jobs/329528056 > > Cool, that tends to confirm the issue remains a bit random. There > is actually something I don't like in the build report, which is > that the "Setting up libpcre2" line is truncated. This definitely > indicates that output is not line-buffered and that could mean that > it in fact fails multiple lines later (processing triggers or any > such thing) but that the successful operations were not properly > logged. At this point I guess it's the apt-get utility which does > not properly configure its stdout, but it could also be anything > in between. In any case I doubt we'll have a big handle on this. > there are few options 1) setup separate "apt" key for "arm64", we do not use pcre2 here 2) use direct "apt-get" call, not travis "apt" plugin (maybe we can control buffering that way) 3) interoperate with travis via support channel 4) wait until it is resolved by itself Martin ? > > Willy >
Re: [PATCH] enable arm64 builds in travis-ci
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 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 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 >
Re: [PATCH] enable arm64 builds in travis-ci
On Fri, May 08, 2020 at 11:12:00AM +0500, ??? wrote: > btw, in my fork it is green > https://travis-ci.com/github/chipitsine/haproxy/jobs/329528056 Cool, that tends to confirm the issue remains a bit random. There is actually something I don't like in the build report, which is that the "Setting up libpcre2" line is truncated. This definitely indicates that output is not line-buffered and that could mean that it in fact fails multiple lines later (processing triggers or any such thing) but that the successful operations were not properly logged. At this point I guess it's the apt-get utility which does not properly configure its stdout, but it could also be anything in between. In any case I doubt we'll have a big handle on this. Willy
Re: [PATCH] enable arm64 builds in travis-ci
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
Re: [PATCH] enable arm64 builds in travis-ci
пт, 8 мая 2020 г. в 10:56, Martin Grigorov : > Hi all, > > On Thu, May 7, 2020 at 11:56 PM Willy Tarreau wrote: > >> Hi Ilya, >> >> On Thu, May 07, 2020 at 09:19:48PM +0500, ??? wrote: >> > Hello, >> > >> > let us enable arm64 builds back. >> >> Good idea, just merged now. Let's see how that ends up now. >> > > Unfortunately it is not good: > https://travis-ci.com/github/haproxy/haproxy/jobs/329657180 > that's why it is marked as "allow to fail" btw, in my fork it is green https://travis-ci.com/github/chipitsine/haproxy/jobs/329528056 > > Martin > > >> >> Thanks, >> Willy >> >>
Re: [PATCH] enable arm64 builds in travis-ci
Hi all, On Thu, May 7, 2020 at 11:56 PM Willy Tarreau wrote: > Hi Ilya, > > On Thu, May 07, 2020 at 09:19:48PM +0500, ??? wrote: > > Hello, > > > > let us enable arm64 builds back. > > Good idea, just merged now. Let's see how that ends up now. > Unfortunately it is not good: https://travis-ci.com/github/haproxy/haproxy/jobs/329657180 Martin > > Thanks, > Willy > >
Re: [PATCH] enable arm64 builds in travis-ci
Hi Ilya, On Thu, May 07, 2020 at 09:19:48PM +0500, ??? wrote: > Hello, > > let us enable arm64 builds back. Good idea, just merged now. Let's see how that ends up now. Thanks, Willy
