◐ Shell
clean mode source ↗

Support SHA-256 Git object hashes (64-char OIDs) by Copilot · Pull Request #3872 · github/codeql-action

Copilot

Git is transitioning to SHA-256 as the default object hash (64 hex chars vs SHA-1's 40). Two production code paths hard-coded assumptions about 40-char OIDs, causing silent failures or errors in SHA-256 repositories.

Production fixes (src/git-utils.ts)

  • getFileOidsUnderPath(): Regex {40} → {40,64} — previously all entries failed to match in SHA-256 repos, causing an error throw.
  • determineBaseBranchHeadCommitOid(): Length checks === 40 → (=== 40 || === 64) — previously the condition was always false for 64-char OIDs, causing silent undefined return and fallback to server-side base SHA calculation.

Test coverage (src/git-utils.test.ts, src/upload-lib.test.ts, src/testing-utils.ts)

  • Added SHA256_GITHUB_SHA = "0".repeat(64) constant to testing-utils.ts
  • SHA-256 variants for getRef() tests (merge PR ref, checkout@v1 path, head PR ref, explicit input)
  • SHA-256 test for determineBaseBranchHeadCommitOid returning the correct base OID from a 64-char merge commit
  • SHA-256 tests for getFileOidsUnderPath (pure 64-char OIDs and mixed SHA-1/SHA-256)
  • SHA-256 upload payload test in upload-lib.test.ts

Risk assessment

  • Low risk: Test coverage for fixed code paths. No behavior change for SHA-1 repos.

Which use cases does this change impact?

  • 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.
  • Code Quality - The changes impact analyses when analysis-kinds: code-quality.
  • Other first-party - The changes impact other first-party analyses.
  • Third-party analyses - The changes affect the upload-sarif action.

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?

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

  • Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.

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.