Ensure uniqueness of overlay-base database cache keys

[kaspersv]

This PR adds a workflow run id and workflow attempt id to the overlay base database cache key postfix to ensure uniqueness of the cache keys. The cache key prefix used for restoring overlay-base databases remains unchanged.

The motivation for the change is that currently if a successful overlay analysis run on the default branch is retried or a repo contains a scheduled CodeQL workflow on the default branch that runs twice without any changes on the default branch in between, then uploading of the overlay-base database will fail due to a cache key collision.

The first commit which adds a unit test for overlay-base cache keys was cherry-picked from #3158.

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.

This individual change is not under feature flag, but it only affects overlay analysis, which is under feature flag and can be disabled in case of unexpected negative impact.

Which use cases does this change impact?

• Advanced setup - Impacts users who have custom workflows.
• Default setup - Impacts users who use default setup.
• Code Scanning - Impacts Code Scanning (i.e. analysis-kinds: code-scanning).

How did/will you validate this change?

• Test repository - This change will be tested on a test repository before merging.
• 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 - 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.

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 PR modifies the cache key generation for overlay-base databases by incorporating workflow run ID and workflow attempt ID into the save key. This ensures uniqueness when the same workflow is retried or scheduled to run multiple times without code changes on the default branch, preventing cache key collisions during upload.

Key Changes:

• Added workflow run ID and attempt ID to the overlay-base database cache save key format
• Exported previously internal cache key generation functions for testing
• Added comprehensive unit test to validate cache key stability and format

Reviewed Changes

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

File	Description
src/overlay-database-utils.ts	Modified cache save key to include workflow run ID and attempt ID; exported cache key functions for testing
src/overlay-database-utils.test.ts	Added unit test to validate cache key generation format and stability
lib/analyze-action.js	Generated JavaScript code reflecting the TypeScript changes

[mbg]

This looks good to me. I added two comments: one is a very minor note about about the behaviour of getWorkflowRunID and getWorkflowRunAttempt if it matters to you, otherwise you can ignore it. The other is about the order of the elements in the cache key. Both points are not blocking.

[mbg]

These two functions may throw errors if the corresponding environment variables are not defined. I don't see any reason why that would be a concern since they should always be set in Actions, but I thought I'd mention it.

[kaspersv]

It is a corner-case of a corner-case, but it doesn't add much code to handle it. I've added error handling in commit 4, such that we default to 1 in the unlikely case these functions fail.

[mbg]

Again, I still don't think this would ever be an issue, but I think I'd prefer throwing an error rather than defaulting to 1. Alternatively omit the runId and attemptId from the cache key.

Not blocking though - I am happy to approve this as is. This can always be tweaked later.