fix(pre-commit-advisory): stop a failed cache-seed run from reddening main - #51
Merged
Conversation
… main
The push-to-default-branch run gates nothing. Its hook steps already end in
`|| true`, and the step that reflects pre-commit's exit code as the job
status is `pull_request`-only — the run exists solely to populate the
default-branch cache scope so PR branches can restore hook envs.
It could still fail on an *infrastructure* step, and did. A transient
curl: (35) Recv failure: Connection reset by peer
while downloading the go-pre-commit release archive failed the install step
and turned an otherwise-green k5s main red (run 30964880559) — test and
build both passed, nothing was wrong with the repo or its hooks, and a
plain re-run went green with no change. Because callers pin `@main`, that
failure mode was reachable from every service repo's default branch.
A seed run that fails costs PRs a cold cache, not correctness. That is not
worth a red ❌ on a service repo's default branch, so the job is now
`continue-on-error` on push.
PR runs are deliberately untouched: they keep failing loudly, because that
❌ is what makes the sticky advisory comment worth reading.
The root cause is fixed separately in the action itself (blairham/go-pre-commit#33,
released as v4.6.1 — `curl --retry` only covers transient HTTP responses and
timeouts, never transport errors like a mid-transfer reset). This is the
defense-in-depth half: even with retries, an infra step failing on a seed run
should not gate anything. Bumping the pinned action version to v4.6.1 is a
separate change.
6 tasks
blairham
added a commit
that referenced
this pull request
Aug 5, 2026
…l retry fix (#52) v4.6.0's install step fetched the release archive with `curl -fsSL --retry 3`, which only retries transient HTTP responses (5xx, 408, 429) and timeouts. A connection reset mid-transfer is a transport-level error, so curl exited 35 immediately without ever using its retry budget: curl: (35) Recv failure: Connection reset by peer That failed the install step and turned an otherwise-green k5s main red (run 30964880559); a plain re-run went green with no change. #51 stopped that class of failure from reddening a caller's default branch, but the seed run still fails and the PR path still pays a cold cache — this is the half that actually stops the flake. v4.6.1 adds `--retry-all-errors` (and raises --retry to 5), which extends the budget to the transport failures we actually hit. The bump is as narrow as it looks: v4.6.0..v4.6.1 touches only the action's own action.yml (2 lines). No Go source changed, so the installed pre-commit binary is byte-for-byte equivalent in behavior — no hook-execution or cache-layout risk. Both the `uses:` ref (which carries the fixed install script) and the `version:` input (which selects the downloaded release) move together so they can't drift.
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
1 participant
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.
Summary
advisoryjobcontinue-on-erroron push only. The push-to-default-branch run gates nothing — its hook steps already end in|| trueand the exit-code-reflecting step ispull_request-only — so it exists purely to populate the default-branch cache scope for PR branches.curl: (35) Recv failure: Connection reset by peerdownloading the go-pre-commit release archive failed the install step and turned an otherwise-green k5s main red (run 30964880559). Test and build both passed; a plain re-run went green with no change. Because callers pin@main, that failure mode was reachable from every service repo's default branch.AGENTS.mddocuments the new behavior alongside the existing "non-blocking by design" section.Context
The root cause is fixed separately in the action itself — blairham/go-pre-commit#33, released as v4.6.1.
curl --retryonly retries transient HTTP responses (5xx/408/429) and timeouts; a mid-transfer connection reset is a transport error, so--retry 3never engaged. That fix adds--retry-all-errors.This PR is the defense-in-depth half: even with retries in place, an infra step failing on a run that gates nothing should not redden a service repo's default branch. Bumping the pinned action to
v4.6.1is a separate change — this PR leaves the pin atv4.6.0.Test plan
actionlint .github/workflows/pre-commit-advisory.yml— cleanpushevent via${{ github.event_name == 'push' }}; theif:gating and every step are unchangedAGENTS.md, semantic changes need a PR in a real caller pointing itsuses:at this branch. The specific behavior to confirm is that job-levelcontinue-on-errorinside aworkflow_callreusable propagates success back to the calling job — that can't be proven from static analysis.🤖 Generated with Claude Code