[PATCH v2] ci: support Travis CI's aarch64 builds

[Paul Chaignon]

On Mon, Nov 11, 2019 at 02:01:35AM +0300, Dmitry V. Levin wrote:
> On Sun, Nov 10, 2019 at 10:45:29AM +0100, Paul Chaignon wrote:
> > On Sun, Nov 10, 2019 at 02:25:50AM +0300, Dmitry V. Levin wrote:
> > > On Fri, Nov 08, 2019 at 12:30:15PM +0100, Paul Chaignon wrote:
> > > > Travis CI now supports aarch64 builds, launched with the new "arch: arm64"
> > > > tag.  These builds are running inside LXD only for the moment.
> > > > 
> > > > The aarch64 builds tend to be a lot slower than their x86_64 counterparts,
> > > > so several timeout values need to be increased.
> > > > 
> > > > * .travis.yml (matrix): add aarch64 builds and mark previous builds as
> > > > amd64.
> > > > * ci/install-dependencies.sh: install packages for aarch64 builds
> > > > * ci/run-build-and-tests.sh: check mpers for aarch64.
> > > > 
> > > > Signed-off-by: Paul Chaignon <paul.chaignon at gmail.com>
> > > > ---
> > > >  .travis.yml                | 50 ++++++++++++++++++++++++++++++++++++++
> > > >  ci/install-dependencies.sh | 26 ++++++++++++++++----
> > > >  ci/run-build-and-tests.sh  |  3 +++
> > > >  tests/umount2.c            |  1 +
> > > 
> > > I suppose the tests/umount2.c part was not intended to squeeze in.
> > > 
> > > Anyway, I applied it and pushed into a test branch to see how it builds.
> > > Apparently, aarch64 builds are often errored out by Travis CI due to
> > > "No output has been received in the last 10m" condition.  I suppose this
> > > is a side effect of raising TIMEOUT_DURATION over the current default of
> > > 10 minutes.
> > 
> > Hm, I had that error once but later builds seemed okay.  I'll try to use
> > the travis_wait command pointed out by the documentation [1] to raise the
> > timeout on Travis CI's side in accordance with TIMEOUT_DURATION.
> > 
> > Is this always happening while running qual_fault.test?
> 
> There is no easy way to tell what has been running when Travis CI stopped
> the build because of no output in 10 minutes.  For example, in [1]
> the last three lines of output were
> 
> PASS: looping_threads.test
> PASS: qual_fault-syscall.test
> PASS: qual_fault.test

As I understand, Travis CI stops because one of the test takes more than
10 minutes (thus, no new output line is emitted).  So one of the tests
around qual_fault.test is likely running slow.  Do we have a way to report
the duration of each test?

In the meantime, I'm experimenting with travis_wait, but the "No output"
error happens sporadically; it's going to take a while to check whether
this works :)

Paul