gh-action-pypi-publish
gh-action-pypi-publish copied to clipboard
pypa
Support for ARM runners
The action currently fails to run on the ARM runners GitHub have made available because the Docker image used for releases only is available for the linux/amd64 architecture.
Would it be possible to add support for linux/arm64 as well, please?
It looks like https://github.com/pypa/gh-action-pypi-publish/blob/HEAD/.github/workflows/build-and-push-docker-image.yml is what needs to be edited to accomplish this.
That workflow could potentially be changed to make use of some of the existing actions available for building Docker images, such as what I use here: https://github.com/Tenzer/dockerfiles/blob/main/.github/workflows/uwsgi-werkzeug-echo.yml. I don't know if that would be appreciated or not.
This would increase the support surface area and maintenance burden related to it. So I'm not sure I want to do this.
What's the motivation here, anyway? I noticed that most unusual requests are coming from people refusing to follow the documented and supported way of using the action.
What's the motivation here, anyway?
To be able to run all our CI workflows on the cheaper ARM runners.
I noticed that most unusual requests are coming from people refusing to follow the documented and supported way of using the action.
I don't think it's documented anywhere that this action only works on the x86/amd64 architecture?
My reason for making this issue was also to let you know that ARM runners now is a thing, and due to how this action is made, it won't work on them out of the box, unlike most other actions available.
The docker requirement might be circumvented with a dedicated venv (possibly using uv to init/activate the venv) and migrating to a composite action.
unlike most other actions available
This phrase implies presumptions (👎🏼). I suspect any action using a docker container, especially using custom docker images like this one, would have similar problems. And, a lot of actions use docker containers if they are not driven by JS/TS.
Composite actions were introduced to bypass the limitations of docker containers' isolation (and more).
unlike most other actions available
This phrase implies presumptions (👎🏼). I suspect any action using a docker container, especially using custom docker images like this one, would have similar problems. And, a lot of actions use docker containers if they are not driven by JS/TS.
I just migrated all our workflows to run on ARM runners, and this was the only action that wasn't compatible with them.
Yep. Docker is only available on GNU/Linux runners.
The supported VMs are mentioned @ https://github.com/marketplace/actions/pypi-publish#Non-goals. For many reasons, I'm not open to changing the architecture in here, in particular, that would be encouraging poor security practices. It's currently composite+docker+python.
The only thing I haven't yet considered is supporting ubuntu-24.04-arm. The currently supported image is ubuntu-latest and two steps — download+publish.
@Tenzer do you have any numbers on possible performance / cost gain? Would it overwheigh possible maintenance burden?
They are 37.5% cheaper to use per minute: https://docs.github.com/en/billing/concepts/product-billing/github-actions#per-minute-rates.
Performance-wise, there isn't a big difference by itself; you mainly benefit if your intended output from your build is some ARM64 binaries, in which case they will be much faster than using cross compilation or emulation.
@Tenzer the thing is that building the dists within the same job that uses the action is specifically discouraged. This is because of security challenges when using OIDC and also more generic separation of concerns. A job with a proper supported configuration will already run under a minute or 2 when uploading pure-python projects, and somewhat longer when uploading about a hundred wheels (for platform-specific builds). The builds are supposed to be happening in separate jobs anyway.
I'm not sure that speeding up a job that mostly runs once a month or half a year in most projects from 20 seconds to 15 seconds can justify the maintenance cost for me.