What is the reason that PEP-11 still considers aarch64-apple-darwin a tier-2 platform?
Is this because we don’t have M1 coverage with GitHub Actions? (and is that because of cost considerations?)
Are there other reasons?
Yes, I think this is it. PEP 11 says for tier 1:
Changes which would break the main branch are not allowed to be merged; any breakage should be fixed or reverted immediately.
Which basically means GitHub Actions (or Azure Pipelines or similar) which run for every PR. Buildbots don’t run for every PR before merge, unless requested.
(and is that because of cost considerations?)
Also yes: GitHub Actions only last month added Apple Silicon, and as part of their paid-only “larger runners”. A quick calculation at python/cpython#110307 (comment) suggests it would cost $120/day.
I’ve heard talk of them introducing a free plan for M1 next year, let’s see.
3 Likes
Anyone here works at Apple? Perhaps they would agree to sponsor M1 GHA capacity for cpython?
1 Like
AFAIK, it’s not an option we currently use or have even discussed, but GHA does support the use of self-hosted runners for workflows rather than just using GitHub-hosted ones. So it might be possible to set up an Apple Silicon based runner somewhere, at least perhaps as a temporary measure until and if GitHub provides similar free access to their own Apple Silicon runners. Given the critical nature of the CI build and test checks to the CPython workflow, there would need to be some discussion about how to implement this and it would have to be quite reliable and open, perhaps best hosted in some sort of existing organizational or corporate environment?
That’s $43800/yr. Perhaps too much for the PSF to fully sponsor, but maybe Apple or some other corporate entity could chip in to finance.
1 Like
for comparison, AWS-hosted M1 instances cost between $5k and $10k per host per year (depending on which savings plan is used). any idea how many of those would be needed to meet cpython’s capacity needs?
I suspect the GitHub pricing would be more attractive, since they are able to do co-tenancy, while self-hosted runners will not offer much flexibility in terms of auto-scaling, and would end up being idle a lot of the time.
1 Like
I have no hard data other than my gut feel, perhaps someone else does. But I would guess we could get by with a minimum of 2 instances. The build and test steps normally run fairly quickly on an Apple Silicon Mac and even the smallest configuration should be able to support a few workflows running simultaneously. It certainly would be easier to just default to GitHub-hosted runners. There would need to be a cost vs benefit analysis to acceleratingTier 1 support, “accelerating” since it seems inevitable that GitHub will either have to provide free Apple Silicon runner access similar to the legacy Intel Mac runners, or they will have to change the ground rules for their current open source project support.
1 Like
I’d be careful with a self-hosted macOS runner with CPython’s workflow because AFAIK CI jobs can run before code review. That at the very least requires looking into some solution for isolating jobs and limiting runtime.
5 Likes
Paul Kehrer created GitHub - reaperhulk/cidermill for pyca/cryptography, which uses macOS’s virtualization framework to run untrusted Github Actions jobs.
4 Likes