Since Azure started enabling arm64 virtual machines (april 2022), we have been investigating how to use them to implement CI/CD for external projects, using Github Actions and /Azure pipelines and self-hosted runners/agents.
...
A runner (or azure agent) is currently registered only for one project or organization. It implies that that you can’t reuse the same runner for different organizations/projects.
⚠️ Potential solution
Run one runner for every project/organization we plan to support. This does not scale very well, and does not ensure a single machine runs a single job at a time (several runners → several jobs running at the same time on the same machine).
...
Github-hosted runners (and Azure-hosted), on the opposite, offers this isolation, butthere is no arm64 runner available yet.
...
Scaling
To avoid huge costs on our cloud infrastructure, we need to be able to start/stop VM on demand, when a new job asks to run.
...
A scale set is attached to a paid subscription, which ensures payment. Alas, it’s not possible to share a scale set (nor subscription) between different projects/organizations.
❌ No Github solution
On Github, autoscaling is supported through two different projects:
...
Actions-runner-controller relies on Kubernetes, which means it uses containers. Alas, Azure Kubernetes is not supported yet for Windows on Arm. https://github.com/Azure/AKS/issues/1613
The second option, based on AWS and full VM, does not support Azure.
It means we have no solution yet for a Windows On Arm/Azure environment.
...
Those challenges are already handled by Azure/Github runners, but there is no support for arm64/windows on arm yet https://github.com/actions/virtual-environments .
...