I'm trying to migrate a project from Travis to Github Actions but I can't find how I specify different architectures. Is this currently not possible? I would preferably run my tests on the host but I've also tried running in a container:
test_linux_arm: runs-on: ubuntu-latest container: image: arm64v8/python:3.7-buster steps: - uses: actions/checkout@v1 - name: Test run: | python -c "import platform; print(platform.machine())"
But this results in the following error:
Error response from daemon: Container d831f6dc0744c2c618042605240808c05550548961a74da377551780beea96bc is not running
Here is how it is done on Travis: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
GitHub hosts Linux and Windows runners on Standard_DS2_v2 virtual machines in Microsoft Azure with the GitHub Actions runner application installed. Looks like it does not support to specify different CPU architectures (such as ARM architectures) when using the GitHub-hosted runners.
You can reference here to get more details: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments...
However, self-hosted runners can support to specify architectures via the runner labels. You can try to install some self-hosted runners with different CPU architectures.
More details about self-hosted runners, reference here: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/using-self-hosted-ru...
That's really too bad since that is the only blocker for migrating from Travis and I'm currently not able to setup a self-hosted runner :/ Would be great with atleast a roadmap to see how far off it is.
As was already mentioned, there is not first class support for this yet, but I have some ideas that may help you along
Ive used multiarch/qemu-user-static (https://github.com/multiarch/qemu-user-static) in the past to run multi arch image on one linux host, like:
steps: - run: | docker run --rm --privileged multiarch/qemu-user-static:register --reset
The big problem with this is we try to start containers before the steps run, so if you use this the host will not be set up by the time it tries to start your arm64 container. Heres more of my sample:
jobs: build: runs-on: ubuntu-latest steps: - run: docker run --rm --privileged multiarch/qemu-user-static:register --reset - uses: docker://multiarch/ubuntu-core:arm64-bionic with: args: 'uname -a' - uses: actions/checkout@v1 - uses: docker://multiarch/ubuntu-core:arm64-bionic with: args: 'bash -c "apt-get update && apt-get install -y coreutils curl git && cd ./src .....'
This would check out your repo, mounted into the container, and execute your "args" inside
Thank you, this looks like an okay temporary workaround. Do you have any tips on how to quickly setup the latest Python inside the container? I can't find any image available that already has it setup (so maybe I should create my own).
In the example I posted above, its using the multiarch/ubuntu-core:arm64-bionic image, so if you also use that you can install python like you normally would on any ubuntu system, which should be something like:
apt-get install python3.6
but theres plenty of existing docs out there for how to install various versions of python on different operating systems, but heres at least one example
jobs: build: runs-on: ubuntu-latest steps: - run: | docker run --rm --privileged multiarch/qemu-user-static:register --reset - uses: docker://multiarch/ubuntu-core:arm64-bionic with: args: 'uname -a' - uses: docker://multiarch/ubuntu-core:arm64-bionic with: args: > bash -c "apt-get update && apt-get install -y python3.6 && python3.6 --version && python3.6 -c\"import platform; print(platform.machine())\""
after some logs from apt, this prints:
The formatting is funky indeed and there may be possible improvements. But, going off my previous example, you could also run checkout at any point and then run scripts from your repo, since the container actions have the source directory mapped in and set as the working directory (./script.sh should refer to script.sh at the root of your repo)
The multiarch images appear to be separated by OS (ubuntu-core) and then tagged by arch-release_codename so the python installation will likely depend mostly on the image (OS) and youll likely just get the correct architecture automatically, for python as shown above it certainly seemed to.
I don't know all the details but that won't work unless you install qemu on the vm. So you might need to manually install qemu, set up binfmt and then start the container manually.