Accept GitHub release URLs in the tools input

[henrymercer]

The tools input of the init and setup-codeql actions now accepts a GitHub release URL, such as https://github.com/github/codeql-action/releases/tag/codeql-bundle-v2.27.1, as well as the older /releases/codeql-bundle-<version> form. The Action selects a compatible bundle from that release, including a per-language bundle when the job can use one, using the bundle selection from #4172.

parseCodeQLReleaseUrl recognises release pages on the current GitHub instance or on github.com by comparing origins. It never treats asset URLs or REST API URLs as releases, so those keep their existing meaning. A release on the current instance is looked up with the API, which works for private and internal repositories. A release on github.com requested from GHES or GHE.com is downloaded by URL, without an API request or credentials, like the existing fallback to the public release. The CLI version comes from a cli-version-<version>.txt asset if the release has one, and otherwise from the tag. As for the default bundle, it decides whether the job can use a per-language bundle and which compression method we prefer.

The bundle always comes from the requested release. We never substitute a release from another repository, and a release URL takes precedence over the force_nightly feature flag. If the release can't be found, setup fails with an error that names it, rather than the generic token error.

Stable releases tagged codeql-bundle-v<version> in the repositories we already download the default bundle from, this Action's repository and github/codeql-action, contain the same bundles as the default bundle for that version. They use and populate the toolcache in the same way. Other releases, such as release candidates, custom bundles and releases in other repositories, may contain a different build under the same version number, so we don't look them up in the toolcache or cache them.

Known limitations:

• For a github.com release requested from GHES or GHE.com, we can't see which assets the release has, so we take the CLI version from the tag and assume the preferred compression method is available. Unless the tag gives a version of 2.19.0 or newer, that's gzip.
• Releases that only contain per-language bundles aren't supported.

Commit-by-commit review recommended. The first two commits document how CodeQL is versioned in the toolcache and move the toolcache lookup out of getCodeQLSource without changing it. The next three add the release URL parser, reading the CLI version from a release, and looking up a requested release. The sixth commit uses these to accept release URLs, and at that point release URLs never use the toolcache. The last two commits let stable releases in the CodeQL Action repositories use it.

Risk assessment

Low risk: This only affects workflows that pass a release URL to the tools input, which wasn't previously supported. Other tools inputs behave as before.

Which use cases does this change impact?

Workflow types:

• Advanced setup
• Managed

Products:

• Code Scanning
• Code Quality
• Other first-party - Analyses using the shared CodeQL setup path.

Environments:

• Dotcom
• GHES

How did/will you validate this change?

• Unit tests - New tests for parsing release URLs, reading the CLI version from a marker asset or the tag, and setting up CodeQL from requested releases on github.com and GHES. These cover toolcache reuse for stable releases in the CodeQL Action repositories, isolation for other releases, gzip-only releases and a missing release. The unit tests and lint pass locally at each commit.
• End-to-end tests - PR checks cover the existing tools inputs, but none of them use a release URL, so the new path relies on the unit tests.

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

• Rollback - Revert or release a fix. Release URLs are not behind a feature flag, but only workflows that use them are affected.

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

• Telemetry - Existing telemetry for tools downloads and initialization failures.

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

• Special considerations - This is stacked on Select CodeQL bundles from a release #4172, so it should be merged after that PR.

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.

[Copilot]

Warning

• Copilot's review of this pull request may be incomplete because some of the changed files are excluded by your Copilot content exclusion settings. See Excluding content from Copilot for details.

Copilot review overview

🟡 Changes recommended

Mixed-case HTTPS release URLs are valid but are currently misclassified as local paths.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1

Open (1)

• Handle uppercase or mixed-case URL schemes in release URL detection · New

What changed in this PR

Adds support for GitHub release-page URLs in the tools input.

Changes:

• Resolves releases through the appropriate GitHub API or public URLs.
• Selects compatible bundles while safely controlling toolcache reuse.
• Adds documentation, changelog entries, and comprehensive tests.

File	Description
src/​setup-codeql.ts	Integrates release resolution, bundle selection, and caching rules.
src/​setup-codeql.test.ts	Tests release downloads, fallback behavior, and caching.
src/​codeql-release.ts	Parses release URLs and resolves release metadata.
src/​codeql-release.test.ts	Tests parsing, version markers, and release lookup.
src/​codeql-bundle.ts	Marks custom releases as non-cacheable.
setup-codeql/​action.yml	Documents release URLs for setup-codeql.
init/​action.yml	Documents release URLs for init.
CHANGELOG.md	Records the new input capability.
lib/​entry-points.js	Generated artifact; content excluded from review.

Files excluded by content exclusion policy (1)

• lib/entry-points.js

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.