Add feature for forcing the nightly bundle in dynamic workflows

[mbg]

Adds a Feature which, when enabled, and the workflow was triggered by a dynamic event forces getCodeQLSource to pick the latest, nightly release.

Some drive-by improvements and observations:

• I added a couple of comments to better document getCodeQLSource.
• While writing those, I noticed that the !toolsInput.startsWith("http") check would probably cause problems if a file happened to have a path that starts with http. Probably not a very likely problem, but could be tricky to troubleshoot if it happens. We could improve this by performing more explicit checks for http:// and https:// or whether the suspected file exists locally or not. Outside of the scope of this PR though.
• I added a unit test for tools: nightly which didn't seem to exist.
• While doing that, I noticed that getNightlyToolsUrl seems to assume that the nightly tag is codeql-bundle- followed by a semver, but this is no longer the case for nightly releases. There's a fallback logic which handles this fine, but we should probably update this to expect the date-based tags.

Risk assessment

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

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Workflow types:

• Managed - Impacts users with dynamic workflows (Default Setup, CCR, ...).

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.
• Code Quality - The changes impact analyses when analysis-kinds: code-quality.
• CCR - The changes impact analyses for Copilot Code Reviews.

Environments:

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

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).
• End-to-end tests - I am depending on PR checks (i.e. tests in pr-checks).

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

• Feature flags - All new or changed code paths can be fully disabled with corresponding feature flags.

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

• Telemetry - I rely on existing telemetry or have made changes to the telemetry.
  • Dashboards - I will watch relevant dashboards for issues after the release. Consider whether this requires this change to be released at a particular time rather than as part of a regular release.
  • Alerts - New or existing monitors will trip if something goes wrong with this change.

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

• No special considerations - This change can be merged at any time.

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]

Pull request overview

This pull request adds a new ForceNightly feature flag that allows forcing the use of the nightly CodeQL CLI bundle in dynamic workflows (Default Setup, CCR, etc.). The feature flag is restricted to dynamic workflow events or test mode, preventing it from affecting advanced workflows. The PR includes comprehensive unit tests and an end-to-end PR check to validate the functionality.

Changes:

• Added ForceNightly feature flag to enable nightly CLI for dynamic workflows
• Enhanced getCodeQLSource with documentation and logic to support forced nightly builds
• Added unit tests for both tools: nightly and ForceNightly feature flag scenarios
• Created new PR check workflow to validate the feature in CI

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/feature-flags.ts	Adds the ForceNightly feature flag definition with environment variable and default value
src/setup-codeql.ts	Implements logic to force nightly CLI when feature flag is enabled in dynamic workflows; adds JSDoc documentation and exports for testing
src/setup-codeql.test.ts	Adds comprehensive unit tests for nightly CLI selection via both explicit input and feature flag
pr-checks/checks/bundle-from-nightly.yml	Defines PR check template to validate ForceNightly feature works as expected
.github/workflows/__bundle-from-nightly.yml	Auto-generated workflow file from the PR check template
lib/*.js	Auto-generated JavaScript transpilation of TypeScript source changes (not reviewed per guidelines)

[esbena]

LGTM with some superficial logging observability/logging concerns.

[esbena]

The recent changes LGTM.

[henrymercer]

I had a quick look over the last two commits.

• I like the solution with storing unwritten nolang diagnostics.
• I would suggest changing the severity of the diagnostic to info, since the UI will complain relatively loudly about warnings.
• The changes look correct but it is hard to say for sure that they will work without a PR check or example run — consider running this on a test repo before merging.

[mbg]

@henrymercer I have made those changes and ran a test in a test repository. See the references in the PR timeline.

[esbena]

Latest (trivial) changes LGTM, and the sample run looks as advertised.