GitHub Actions ARM32 Support Ending December 2026: CI Migration Guide
GitHub announced on November 12, 2026 that its hosted Actions runners will end ARM32 job execution on Linux and Windows by December 8, 2026. The change includes native AArch32 user-space execution on hosted runners. GitHub connects the timing to the move away from Node 20 and notes that Node 24 does not support ARM32.
Which CI jobs need attention?
Search workflows, reusable workflows, composite actions, Dockerfiles and build scripts. A job may look like an ordinary ARM64 build while a step launches a 32-bit executable. Look for ARMv7, AArch32, armhf, linux-arm, platform settings and tests that run compiled ARM32 outputs. Inspect downloaded tooling and third-party actions, too.
| Existing dependency | Migration target | Verification |
|---|---|---|
| ARM32 executable used only as a build tool | ARM64 or x64 build-tool release | Run the exact tool and record its architecture |
| App supported on ARM64 | ARM64 artifact and ARM64 test job | Verify native dependencies, runtime and target hardware |
| Product still ships to ARM32 devices | Supported cross-build environment and a separate controlled test target | Run the built artifact on representative ARM32 hardware |
| Action tied to Node 20 | Maintained action compatible with the current runner runtime | Review the action’s metadata and release notes |
An ARM64 runner can build artifacts for another target when its toolchain supports that target. A successful build is evidence of compilation. Runtime compatibility still depends on executing the artifact under a representative environment. Moving a job to ARM64 also changes the artifacts it produces if you switch the .NET Runtime Identifier from linux-arm to linux-arm64.
Inventory the repository before editing jobs
git grep -inE 'arm32|armv7|armhf|aarch32|linux-arm([^[:alnum:]]|$)|win-arm([^[:alnum:]]|$)|node20' \
-- .github Dockerfile scriptsReview hits with context. A historical README mention is different from an executable test step. Check build and runtime dependencies separately, then group each hit into replace, cross-build or hardware-test.
Example ARM64 build for a supported Linux target
The following uses a documented hosted label. Confirm that your repository can select it and that the project targets .NET 10. Substitute your project path when the repository contains multiple projects.
name: Linux ARM64 build
on:
push:
workflow_dispatch:
permissions:
contents: read
jobs:
build:
runs-on: ubuntu-24.04-arm
steps:
- uses: actions/checkout@v5
- uses: actions/setup-dotnet@v5
with:
dotnet-version: '10.0.x'
- name: Verify runner architecture
run: test "$(uname -m)" = aarch64
- name: Publish ARM64 artifact
run: dotnet publish -c Release -r linux-arm64 --self-contained falseAdd an executable smoke test for your published output on the intended runner or device. A framework-dependent output requires a compatible installed runtime. For a production workflow, pin reviewed action revisions according to your organization’s supply-chain policy. Keep a canary workflow and compare artifact checksums, dependency loading and smoke-test results before replacing the release path.
How to handle remaining ARM32 devices
Use a controlled device test stage with restricted access and an auditable artifact handoff. A self-hosted ARM64 runner can dispatch tests to hardware without requiring the Actions runner process itself to run as ARM32. Review what GitHub supports for the runner host and action runtime independently. Avoid running untrusted pull requests on a runner with device credentials or direct access to internal networks.
Does this end support for every ARM32 build? The announcement targets hosted job execution. Cross-compilation remains a separate toolchain question. Validate cross-built outputs on representative devices.
Does the change retire ARM64 hosted runners? The announcement covers ARM32. Review the hosted-runner reference for available ARM64 labels and repository eligibility.
Comments
Post a Comment