ci: retry the changes filter so one dropped API connection does not fail every check - #5933
Merged
Conversation
Contributor
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (2 files)
Reviewed by grok-4.6 · Input: 77.2K · Output: 11K · Cached: 235K Review guidance: REVIEW.md from base branch |
eshurakov
approved these changes
Sep 7, 2026
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 free
to 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.
Why
The
changesjob runsdorny/paths-filterto decide which checks are needed. That action has no retry of its own, so a single dropped connection toapi.github.comwhile it lists a pull request's changed files fails the step — and with it every check that declaresneeds: changes.Observed on PR #5925 (2026-09-07): the
changesjob failed,typecheck,lint,build,testand the rest never ran, and the pull request could not go green until the job was re-run by hand.What changed
Detect changesattempt iscontinue-on-error: true, and a secondDetect changes (retry)step runs onlyif: steps.filter.outcome == 'failure'.kilocode_backendandcloud_agent_nextoutputs fall back to the retry's outputs. Every consumer reads them throughneeds.changes.outputs, so no other step needs a change.continue-on-error.scripts/changes-filter-retry.test.mjsfails the job if the wiring rots. It rejects a retry that is unconditional, filters that drift between the two attempts, a missing output fallback, and an ignored retry outcome. It runs in the same job, before the filter steps.Proof
The
changesjob on this pull request is the live proof of the happy path: it runs the new test and both filter steps.Scope
workspace_matrixcomes from a separateDetect changed workspaces with testsstep, which is not retried. A transient failure there still fails the job.