CodeQL all-platform bundle deprecation: audit OS and CPU installation paths before versions

Dev
Views 3

A security scanner may receive version updates while its installer filename stays unchanged for years. If your team downloads CodeQL through custom CI or an internal mirror, inspect both the version and the asset being downloaded.

Find installation paths, map OS and CPU, separate caches, and verify analysis: a checklist for custom CI.
Find installation paths, map OS and CPU, separate caches, and verify analysis: a checklist for custom CI.

On September 22, 2026, GitHub announced the deprecation of the all-platform CodeQL bundle. This article separates that announcement from practical recommendations for making a platform-specific migration reviewable.

Deprecation is not an outage today

Starting with CodeQL CLI 2.27.0, codeql-bundle.tar.gz and codeql-bundle.tar.zst are deprecated. GitHub plans to remove them in mid-March 2027 and recommends the bundle matching the supported operating system and architecture.

Linux ARM64 binaries are available only in platform-specific downloads, not the all-platform bundle. This does not mean every existing workflow is now broken. First establish whether your installation actually downloads either deprecated file.

Trace the direct installation paths

Searching workflow YAML alone can miss installations baked into container images, bootstrap scripts or internal artifact repositories. Connect the code that constructs a download URL to the environment that eventually runs analysis.

Record the execution environment, OS, CPU architecture, downloaded asset, cache location and owner. This inventory is an operational suggestion, not an official requirement. Do not paste secret tokens or private endpoints into public issues.

An operating-system name is not enough

Linux on x86-64 and Linux on ARM64 need different executables. Distinguish the host from its container environment and map exact filenames from the release assets. Reject unknown combinations rather than silently selecting a default; the resulting failure is easier to diagnose.

The 2.27.0 release lists Linux ARM64 CLI and bundle assets. An available download does not establish support for every language and build configuration. Current system requirements label Linux ARM64 support beta, so check the relevant language and environment conditions too.

Do not let caches hide a failed migration

Changing a download filename proves little if an old cache supplies the executable. Include platform differences alongside the version in cache keys and mirror paths, and record the asset and CLI version actually used in the first validation run.

Use distributions from official sources and their supplied integrity information. If your internal repository retains verified assets, retain their original version and platform too. Pay particular attention when different architectures currently share one cache name.

Verify analysis, not merely startup

A CLI that launches is not necessarily equivalent to the previous analysis setup. On the same commit of a representative repository, check database creation, query execution and result upload, and compare the languages and build modes included.

Combining this change with an application refactor or query-policy update makes differences harder to explain. Review installation changes separately; investigate unexpected results using the tool version, pack versions and build logs.

Start with one reproducible path

A small team can begin with its most important custom CI path. Document success criteria and the settings needed to roll back, then give mirror and older-image owners the same checklist so the remaining scope is visible.

Public releases and issues are useful starting points for compatibility questions, but another repository's results cannot validate yours. This article does not claim community consensus or a measured migration success rate.

What to leave in the change record

Attach the old filename, new platform mapping, actual execution environment and representative analysis results to the PR. List environments still untested so reviewers can distinguish completed work from remaining work.

Before removal, the task is to change and validate the installation path, not simply hide the warning. Assign someone to revisit the official changelog and requirements in case a more precise removal date is announced.

Sources