About the Multi CPU Architecture category

Hi, this is wanderful! It’s greate to have aarch64 support in Travis.

I try to test it for Apache Storm, but I found a swapon related problem on the aarch64 arch, I do the same thing with x86:

sudo dd if=/dev/zero of=/swapfile.img bs=4096 count=1M
sudo chmod 0600 /swapfile.img
sudo mkswap /swapfile.img
sudo swapon /swapfile.img

but I got the “swapon: /swapfile.img: skipping - it appears to have holes.”.

After some investigation, I found that the filesystem of aarch64 in travis is “shiftfs”[2], but the x86 is “ext4”[3].

So do we have some way to set the file system to ext4 in travis aarch64 arch? or any idea on how to do swapon in current travis aarch64 arch?

[1] https://travis-ci.org/Yikun/arm-openlab-test/jobs/619518155#L81
[2] https://travis-ci.org/Yikun/arm-openlab-test/jobs/619518155#L59
[3] https://travis-ci.org/Yikun/arm-openlab-test/jobs/619518159#L218

@illume

This one was, as it appears, by design - until the job reaches ‘cancellable’ state, the cancel button should not appear.
Some fixes were done on refreshing the view and while job is reaching the ‘cancellable’ state, pending icon/animation should appear now.

Hi @Yikun!

Thanks for testing arm out and the report! Would you mind moving it as a thread to the https://travis-ci.community/c/environments/multi-cpu-arch/96 ? This would help to keep question and answers organized for searches.

On file system change - I am afraid it’s nothing you can do from .travis.yml . Keeping such a thread open may allow other users to see if they have demand for the same feature.

Hi @nigelhorne

Thanks for testing out Arm builds! If the issue persists, would you mind to move it as a thread to https://travis-ci.community/c/environments/multi-cpu-arch/96 and provide link to the build job that actually resulted in that failure? Not much can be done on the error message itself.

Hi @mjnovice

Thanks for testing!
Java setup may be still missing, so if a Java packet needed, please install relevant package in before_install step and make sure environmental variables are set correctly.

Hi all!

First of all, thank you for this great addition to travis-ci. It is really useful for open source software maintainers :heart:.

I would like to share that I noticed something that made me some headaches as a maintainer of a C++ project. The CMake version used in the ARM64 and AMD64 images seems to be different:

  • ARM64 images uses: cmake version 3.5.1
  • AMD64 images uses: cmake version 3.12.4

Why this difference? CMake is the main configuration system used by C++ projects nowadays, and it would avoid issues to have the same version in both images.

Best regards,
Luis

+1 for the fact that arm64 builds are offered. For my project https://travis-ci.com/github/bkimminich/juice-shop they work fine for running an npm install of a not-so-small project. All good there!

-1 when trying to build a Docker image on arm64. A job doing a docker build and push that takes <10min on amd64 is continually running into timeouts on arm64. Sometimes I get a timeout before the docker build is even starting. Sometimes it gets into the build part but then starves at some point.

I could live with arm64 builds being 10 times slower than amd64 as long as I end up with a successfully built and published Docker image. But even travis_wait didn’t do the trick for me. As mentioned, the timeout occurs sometimes even before any of my scripts has been launched.

Are there any performance improvements planned for arm64? Or at least doing x3 on the default timeout? The way it works now, I can’t use it unfortunately, but I really would love to avoid a CI/CD setup with two providers. I had that in the past, but when Travis-CI introduced Windows jobs, I dropped my extra AppVeyor jobs in favor of it.

(see https://github.com/bkimminich/juice-shop/issues/1404 for some more information)