Migration of CI for ARM
kimikage opened this issue · comments
We've aggregated the major CI jobs into GitHub Actions, in terms of speed and UI integrity (PR #204).
However, the GitHub-hosted runners (i.e. non-self-hosted runners) do not support ARM architecture. For this reason, we currently use Travis CI for arm64 (aarch64).
We currently have two problems with Travis CI. (cf. #204 (comment))
One is that FixedPointNumbers.jl uses the old "travis-ci.org" and needs to be migrated to "travis-ci.com" by the end of this year.
The other is that Travis CI's pricing plan has been changed. (https://discourse.julialang.org/t/travis-ci-changes-pricing-plans/49528)
I tried out the Drone Cloud as a free CI service that supports the ARM architecture.
(cf. https://cloud.drone.io/kimikage/ColorBlendModes.jl/5)
Are there any other good tools out there?
An alternative is to build an arm docker container in github action, an example can be found in https://github.com/johnnychen94/jill.py/blob/67c5f68bb792f82f86526012fe837bc9a10a96a2/.github/workflows/pythonapp.yml#L146-L175
Do you want me to submit the PR or you want to try it out yourself? (I could do it this weekend)
It's nice to have everything done in GitHub Actions. However, IIUC, the method you showed me uses QEMU.
That's true for the case with Drone Cloud as well, but the limitations in Docker Hub also started. 😕
Oh yes, it could be a potential issue. But we could try it out and see how frequently we reach the request limits without logining in docker hub. If it happens too frequently then we might need to register a docker hub account and configure the login in the github action file.
The uraimo/run-on-arch-action itself seems to be using GitHub Packages instead of Docker Hub. However, the future of GitHub Packages is also uncertain, as it is planned to move to the GitHub Container Registry.
There have been a bunch of changes to DevOps infrastructures over the past few months and I'm still not exactly up to date on the situation. 😅
I think it's worth a try to see how long it takes with run-on-arch-action.
I don't know what the future holds, but using GitHub Actions seems to be the least uncertain risk. Since the deadline is approaching, I'd like to try the method first.
Since these only affect us maintainers and won't affect any users of this package, please don't hesitate to do this 🚀