build: collapse chains of skipped workflow runs#1973
Conversation
The validate job's 'Look for prior successful runs' step finds a prior successful run that is commit- or tree-same and records its URL via core.notice and as the validate.outputs.skip output, which downstream jobs surface to users. When the prior run was itself a skip-run (i.e. its only successful work was recording a notice pointing at a yet earlier run), we end up with a chain of skip-runs each pointing at the previous skip-run, rather than at the run that actually built and tested the tree. Following such a chain by hand to find the real build is tedious. Bottom out that chain in the script: after identifying a candidate run, inspect its Validation job's annotations for the same 'Skipping: There already is a successful run: <url>' notice. If present, fetch the referenced run, verify it is still completed and successful, and repeat until we reach a run that is not itself a skip-run. Use that URL for both the notice and the job output, so consumers always see the real underlying run. Also add console logs along the way (initial match, each chain hop, stop conditions) to make future debugging straightforward, and grant the workflow checks: read so the script can call checks.listAnnotations. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>
|
This issue was noticed with the failure of this check run in That workflow followed the skip-run to another skip-run, which didn't have the required artifacts (to run the functional tests). Whilst we could also update |
There was a problem hiding this comment.
Pull request overview
Updates the validate job's "Look for prior successful runs" step to follow chains of skip-runs back to the underlying real build, so the recorded notice and validate.outputs.skip URL always point to a run that actually built and tested the tree rather than to another skip-run.
Changes:
- Adds
checks: readto workflow permissions so the script can callchecks.listAnnotations. - Introduces a
resolveSkipChainhelper that, for a candidate prior run, fetches itsValidationjob's annotations, detects theSkipping: There already is a successful run: <url>notice, and iteratively hops to the referenced run (validating it is still completed/successful) up toMAX_CHAIN_LENGTH(10) iterations. - Calls
resolveSkipChainbefore emitting the notice / returning the result, and adds console logs for each step / stop condition.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The validate job's 'Look for prior successful runs' step finds a prior successful run that is commit- or tree-same and records its URL via
core.noticeand as thevalidate.outputs.skipoutput, which downstream jobs surface to users.When the prior run was itself a skip-run (i.e. its only successful work was recording a notice pointing at a yet earlier run), we end up with a chain of skip-runs each pointing at the previous skip-run, rather than at the run that actually built and tested the tree. Following such a chain by hand to find the real build is tedious.
Bottom out that chain in the script: after identifying a candidate run, inspect its Validation job's annotations for the same 'Skipping: There already is a successful run: ' notice. If present, fetch the referenced run, verify it is still completed and successful, and repeat until we reach a run that is not itself a skip-run. Use that URL for both the notice and the job output, so consumers always see the real underlying run.
Also add console logs along the way (initial match, each chain hop, stop conditions) to make future debugging straightforward, and grant the workflow checks: read so the script can call
checks.listAnnotations.