• Right now, this just skips computing baseline file coverage, but as follow up, we'll change this to also skip running the CodeQL queries to determine actual file coverage.
• We don't plan to roll this out externally for now. codeql database interpret-results currently expects baseline information to always be present, and displays a log message "The database provided was made with a CLI version before 2.11.2 which did not record file baseline information, so file baseline information will be absent." when it is missing. We'll address this and put this feature behind a tools feature flag. At this point we'll also add a changelog entry. I'm proposing merging this now to make more incremental code changes and to allow us to test this internally.
• There are two items of drive-by cleanup: removing an unused CLI function, and updating the version of the caniuse-lite package to avoid a pesky warning during builds.

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:

• Advanced setup - Impacts users who have custom CodeQL workflows.
• 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?

• Test repository - This change will be tested on a test repository before merging.

See https://github.com/github/codeql-action/actions/runs/21356271329

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.
  • 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.