Identifying GitHub Actions Workflows Affected by ARM32 Runner Changes

Niharika Gupta

GitHub Actions workflows often run unnoticed for months or even years. A pipeline may build an application, execute tests, publish packages, or deploy software without requiring regular changes. However, changes to runner architecture support can affect these workflows even when the application code remains exactly the same.

One such change concerns ARM32 execution in GitHub Actions. GitHub has announced that hosted runners will end support for ARM32 job execution on Windows and Linux. The retirement is connected to the transition from Node.js 20 to Node.js 24 because Node.js 24 does not officially support ARM32.

For teams maintaining multiple repositories, the challenge is identifying which workflows actually depend on ARM32. Searching for a particular runner label is not always enough. Architecture can be selected through self-hosted runner labels, build matrices, container images, shell scripts, or external actions.

This article explains how to identify potentially affected workflows, inspect their architecture dependencies, and prepare a migration plan without unnecessarily changing ARM64 or x64 pipelines.

Understanding the ARM32 Runner Change

ARM is a processor architecture family used in embedded devices, single-board computers, mobile devices, and other hardware platforms.

ARM32 and ARM64 are different instruction-set architectures:

ARM32, also known as AArch32, uses a 32-bit execution environment.
ARM64, also known as AArch64, uses a 64-bit execution environment.
x64 is the 64-bit architecture commonly used by Intel and AMD desktop and server processors.

The distinction matters because a workflow that builds software for ARM32 is not necessarily running on an ARM32 runner.

For example, an x64 GitHub-hosted runner can cross-compile an application for a 32-bit ARM device. That workflow may continue working because its execution environment is x64, even though its output targets ARM32.

The announced retirement concerns native ARM32 user-space execution on hosted Linux and Windows runners. It should not be interpreted as the removal of ARM64 support or as a general restriction on producing ARM32 binaries.

Why Node.js 24 matters

GitHub Actions uses JavaScript runtimes to execute JavaScript-based actions. Many commonly used actions are implemented using Node.js.

The transition to Node.js 24 introduces an architecture compatibility issue because Node.js 24 does not officially support ARM32. Consequently, actions that move to Node.js 24 cannot be assumed to work in an ARM32 execution environment.

This is particularly relevant when a workflow uses several third-party actions. A workflow might not explicitly mention Node.js, but its actions may depend on it internally.

GitHub announced that hosted runners will end ARM32 job execution support on Windows and Linux by December 8, 2026.

The practical implication is that teams should identify ARM32 dependencies before the retirement rather than waiting for workflows to fail.

Which GitHub Actions Workflows Should You Review?

Not every workflow that mentions ARM is affected. The important question is whether the workflow depends on ARM32 execution.

Start by reviewing the following categories.

Workflows using ARM32 self-hosted runners

A workflow can select a self-hosted runner through labels.

For example:

name: ARM32 Build

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: [self-hosted, linux, ARM32]

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Build application
        run: ./build.sh

The ARM32 label is a strong indication that the workflow expects a runner with that architecture.

However, labels are user-defined. A label named ARM32 does not automatically prove the underlying machine is ARM32. An administrator could have assigned that label to a different architecture.

Verify the actual runner hardware and operating system before deciding whether the workflow is affected.

You should also inspect organization-level and repository-level runner groups. A workflow may use a generic label such as embedded-linux or hardware-builder instead of explicitly mentioning ARM32.

Workflows using architecture-specific build matrices

A build matrix can define multiple target architectures.

For example:

name: Multi-Architecture Build

on:
  push:
    branches:
      - main

jobs:
  build:
    strategy:
      matrix:
        architecture:
          - x64
          - arm32
          - arm64

    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Display target architecture
        run: echo "Building for ${{ matrix.architecture }}"

This workflow runs on an Ubuntu x64 hosted runner. Its matrix includes ARM32, but that does not mean the job itself executes on ARM32 hardware.

The distinction is important:

Runner architecture determines where the workflow commands execute.
Target architecture determines the architecture for which the application is built.

A cross-compilation workflow may continue to build ARM32 software using an x64 or ARM64 runner, provided its compiler, dependencies, and build environment support that target.

Do not remove ARM32 matrix entries automatically. First establish whether the workflow uses native execution or cross-compilation.

Workflows using ARM32 container images

Container images can introduce architecture dependencies even when the runner itself is not ARM32.

Consider this example:

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: arm32v7/python:3.11

    steps:
      - name: Run tests
        run: python -m pytest

The workflow explicitly requests an ARM32 container image.

Whether this works depends on the runner architecture, container runtime, image compatibility, and any emulation configured in the environment.

An ARM32 container reference is therefore worth investigating, but it does not prove that the workflow requires an ARM32 hosted runner.

Review Dockerfiles, image manifests, build scripts, and container execution settings to understand the actual dependency.

Workflows using third-party actions

A workflow may not contain any architecture-specific configuration but can still depend on actions that are incompatible with its execution environment.

For example:

jobs:
  build:
    runs-on: [self-hosted, linux, ARM32]

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24

      - run: npm install
      - run: npm test

The workflow uses a JavaScript-based action and requests Node.js 24. On an ARM32 execution environment, this creates a compatibility concern.

Review the runtime requirements of actions used in affected jobs. Check their release notes and action metadata rather than assuming that every version of an action supports every runner architecture.

Also remember that actions can depend on other actions or bundled binaries. Inspect the complete dependency chain when an action has architecture-specific requirements.

How to Find Potentially Affected Workflows

The first step is to create an inventory of workflow files across your repositories.

GitHub workflow definitions are generally stored in the .github/workflows directory.

For a repository checked out locally, use the following commands to search for architecture-related references:

grep -RniE \
  'arm32|armv7|armv7l|aarch32|armhf|linux/arm/v7' \
  .github/workflows

This search can identify common ARM32 references in workflow files.

You can also search for self-hosted runner labels:

grep -RniE \
  'self-hosted|runs-on|arm32|armv7|armhf' \
  .github/workflows

These commands are useful for an initial investigation, but they are not a complete architecture audit.

A workflow may inherit runner information through reusable workflows, use expressions to construct labels, or define architecture settings in another file.

Search across multiple repositories

For organizations with many repositories, checking each repository manually is inefficient.

GitHub CLI can help you list repositories:

gh repo list ORGANIZATION_NAME \
  --limit 200 \
  --json nameWithOwner \
  --jq '.[].nameWithOwner'

After obtaining the repository list, you can clone or inspect repositories and search their workflow definitions.

For example:

gh repo clone ORGANIZATION_NAME/REPOSITORY_NAME

cd REPOSITORY_NAME

grep -RniE \
  'arm32|armv7|armv7l|aarch32|armhf' \
  .github/workflows

For a large organization, consider automating this process and storing the results in a central inventory.

The inventory should include the repository name, workflow file, job name, runner labels, architecture references, container images, and review status.

Automating ARM32 Reference Detection

A small Python script can scan workflow files and report common ARM32 references.

The following example searches YAML files under .github/workflows:

from pathlib import Path
import re

workflow_directory = Path(".github/workflows")

patterns = {
    "ARM32": r"\barm32\b",
    "ARMv7": r"\barmv7l?\b",
    "AArch32": r"\baarch32\b",
    "ARMHF": r"\barmhf\b",
    "ARM32 Docker": r"linux/arm/v7",
}

if not workflow_directory.exists():
    print("Workflow directory not found.")
    raise SystemExit(1)

for file_path in workflow_directory.rglob("*.yml"):
    content = file_path.read_text(
        encoding="utf-8",
        errors="ignore"
    )

    for architecture, pattern in patterns.items():
        matches = list(
            re.finditer(pattern, content, re.IGNORECASE)
        )

        for match in matches:
            line_number = content[:match.start()].count("\n") + 1

            print(
                f"{file_path}:{line_number} "
                f"Potential {architecture} reference"
            )

for file_path in workflow_directory.rglob("*.yaml"):
    content = file_path.read_text(
        encoding="utf-8",
        errors="ignore"
    )

    for architecture, pattern in patterns.items():
        matches = list(
            re.finditer(pattern, content, re.IGNORECASE)
        )

        for match in matches:
            line_number = content[:match.start()].count("\n") + 1

            print(
                f"{file_path}:{line_number} "
                f"Potential {architecture} reference"
            )

Save the script as scan_workflows.py and execute it from the repository root:

python scan_workflows.py

A possible result might look like this:

.github/workflows/embedded-build.yml:12 Potential ARM32 reference
.github/workflows/device-tests.yaml:8 Potential ARMv7 reference
.github/workflows/docker-build.yml:19 Potential ARM32 Docker reference

This script is a discovery tool, not a compatibility checker. It identifies text references but cannot determine whether a job executes natively on ARM32.

For a more advanced implementation, parse workflow YAML and inspect the runs-on property, job-level container configuration, matrix definitions, and reusable workflow references separately.

You should also account for indirect dependencies that are defined outside the workflow files.

How to Verify the Actual Runner Architecture

After identifying possible matches, verify the architecture of the machine executing the job.

For Linux runners, add a temporary diagnostic step:

- name: Inspect runner architecture
  run: |
    uname -a
    uname -m
    getconf LONG_BIT
    lscpu

Common output values include:

Command output	Meaning
x86_64	64-bit x86 architecture
aarch64	64-bit ARM architecture
armv7l	32-bit ARM architecture
32 from getconf	32-bit user-space environment
64 from getconf	64-bit user-space environment

The uname command reports the kernel architecture. The getconf command provides information about the user-space environment.

For a more complete investigation, inspect both the operating system and the architecture of important tools installed on the runner.

For example:

- name: Inspect tool architectures
  run: |
    uname -m
    node --version || true
    file "$(command -v node)" || true
    docker version || true

The presence of an ARM32 binary in a repository does not establish that the runner is ARM32. Likewise, an ARM64 runner can build an ARM32 application without necessarily executing ARM32 binaries.

On Windows, inspect the operating system and processor architecture using PowerShell:

- name: Inspect Windows architecture
  shell: pwsh
  run: |
    Get-CimInstance Win32_OperatingSystem |
      Select-Object OSArchitecture

    Get-CimInstance Win32_Processor |
      Select-Object Name, Architecture

Run these checks on the actual runner used by the job. Checking a developer's local machine or a different CI environment will not establish the workflow's execution architecture.

Distinguishing ARM32 Workloads From ARM64 Workloads

One of the most common mistakes during architecture migrations is treating ARM32 and ARM64 as interchangeable.

They are not interchangeable, and the retirement announcement should not lead teams to remove working ARM64 jobs.

Consider the following examples:

Workflow configuration	What it indicates	Initial assessment
Self-hosted runner labeled ARM32	Possible ARM32 execution	Investigate
Self-hosted runner labeled ARM64	ARM64 execution	Not directly affected by ARM32 retirement
ubuntu-latest with ARM32 cross-compilation	x64 hosted execution targeting ARM32	Not automatically affected
ubuntu-24.04-arm	ARM64 hosted execution	Not directly affected
ARM32 Docker image on x64 runner	Architecture-specific container dependency	Investigate
x64 build producing ARM32 binaries	Cross-compilation	Not automatically affected

The key is to identify where ARM32 is used.

A workflow may contain ARM32 references in its output configuration, compiler flags, package names, or deployment scripts without executing ARM32 instructions.

For example, a compiler command might look like this:

arm-linux-gnueabihf-gcc \
  -o application \
  main.c

This command uses a cross-compiler to generate an ARM32 binary. It does not necessarily require an ARM32 runner.

The workflow can continue using an appropriate x64 or ARM64 runner if the cross-compilation toolchain and dependencies are compatible.

Preparing a Migration Plan

Once you have identified affected workflows, classify them according to their actual execution requirements.

Move compatible workloads to ARM64

If the application supports ARM64, moving the workflow to an ARM64 runner may be a practical option.

For example:

jobs:
  build:
    runs-on: ubuntu-24.04-arm

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Build application
        run: ./build.sh

Before migrating, verify that your dependencies, native libraries, compiler toolchains, and third-party actions support ARM64.

Changing the runner label alone does not guarantee that the application will work.

Use cross-compilation when native ARM32 execution is unnecessary

Some projects need to generate ARM32 binaries but do not need to execute them during the build.

In such cases, an x64 runner with an appropriate cross-compilation toolchain may be sufficient.

For example:

jobs:
  build-arm32:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Install ARM32 compiler
        run: |
          sudo apt-get update
          sudo apt-get install -y \
            gcc-arm-linux-gnueabihf

      - name: Compile application
        run: |
          arm-linux-gnueabihf-gcc \
            -o application \
            main.c

This approach separates the build machine architecture from the target application architecture.

However, if the workflow must execute the resulting ARM32 binary, additional testing infrastructure is required.

Move hardware-dependent tests to suitable infrastructure

Some projects require native ARM32 execution because they test hardware-specific behavior, device drivers, system libraries, or embedded applications.

Cross-compilation alone cannot replace these tests.

Depending on the project, alternatives may include:

Dedicated physical ARM32 hardware.
A compatible external CI environment.
A supported virtualization or emulation setup.
A custom testing environment managed by the engineering team.

Before choosing an alternative, validate its compatibility with the operating system, required instruction sets, native dependencies, and test workload.

Do not assume that an emulator will reproduce every hardware-specific behavior.

Review JavaScript actions and their runtime requirements

For workflows that must continue running on ARM32 infrastructure outside GitHub-hosted runners, inspect the JavaScript actions they use.

Check whether the action supports Node.js 24 and whether its runtime dependencies support the target architecture.

An action that works on an x64 runner may not work on an ARM32 machine. The same applies to downloaded command-line tools and native dependencies.

Keeping an older JavaScript runtime indefinitely is not a reliable migration strategy. Review supported action versions and plan the required infrastructure changes.

Common Mistakes to Avoid

Removing every ARM32 reference

An ARM32 compiler target does not mean the workflow runs on ARM32 hardware. Removing all ARM32-related build configurations can break legitimate cross-compilation pipelines.

Inspect the execution environment before changing the workflow.

Assuming ARM64 is affected

ARM32 and ARM64 have different compatibility requirements. The announced retirement is specifically about ARM32 execution on hosted Linux and Windows runners.

Do not migrate ARM64 jobs unnecessarily.

Checking only runs-on

The runs-on property is important, but it is not the only place where architecture dependencies appear.

Inspect containers, reusable workflows, matrices, scripts, action dependencies, and external build tools.

Assuming an action version supports every architecture

An action's version number does not establish compatibility with ARM32. Review its runtime declaration, release notes, dependencies, and supported platforms.

Waiting for a workflow failure

A workflow can remain successful until a runner or action runtime changes. Waiting for the first failure can create avoidable interruptions to builds and deployments.

Complete the inventory and test the migration before the retirement takes effect.

Best Practices for Managing Runner Architecture Changes

A structured approach makes architecture migrations easier to manage.

Practice	Why it matters
Maintain a workflow inventory	Helps identify repositories and jobs that depend on specific architectures
Use explicit runner labels	Makes runner requirements easier to understand
Separate host and target architectures	Prevents unnecessary migration of cross-compilation workflows
Pin action versions responsibly	Makes changes easier to review and test
Review third-party action runtimes	Identifies dependencies that may not support the target architecture
Test on the replacement environment	Finds compatibility problems before production CI is affected
Monitor workflow failures	Helps identify unexpected changes after migration
Document hardware dependencies	Makes future infrastructure changes easier to plan

It is also useful to include architecture information in CI logs. Recording the operating system, processor architecture, runtime versions, and compiler versions makes troubleshooting easier when a workflow behaves differently across environments.

Conclusion

The ARM32 changes in GitHub Actions are a reminder that CI/CD compatibility depends on more than workflow syntax and application code. Runner architecture, JavaScript runtimes, container images, native dependencies, and build tools can all influence whether a workflow continues to work.

Start by searching workflow files for ARM32-related references, then verify the actual execution architecture. Separate native ARM32 workloads from cross-compilation jobs and ARM64 workloads before making changes.

For compatible workloads, consider moving to ARM64 or using cross-compilation. For hardware-dependent tests, evaluate dedicated hardware or another supported execution environment.

Most importantly, treat architecture detection as an inventory and verification task rather than a simple text replacement. This approach helps teams prepare for runner changes while keeping unaffected builds and deployments running as expected.

GitHub ActionsARM32 runnersCI/CDself-hosted runnersNode.js 24workflow migration

Comments

Join the conversation! Your thoughts help the community grow.

Identifying GitHub Actions Workflows Affected by ARM32 Runner Changes

Niharika Gupta

1h300100Article

This article explains how to identify potentially affected workflows, inspect their architecture dependencies, and prepare a migration plan without unnecessarily changing ARM64 or x64 pipelines.

Understanding the ARM32 Runner Change

ARM is a processor architecture family used in embedded devices, single-board computers, mobile devices, and other hardware platforms.

ARM32 and ARM64 are different instruction-set architectures:

ARM32, also known as AArch32, uses a 32-bit execution environment.
ARM64, also known as AArch64, uses a 64-bit execution environment.
x64 is the 64-bit architecture commonly used by Intel and AMD desktop and server processors.

The distinction matters because a workflow that builds software for ARM32 is not necessarily running on an ARM32 runner.

Why Node.js 24 matters

GitHub Actions uses JavaScript runtimes to execute JavaScript-based actions. Many commonly used actions are implemented using Node.js.

This is particularly relevant when a workflow uses several third-party actions. A workflow might not explicitly mention Node.js, but its actions may depend on it internally.

GitHub announced that hosted runners will end ARM32 job execution support on Windows and Linux by December 8, 2026.

The practical implication is that teams should identify ARM32 dependencies before the retirement rather than waiting for workflows to fail.

Which GitHub Actions Workflows Should You Review?

Not every workflow that mentions ARM is affected. The important question is whether the workflow depends on ARM32 execution.

Start by reviewing the following categories.

Workflows using ARM32 self-hosted runners

A workflow can select a self-hosted runner through labels.

For example:

name: ARM32 Build

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: [self-hosted, linux, ARM32]

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Build application
        run: ./build.sh

The ARM32 label is a strong indication that the workflow expects a runner with that architecture.

However, labels are user-defined. A label named ARM32 does not automatically prove the underlying machine is ARM32. An administrator could have assigned that label to a different architecture.

Verify the actual runner hardware and operating system before deciding whether the workflow is affected.

You should also inspect organization-level and repository-level runner groups. A workflow may use a generic label such as embedded-linux or hardware-builder instead of explicitly mentioning ARM32.

Workflows using architecture-specific build matrices

A build matrix can define multiple target architectures.

For example:

name: Multi-Architecture Build

on:
  push:
    branches:
      - main

jobs:
  build:
    strategy:
      matrix:
        architecture:
          - x64
          - arm32
          - arm64

    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Display target architecture
        run: echo "Building for ${{ matrix.architecture }}"

This workflow runs on an Ubuntu x64 hosted runner. Its matrix includes ARM32, but that does not mean the job itself executes on ARM32 hardware.

The distinction is important:

Runner architecture determines where the workflow commands execute.
Target architecture determines the architecture for which the application is built.

A cross-compilation workflow may continue to build ARM32 software using an x64 or ARM64 runner, provided its compiler, dependencies, and build environment support that target.

Do not remove ARM32 matrix entries automatically. First establish whether the workflow uses native execution or cross-compilation.

Workflows using ARM32 container images

Container images can introduce architecture dependencies even when the runner itself is not ARM32.

Consider this example:

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: arm32v7/python:3.11

    steps:
      - name: Run tests
        run: python -m pytest

The workflow explicitly requests an ARM32 container image.

Whether this works depends on the runner architecture, container runtime, image compatibility, and any emulation configured in the environment.

An ARM32 container reference is therefore worth investigating, but it does not prove that the workflow requires an ARM32 hosted runner.

Review Dockerfiles, image manifests, build scripts, and container execution settings to understand the actual dependency.

Workflows using third-party actions

A workflow may not contain any architecture-specific configuration but can still depend on actions that are incompatible with its execution environment.

For example:

jobs:
  build:
    runs-on: [self-hosted, linux, ARM32]

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24

      - run: npm install
      - run: npm test

The workflow uses a JavaScript-based action and requests Node.js 24. On an ARM32 execution environment, this creates a compatibility concern.

Also remember that actions can depend on other actions or bundled binaries. Inspect the complete dependency chain when an action has architecture-specific requirements.

How to Find Potentially Affected Workflows

The first step is to create an inventory of workflow files across your repositories.

GitHub workflow definitions are generally stored in the .github/workflows directory.

For a repository checked out locally, use the following commands to search for architecture-related references:

grep -RniE \
  'arm32|armv7|armv7l|aarch32|armhf|linux/arm/v7' \
  .github/workflows

This search can identify common ARM32 references in workflow files.

You can also search for self-hosted runner labels:

grep -RniE \
  'self-hosted|runs-on|arm32|armv7|armhf' \
  .github/workflows

These commands are useful for an initial investigation, but they are not a complete architecture audit.

A workflow may inherit runner information through reusable workflows, use expressions to construct labels, or define architecture settings in another file.

Search across multiple repositories

For organizations with many repositories, checking each repository manually is inefficient.

GitHub CLI can help you list repositories:

gh repo list ORGANIZATION_NAME \
  --limit 200 \
  --json nameWithOwner \
  --jq '.[].nameWithOwner'

After obtaining the repository list, you can clone or inspect repositories and search their workflow definitions.

For example:

gh repo clone ORGANIZATION_NAME/REPOSITORY_NAME

cd REPOSITORY_NAME

grep -RniE \
  'arm32|armv7|armv7l|aarch32|armhf' \
  .github/workflows

For a large organization, consider automating this process and storing the results in a central inventory.

The inventory should include the repository name, workflow file, job name, runner labels, architecture references, container images, and review status.

Automating ARM32 Reference Detection

A small Python script can scan workflow files and report common ARM32 references.

The following example searches YAML files under .github/workflows:

from pathlib import Path
import re

workflow_directory = Path(".github/workflows")

patterns = {
    "ARM32": r"\barm32\b",
    "ARMv7": r"\barmv7l?\b",
    "AArch32": r"\baarch32\b",
    "ARMHF": r"\barmhf\b",
    "ARM32 Docker": r"linux/arm/v7",
}

if not workflow_directory.exists():
    print("Workflow directory not found.")
    raise SystemExit(1)

for file_path in workflow_directory.rglob("*.yml"):
    content = file_path.read_text(
        encoding="utf-8",
        errors="ignore"
    )

    for architecture, pattern in patterns.items():
        matches = list(
            re.finditer(pattern, content, re.IGNORECASE)
        )

        for match in matches:
            line_number = content[:match.start()].count("\n") + 1

            print(
                f"{file_path}:{line_number} "
                f"Potential {architecture} reference"
            )

for file_path in workflow_directory.rglob("*.yaml"):
    content = file_path.read_text(
        encoding="utf-8",
        errors="ignore"
    )

    for architecture, pattern in patterns.items():
        matches = list(
            re.finditer(pattern, content, re.IGNORECASE)
        )

        for match in matches:
            line_number = content[:match.start()].count("\n") + 1

            print(
                f"{file_path}:{line_number} "
                f"Potential {architecture} reference"
            )

Save the script as scan_workflows.py and execute it from the repository root:

python scan_workflows.py

A possible result might look like this:

.github/workflows/embedded-build.yml:12 Potential ARM32 reference
.github/workflows/device-tests.yaml:8 Potential ARMv7 reference
.github/workflows/docker-build.yml:19 Potential ARM32 Docker reference

This script is a discovery tool, not a compatibility checker. It identifies text references but cannot determine whether a job executes natively on ARM32.

For a more advanced implementation, parse workflow YAML and inspect the runs-on property, job-level container configuration, matrix definitions, and reusable workflow references separately.

You should also account for indirect dependencies that are defined outside the workflow files.

How to Verify the Actual Runner Architecture

After identifying possible matches, verify the architecture of the machine executing the job.

For Linux runners, add a temporary diagnostic step:

- name: Inspect runner architecture
  run: |
    uname -a
    uname -m
    getconf LONG_BIT
    lscpu

Common output values include:

Command output	Meaning
x86_64	64-bit x86 architecture
aarch64	64-bit ARM architecture
armv7l	32-bit ARM architecture
32 from getconf	32-bit user-space environment
64 from getconf	64-bit user-space environment

The uname command reports the kernel architecture. The getconf command provides information about the user-space environment.

For a more complete investigation, inspect both the operating system and the architecture of important tools installed on the runner.

For example:

- name: Inspect tool architectures
  run: |
    uname -m
    node --version || true
    file "$(command -v node)" || true
    docker version || true

The presence of an ARM32 binary in a repository does not establish that the runner is ARM32. Likewise, an ARM64 runner can build an ARM32 application without necessarily executing ARM32 binaries.

On Windows, inspect the operating system and processor architecture using PowerShell:

- name: Inspect Windows architecture
  shell: pwsh
  run: |
    Get-CimInstance Win32_OperatingSystem |
      Select-Object OSArchitecture

    Get-CimInstance Win32_Processor |
      Select-Object Name, Architecture

Run these checks on the actual runner used by the job. Checking a developer's local machine or a different CI environment will not establish the workflow's execution architecture.

Distinguishing ARM32 Workloads From ARM64 Workloads

One of the most common mistakes during architecture migrations is treating ARM32 and ARM64 as interchangeable.

They are not interchangeable, and the retirement announcement should not lead teams to remove working ARM64 jobs.

Consider the following examples:

Workflow configuration	What it indicates	Initial assessment
Self-hosted runner labeled ARM32	Possible ARM32 execution	Investigate
Self-hosted runner labeled ARM64	ARM64 execution	Not directly affected by ARM32 retirement
ubuntu-latest with ARM32 cross-compilation	x64 hosted execution targeting ARM32	Not automatically affected
ubuntu-24.04-arm	ARM64 hosted execution	Not directly affected
ARM32 Docker image on x64 runner	Architecture-specific container dependency	Investigate
x64 build producing ARM32 binaries	Cross-compilation	Not automatically affected

The key is to identify where ARM32 is used.

A workflow may contain ARM32 references in its output configuration, compiler flags, package names, or deployment scripts without executing ARM32 instructions.

For example, a compiler command might look like this:

arm-linux-gnueabihf-gcc \
  -o application \
  main.c

This command uses a cross-compiler to generate an ARM32 binary. It does not necessarily require an ARM32 runner.

The workflow can continue using an appropriate x64 or ARM64 runner if the cross-compilation toolchain and dependencies are compatible.

Preparing a Migration Plan

Once you have identified affected workflows, classify them according to their actual execution requirements.

Move compatible workloads to ARM64

If the application supports ARM64, moving the workflow to an ARM64 runner may be a practical option.

For example:

jobs:
  build:
    runs-on: ubuntu-24.04-arm

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Build application
        run: ./build.sh

Before migrating, verify that your dependencies, native libraries, compiler toolchains, and third-party actions support ARM64.

Changing the runner label alone does not guarantee that the application will work.

Use cross-compilation when native ARM32 execution is unnecessary

Some projects need to generate ARM32 binaries but do not need to execute them during the build.

In such cases, an x64 runner with an appropriate cross-compilation toolchain may be sufficient.

For example:

jobs:
  build-arm32:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Install ARM32 compiler
        run: |
          sudo apt-get update
          sudo apt-get install -y \
            gcc-arm-linux-gnueabihf

      - name: Compile application
        run: |
          arm-linux-gnueabihf-gcc \
            -o application \
            main.c

This approach separates the build machine architecture from the target application architecture.

However, if the workflow must execute the resulting ARM32 binary, additional testing infrastructure is required.

Move hardware-dependent tests to suitable infrastructure

Some projects require native ARM32 execution because they test hardware-specific behavior, device drivers, system libraries, or embedded applications.

Cross-compilation alone cannot replace these tests.

Depending on the project, alternatives may include:

Dedicated physical ARM32 hardware.
A compatible external CI environment.
A supported virtualization or emulation setup.
A custom testing environment managed by the engineering team.

Before choosing an alternative, validate its compatibility with the operating system, required instruction sets, native dependencies, and test workload.

Do not assume that an emulator will reproduce every hardware-specific behavior.

Review JavaScript actions and their runtime requirements

For workflows that must continue running on ARM32 infrastructure outside GitHub-hosted runners, inspect the JavaScript actions they use.

Check whether the action supports Node.js 24 and whether its runtime dependencies support the target architecture.

An action that works on an x64 runner may not work on an ARM32 machine. The same applies to downloaded command-line tools and native dependencies.

Keeping an older JavaScript runtime indefinitely is not a reliable migration strategy. Review supported action versions and plan the required infrastructure changes.

Common Mistakes to Avoid

Removing every ARM32 reference

An ARM32 compiler target does not mean the workflow runs on ARM32 hardware. Removing all ARM32-related build configurations can break legitimate cross-compilation pipelines.

Inspect the execution environment before changing the workflow.

Assuming ARM64 is affected

ARM32 and ARM64 have different compatibility requirements. The announced retirement is specifically about ARM32 execution on hosted Linux and Windows runners.

Do not migrate ARM64 jobs unnecessarily.

Checking only runs-on

The runs-on property is important, but it is not the only place where architecture dependencies appear.

Inspect containers, reusable workflows, matrices, scripts, action dependencies, and external build tools.

Assuming an action version supports every architecture

An action's version number does not establish compatibility with ARM32. Review its runtime declaration, release notes, dependencies, and supported platforms.

Waiting for a workflow failure

A workflow can remain successful until a runner or action runtime changes. Waiting for the first failure can create avoidable interruptions to builds and deployments.

Complete the inventory and test the migration before the retirement takes effect.

Best Practices for Managing Runner Architecture Changes

A structured approach makes architecture migrations easier to manage.

Practice	Why it matters
Maintain a workflow inventory	Helps identify repositories and jobs that depend on specific architectures
Use explicit runner labels	Makes runner requirements easier to understand
Separate host and target architectures	Prevents unnecessary migration of cross-compilation workflows
Pin action versions responsibly	Makes changes easier to review and test
Review third-party action runtimes	Identifies dependencies that may not support the target architecture
Test on the replacement environment	Finds compatibility problems before production CI is affected
Monitor workflow failures	Helps identify unexpected changes after migration
Document hardware dependencies	Makes future infrastructure changes easier to plan

Conclusion

For compatible workloads, consider moving to ARM64 or using cross-compilation. For hardware-dependent tests, evaluate dedicated hardware or another supported execution environment.

GitHub ActionsARM32 runnersCI/CDself-hosted runnersNode.js 24workflow migration

Comments

Join the conversation! Your thoughts help the community grow.