GeezerVison

The CodeQL CLI will ship native linux-arm64 artifacts, but the Action does not yet recognize that platform: it rejects the CLI as an unsupported platform/architecture combination and, even if it got past that, would resolve the wrong bundle asset. This change teaches the Action about linux/arm64 so it accepts the CLI and downloads the correct bundle.

Approach

Two small semantic edits, plus faithful test/mock coverage:

• src/cli-errors.ts - add ["linux", "arm64"] to SUPPORTED_PLATFORMS so isUnsupportedPlatform() no longer rejects it.
• src/setup-codeql.ts - make the linux branch of getCodeQLBundleName() architecture-aware, resolving codeql-bundle-linux-arm64.tar.zst on arm64 and codeql-bundle-linux64 elsewhere. This flows automatically to the download and nightlies URL builders.

Arm64 is shipped as a per-platform bundle only and is deliberately excluded from the combined all-platforms gzip (which is near the release-asset size limit), so it is important that resolution lands on the exact per-platform asset name rather than the combined-gzip fallback.

The bundle-download mock in src/testing-utils.ts was updated to mirror the same arch logic so it stays faithful on arm64 hosts (x64 behavior is unchanged). Tests were updated accordingly: the now-supported linux/arm64 case was removed from the unsupported-platform list in src/cli-errors.test.ts, and src/setup-codeql.test.ts gained an explicit arch per case plus a new linux/arm64 case.

x64, macOS, and Windows behavior is unchanged; the only new behavior is on Linux arm64 runners, which do not work at all today.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are documentation or test only, or have been fully tested and validated. This change only adds behavior for Linux arm64 (a platform that fails today) and leaves all existing platforms untouched; it is covered by unit tests.

Which use cases does this change impact?

Workflow types:

• Advanced setup - Impacts users who have custom CodeQL workflows.
• Managed - Impacts users with dynamic workflows (Default Setup, Code Quality, ...).

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.
• Code Quality - The changes impact analyses when analysis-kinds: code-quality.
• Other first-party - The changes impact other first-party analyses.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.

Only relevant when running on a Linux arm64 runner; other architectures are unaffected.

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files) for the new arch branch and platform-support change.
• Test repository - This change will be tested on a Linux arm64 test repository before merging.

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix. There is no x64/macOS/Windows impact, so the blast radius is limited to arm64 runners.

How will you know if something goes wrong after this change is released?

• Other - Failures would surface as CodeQL bundle download or platform errors in the Action logs on Linux arm64 runners.

Are there any special considerations for merging or releasing this change?

• Special considerations - This relies on the CLI publishing the per-platform codeql-bundle-linux-arm64.tar.zst asset. It should only be merged once that asset is being produced.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.