Repository navigation
CI: let the artifact upload retry actually retry - #562
Merged
Merged
Conversation
The package upload is guarded by a retry step that re-runs
actions/upload-artifact under the same artifact name when the first
attempt fails. That only helps when the first attempt failed before it
registered the name. When it fails later - as on the Intel macOS job of
run 34611736400, where FinalizeArtifact returned 403 - the name is
already taken, so the retry fails with
409 Conflict: an artifact with this name already exists on the
workflow run
and, unlike the first attempt, the retry has no continue-on-error, so a
transient upload error fails a job whose build and tests both passed.
Give the retry overwrite: true, which deletes a matching artifact before
uploading and is documented not to fail when none exists, so it covers
both cases. Give it continue-on-error: true as well, matching the first
attempt: packaging is not what these jobs are there to verify, and a
flaky upload should not red an otherwise green build.
All four upload retries (linux, linux-arm64, macos, windows) had the
same shape and are fixed together.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.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 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.
The package upload in each build job is guarded by a retry step that re-runs
actions/upload-artifactunder the same artifact name when the first attempt fails. That only helps when the first attempt failed before it registered the name.What went wrong
On the Intel macOS job of run 34611736400 the upload got a
403 Forbiddenat the FinalizeArtifact stage — which runs afterCreateArtifact, sodcmqi-macos-x86_64-packagewas already registered on the run. The retry then failed withand because the retry — unlike the first attempt — has no
continue-on-error, the job went red even though the build succeeded and all 93 tests passed.What changes
Each of the four upload retries (
linux,linux-arm64,macos,windows) gets:overwrite: true— deletes a matching artifact before uploading, and is documented as "Does not fail if the artifact does not exist", so the one setting covers both failure modes: the name was registered, or it was not.continue-on-error: true— matching what the first attempt already has. Packaging is not what these jobs exist to verify, and a transient upload error should not fail a job whose build and tests passed.No other behaviour changes; the artifact names, paths and
if:conditions are untouched.Verification
All five workflow files still parse, and each retry step now carries both keys:
The failure itself is a first occurrence — the last dozen macOS runs on
masterare all success or cancelled — so this is about the retry being able to do its job when the flake recurs, not about a persistent breakage.🤖 Generated with Claude Code