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)

[Copilot]

The test for ForceNightly feature flag only covers the case where the feature is enabled and the workflow event is "dynamic". Consider adding negative test cases similar to the AllowToolcacheInput feature (see lines 525-543) to verify that:

1. The ForceNightly feature flag does NOT force nightly when the workflow event is not "dynamic" (e.g., "pull_request")
2. The ForceNightly feature flag does NOT force nightly when the feature flag is not enabled

These test cases would ensure the feature flag's conditional behavior (restricted to dynamic workflows) is properly validated.

Suggested change

	test("ForceNightly does not force nightly when event is not dynamic", async (t) => {
	const loggedMessages: LoggedMessage[] = [];
	const logger = getRecordingLogger(loggedMessages);
	const features = createFeatures([Feature.ForceNightly]);
	process.env["GITHUB_EVENT_NAME"] = "pull_request";
	const getApiClientStub = sinon
	.stub(api, "getApiClient")
	.throws(
	new Error(
	"getApiClient should not be called when ForceNightly is not applied",
	),
	);
	try {
	await withTmpDir(async (tmpDir) => {
	setupActionsVars(tmpDir, tmpDir);
	await setupCodeql.getCodeQLSource(
	undefined,
	SAMPLE_DEFAULT_CLI_VERSION,
	SAMPLE_DOTCOM_API_DETAILS,
	GitHubVariant.DOTCOM,
	false,
	features,
	logger,
	);
	});
	// If we reach this point, then getApiClient was not called and the nightly
	// path was not taken, which is the expected behavior.
	t.pass();
	} finally {
	getApiClientStub.restore();
	}
	});
	test("ForceNightly does not force nightly when feature flag is disabled", async (t) => {
	const loggedMessages: LoggedMessage[] = [];
	const logger = getRecordingLogger(loggedMessages);
	const features = createFeatures([]);
	process.env["GITHUB_EVENT_NAME"] = "dynamic";
	const getApiClientStub = sinon
	.stub(api, "getApiClient")
	.throws(
	new Error(
	"getApiClient should not be called when ForceNightly feature flag is disabled",
	),
	);
	try {
	await withTmpDir(async (tmpDir) => {
	setupActionsVars(tmpDir, tmpDir);
	await setupCodeql.getCodeQLSource(
	undefined,
	SAMPLE_DEFAULT_CLI_VERSION,
	SAMPLE_DOTCOM_API_DETAILS,
	GitHubVariant.DOTCOM,
	false,
	features,
	logger,
	);
	});
	// If we reach this point, then getApiClient was not called and the nightly
	// path was not taken, which is the expected behavior.
	t.pass();
	} finally {
	getApiClientStub.restore();
	}
	});

[Copilot]

The JSDoc comment for getCodeQLSource has an incomplete @returns tag. Consider adding a description such as:

@returns A CodeQLToolsSource object describing where the CodeQL CLI should be sourced from.

This would be consistent with other functions in this file (e.g., lines 764, 899) that provide complete return value descriptions.

Suggested change

	* @returns
	* @returns A CodeQLToolsSource object describing where the CodeQL CLI should be sourced from.