Fall back to non-overlay analysis when diff-informed analysis is unavailable#3791
Fall back to non-overlay analysis when diff-informed analysis is unavailable#3791sam-robson wants to merge 1 commit intomainfrom
Conversation
472336b to
8c82546
Compare
There was a problem hiding this comment.
Pull request overview
Ensures the CodeQL init step avoids the unsupported “overlay-only” mode by falling back to a full non-overlay analysis when diff-informed analysis was expected but didn’t produce the pr-diff-range.json output.
Changes:
- Add a
hasDiffRangesJsonFile()helper to detect whetherpr-diff-range.jsonwas produced. - In
init-action, revertoverlayDatabaseModetoNonewhen overlay is enabled, diff-informed analysis should have run, but the diff ranges file is missing. - Update the generated
lib/init-action.jsto reflect the TypeScript changes.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/init-action.ts | Adds a guard to revert overlay mode to non-overlay when diff-informed output is missing. |
| src/diff-informed-analysis-utils.ts | Introduces hasDiffRangesJsonFile() helper for detecting persisted diff ranges output. |
| lib/init-action.js | Generated build output reflecting the TypeScript changes (not reviewed). |
8c82546 to
08f4ea7
Compare
| ); | ||
| } | ||
|
|
||
| export function hasDiffRangesJsonFile(): boolean { |
There was a problem hiding this comment.
Minor: Adding a JSDoc comment here would be nice.
| // If overlay is enabled and diff-informed analysis should have run but | ||
| // failed to produce output, revert to non-overlay analysis. Overlay | ||
| // without diff-informed is an untested combination that can produce | ||
| // inaccurate results. | ||
| try { | ||
| if ( | ||
| config.overlayDatabaseMode === OverlayDatabaseMode.Overlay && | ||
| (await shouldPerformDiffInformedAnalysis(codeql, features, logger)) && | ||
| !hasDiffRangesJsonFile() | ||
| ) { | ||
| logger.warning( | ||
| "Diff-informed analysis is not available for this pull request. " + | ||
| `Reverting overlay database mode to ${OverlayDatabaseMode.None}.`, | ||
| ); | ||
| config.overlayDatabaseMode = OverlayDatabaseMode.None; | ||
| } | ||
| } catch (e) { | ||
| logger.warning( | ||
| `Failed to determine diff-informed analysis availability, ` + | ||
| `reverting overlay database mode to ${OverlayDatabaseMode.None}: ${getErrorMessage(e)}`, | ||
| ); | ||
| config.overlayDatabaseMode = OverlayDatabaseMode.None; | ||
| } | ||
|
|
There was a problem hiding this comment.
It would be good to move this out of init-action.ts and into one of the overlay-specific modules if possible.
There's already a bunch of logic around overlay enablement there, so spreading that out across different locations isn't good.
We also have some frameworks for tests/diagnostics/telemetry there that this could factor into. In any case, this should have test coverage.
When overlay analysis is enabled for a PR but diff-informed analysis fails (e.g. deleted branch, API error, too many changed files), the action previously continued with overlay-only analysis. This is an untested combination that can produce inaccurate results. Now we fall back to a full non-overlay analysis instead.
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
dynamicworkflows (Default Setup, Code Quality, ...).Products:
analysis-kinds: code-scanning.analysis-kinds: code-quality.Environments:
github.comand/or GitHub Enterprise Cloud with Data Residency.How did/will you validate this change?
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist