GeezerVison

The overlay status mechanism records a marker in the Actions cache when building an overlay-base database fails, so that later runs skip overlay analysis instead of failing the same way, but it records one whenever the analyze step did not report success, which also covers runs that were cancelled, since the init post step still runs in that case. A cancellation tells us nothing about whether the analysis would have succeeded, and a marker disables overlay analysis for the whole repository until the next CodeQL release, so this adds an internal job-status input defaulting to ${{ job.status }} and skips recording when the job was cancelled.

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, Code Quality, ...).

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.

Environments:

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

How did/will you validate this change?

• Test repository - This change will be tested on a test repository before merging, specifically to confirm that a cancelled run reports cancelled to the post step.
• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).

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

• Feature flags - The behaviour change only takes effect where overlay_analysis_status_save is enabled, so disabling that flag restores the previous behaviour. The new input is inert on its own.

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

• Telemetry - I rely on existing telemetry. The codeql-action/overlay-disabled diagnostic reports skipped-due-to-cached-status, so the rate of that reason shows whether we are recording fewer markers as intended, and overlay adoption shows whether we have stopped recording ones we needed.

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. Not added, since the behaviour is gated behind an existing feature flag, matching earlier changes to this mechanism.
• Confirm the readme and docs have been updated if necessary.