|
Hi All, the below error appears to be bogus, or something to do with a misconfigured build. For example 1258.40, which is the linux32ARMv6 squeak.cog.spur build, is doing this (amd64 packages?!?!?) when it stalls: Get:1 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 libc6-dev amd64 2.19-0ubuntu6.14 [1,913 kB] Get:2 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 libc-dev-bin amd64 2.19-0ubuntu6.14 [69.0 kB] Get:3 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 libc6 amd64 2.19-0ubuntu6.14 [4,753 kB] Get:4 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 libatomic1 amd64 4.8.4-2ubuntu1~14.04.4 [8,630 B] Get:5 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 libitm1 amd64 4.8.4-2ubuntu1~14.04.4 [28.6 kB] Get:6 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 libgomp1 amd64 4.8.4-2ubuntu1~14.04.4 [23.1 kB] Get:7 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 libasan0 amd64 4.8.4-2ubuntu1~14.04.4 [63.1 kB] Get:8 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 libtsan0 amd64 4.8.4-2ubuntu1~14.04.4 [94.8 kB] Get:9 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 libquadmath0 amd64 4.8.4-2ubuntu1~14.04.4 [126 kB] Get:10 http://us-central1.gce.archive.ubuntu.com/ubuntu trusty-updates/main amd64 g++-4.8 amd64 4.8.4-2ubuntu1~14.04.4 [18.0 MB] On Tue, Apr 3, 2018 at 3:52 PM, Travis CI <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
In reply to this post by Travis CI
On 4 April 2018 at 06:52, Travis CI <[hidden email]> wrote: > > > OpenSmalltalk / opensmalltalk-vm > > Cog > > Build #1258 has errored > > 2 hours, 29 minutes, and 57 seconds > > Eliot Miranda > > 0ce1378 CHANGESET → > > Nuke obsolete files that uploaded VMs to mirandabanda.org I notice https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/361820486 shows the failures due to Raspberry Pi are 1258.38 16 min Failed in travis_install.sh 1258.39 49 min Failed in travis-build.sh = The job exceeded the maximum time limit for jobs, and has been terminated. 1258.40 16 min Failed in travis_install.sh 1258.41 16 min Failed in travis_install.sh 1258.42 49 min Failed in travis_build.sh = The job exceeded the maximum time limit for jobs, and has been terminated. 1258.43 45 min Success, travis_install.sh time = 22 minutes, travis_build.sh = 21 minutes So over half the builds failed directly due to installing from remote site. The successful job shows over half the time taken with the install, so this indirectly causes the two timeout failures. The install says... "After this operation, 427 MB of additional disk space will be used". So I wonder if it wold be useful to have an install-only stage that tar's itself up to carry forward as an artifact for a subsequent build-only job to untar & chroot into that artifact ?? This might save 20 minutes per build-only job and give the build more headroom to succeed. Also the install-only stage might have some magic to detect a stalled install before Travis does, and restart it. And at least it will be very obvious that install failed rather than a build. cheers -ben |
2018-04-04 6:58 GMT+02:00 Ben Coman <[hidden email]>:
Yes, those timeouts sound like the source of our problems. I understand that build worker machines are linux amd64 and that we use sort of cross-compilation -march=armv6 to produce our artifacts, so amd64 messages seems normal, though we go probably thru tons of useless stuff. If we can accelerate production of arm builds that's all good, they are dead slow... |
In reply to this post by Ben Coman
On 4 April 2018 at 12:58, Ben Coman <[hidden email]> wrote: > On 4 April 2018 at 06:52, Travis CI <[hidden email]> wrote: >> >> >> OpenSmalltalk / opensmalltalk-vm >> >> Cog >> >> Build #1258 has errored >> >> 2 hours, 29 minutes, and 57 seconds >> >> Eliot Miranda >> >> 0ce1378 CHANGESET → >> >> Nuke obsolete files that uploaded VMs to mirandabanda.org > > I notice https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/361820486 > shows the failures due to Raspberry Pi are > > 1258.38 16 min Failed in travis_install.sh > 1258.39 49 min Failed in travis-build.sh = The job exceeded the > maximum time limit for jobs, and has been terminated. > 1258.40 16 min Failed in travis_install.sh > 1258.41 16 min Failed in travis_install.sh > 1258.42 49 min Failed in travis_build.sh = The job exceeded the > maximum time limit for jobs, and has been terminated. > 1258.43 45 min Success, travis_install.sh time = 22 minutes, > travis_build.sh = 21 minutes But then here... https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/361559796 it takes only 70 seconds for travis_install.sh. cheers -ben > > So over half the builds failed directly due to installing from remote site. > The successful job shows over half the time taken with the install, so > this indirectly causes the two timeout failures. > The install says... "After this operation, 427 MB of additional disk > space will be used". > > So I wonder if it wold be useful to have an install-only stage that > tar's itself up to carry forward as an artifact > for a subsequent build-only job to untar & chroot into that artifact ?? > This might save 20 minutes per build-only job and give the build more > headroom to succeed. > > Also the install-only stage might have some magic to detect a stalled > install before Travis does, and restart it. > And at least it will be very obvious that install failed rather than a build. > > cheers -ben |
On Wed, Apr 4, 2018 at 11:12 PM Ben Coman <[hidden email]> wrote:
I haven't closely looked into this specific case, but it's always good to check Travis' status page [1] as well. As all infrastructure providers, they sometimes suffer from outages, especially because they have to keep things up-to-date and provide backwards compatibility at the same time. Fabio
|
Free forum by Nabble | Edit this page |