Repository navigation
ci: three guards on the snapshot prune, and why it is asset by asset - #531
Merged
Merged
Conversation
The step that removes the assets a snapshot run did not upload now refuses an empty upload (every asset of the release would count as stale), treats an asset that is already gone as removed (one re-read of the release after a failed delete-asset), and reports a failed deletion while trying the rest, failing only afterwards -- the assets of this upload are on the release either way, so this is "attach first, then red" like the signature check. The guards come from the job's own history, dug up from git and the Actions API: its first form (2026-05-07) deleted and recreated the whole snapshot release, and on 2026-05-10 the runs of several main pushes minutes apart deleted it under each other -- every job of each burst but the last failed in that step with its artifacts present. The job went with the Central migration the next morning and came back as view-or-create plus upload --clobber without any cleanup, which is how the backlog grew; no commit named the failures. The step comment, CLAUDE.md and the CHANGELOG bullet say so now, and the runs are recorded in workspace/policies/fat-jar-release-assets.md. The step is the same text as the siblings' shared github-snapshot job. Verified: the script, extracted verbatim from the workflow, against a gh stub in eight cases (empty upload refused with nothing deleted; empty release and equal sets are no-ops; stale assets removed; an asset gone under us tolerated; a real deletion failure reported after the rest were tried; a failed re-read reported; a failed release view fails before anything is deleted), bash -n over every run script, the shared-files and release-gate checks, the buildcheck unit tests. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2
bernardladenthin
had a problem deploying
to
maven-central
October 12, 2026 12:14 — with 
GitHub Actions
Failure
GitHub Actions
Failure
bernardladenthin
had a problem deploying
to
maven-central
October 12, 2026 12:14 — with
GitHub Actions
Failure
GitHub Actions
Failure
This was referenced Oct 12, 2026
Merged
|
This branch had an error being deployed
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
2 participants
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
github-snapshotstep that removes the assets a run did not upload (Attach every Central artifact to the GitHub releases and prune the snapshot pre-release #529) gets three guards: an empty upload is refused (every asset of the release would count as stale; unreachable whiledownload-artifactandgh release uploadfail first, the guard makes the invariant explicit), an asset that is already gone counts as removed (one re-read of the release after a faileddelete-asset; two overlapping dispatches may both pick it), and a failed deletion is reported while the rest are still tried, failing only afterwards -- the assets of this upload are on the release either way ("attach first, then red", like the signature check). Nothing is swallowed with|| true.snapshotrelease with its tag, and on 2026-05-10 the runs of several main pushes minutes apart deleted it under each other -- every job of each burst but the last failed in that step with its artifacts present. The job went with the Central migration the next morning and came back as view-or-create plusupload --clobberwithout any cleanup, which is how the 208-asset backlog grew; no commit named the failures. The runs are inworkspace/policies/fat-jar-release-assets.md(Release-assets policy: the three prune guards and the May 2026 delete-and-recreate history workspace#54).github-snapshotjob (ci: three guards on the snapshot prune, and why it is asset by asset BitcoinAddressFinder#386, ci: three guards on the snapshot prune, and why it is asset by asset srcmorph#224, ci: three guards on the snapshot prune, and why it is asset by asset streambuffer#178).Test plan
ghstub in eight cases (empty upload refused with nothing deleted; empty release and equal sets are no-ops; stale assets removed; an asset gone under us tolerated; a real deletion failure reported after the rest were tried; a failed re-read reported; a failed release view fails before anything is deleted);check-run-scripts.py(bash -nover every run script),check-shared-files.py,check-release-gate.py, the 122 buildcheck unit testsRelated issues / PRs
Follow-up of #529. Siblings: bernardladenthin/BitcoinAddressFinder#386, bernardladenthin/srcmorph#224, bernardladenthin/streambuffer#178; policy: bernardladenthin/workspace#54.
Checklist
CONTRIBUTING.mdandCODE_OF_CONDUCT.mdSECURITY.md)🤖 Generated with Claude Code
https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2
Generated by Claude Code