Uh oh!
There was an error while loading. Please reload this page.
fix(ci): target the failure region when parsing the pin guard from job logs - #453
Merged
Merged
Conversation
…b logs The PR Failure Report companion parsed the action-pins consistency guard from the last 30 lines of a failed job log. For a Go test failure the guard signature and its want/got rows print in the middle of the log; the trailing lines are post-job git-config cleanup ending at "Cleaning up orphan processes". parsePinGuard therefore saw no signature and dropped the manifest remediation, leaving only a generic exit-code annotation. Feed the full job log to parsePinGuard so the signature and rows are found wherever they land, and display a failure-anchored region instead of the cleanup tail. Adds a node unit test that extracts the shipped helpers verbatim from the workflow and runs them against a real captured failing job log. Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
The pin-guard node test and its fixture were never wired into any CI job, so drop them along with the sentinel comments that existed only to support extracting the helper source for that test. The underlying fix (parsing the pin guard against the full job log and anchoring extractFailRegion on the failure signature) is unchanged. Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
The sentinel comments existed only to mark the extraction boundary for the now-removed node unit test. Remove them along with it. Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The PR Failure Report companion (
drift-comment.yaml) parses the action-pins consistency guard (TestActionPinsAnchorCoversManifest/TestWorkflowsConsistentWithActionPins) from a failed job's log so it can print the exactinternal/generate/action_pins.yamlremediation (action, want vs got SHA). An intentional-trip validation of the merged companion (#441) showed the remediation was absent: the sticky comment named the failedUnit Testsjob but printed no manifest edit, only a genericexit code 123annotation.Root cause:
parsePinGuardwas fed the last 30 lines of the job log. For a Go test failure the guard signature and itswant ... got ...rows print in the middle of the log; the trailing lines are post-job git-config and credential cleanup ending atCleaning up orphan processes. The parser saw no signature, so it produced nothing.Fix
parsePinGuardso the signature and want/got rows are found wherever they land, rather than a blind trailing slice.extractFailRegion, which anchors on the first failure signature (--- FAIL, the guard messages) and windows forward, so the displayed log region shows the failing test output instead of the cleanup tail. Falls back to the trailing lines for non-test failures.Verification
.github/workflows/__tests__/pin-guard.test.js) extracts the shipped helpers verbatim from the workflow (between sentinels, so no forked copy can drift) and runs them against a real captured failingUnit Testsjob log. It asserts the manifest remediation is produced, the display region lands on the failure (not the cleanup tail), and that the prior last-30-lines approach produced nothing. 4/4 pass undernode --test.actionlintclean on the workflow;node --checkclean on the embedded script.The companion runs only from
mainonworkflow_run, so this local proof stands in for a live run.