Repository navigation
ci: refuse to publish a version that is already on nuget.org - #43
Merged
Merged
Conversation
The publish step passes --skip-duplicate, so re-tagging an already-published version SUCCEEDS while uploading nothing. The run goes green, the release notes say the new version shipped, and what is on nuget.org is the older bytes. A published version can never be replaced there, only unlisted, which makes publishing the one irreversible step in this workflow. Until now the check was a human remembering to look. Cutting 0.2.5 I checked by hand, which is exactly the kind of guard that works until the once it does not. Runs before Restore, for the same reason the tag-matches-version check does: catch it before anything is built, not after it is on nuget.org. An unreachable nuget.org is a FAILURE, deliberately. A check that passes when it cannot verify anything is worse than no check. A 404 on the package index is not that case -- it means the package has never been published, which is the correct state for a first release. All four paths exercised against the live feed rather than reasoned about: version already published (0.2.5) exit 1, names the version and says why version not published (0.2.6) exit 0 package never published (404) exit 0, "would be the first release" nuget.org unreachable exit 1, "refusing rather than assuming" Known window, recorded in the step's own comment: the flat-container listing lags a push by a few minutes -- measured at roughly four for 0.2.5 -- so re-tagging inside that window still slips through. That is a far narrower hole than the one this closes, and closing it completely would mean trusting the registration index, which is slower still. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018wZEgtuzaZPswykiGEBxbz
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.
release.ymlpublishes with--skip-duplicate, so re-tagging an already-published versionsucceeds while uploading nothing. The run goes green, the release notes say the new version
shipped, and what sits on nuget.org is the older bytes. A published version can never be replaced
there — only unlisted — which makes publishing the one irreversible step in this workflow.
Until now the check was a human remembering to look. Cutting 0.2.5 I checked by hand, which is
the kind of guard that works right up until the once it doesn't.
Design
Runs before Restore, for the same reason the tag-matches-version check does: catch it before
anything is built, not after it is on nuget.org.
An unreachable nuget.org fails the step. A check that passes when it cannot verify anything is
worse than no check — the same stance
phoenixmldb'scheck-pins.shtakes, and for the samereason. A 404 on the package index is not that case: it means the package has never been
published, which is the correct state for a first release.
All four paths exercised against the live feed
0.2.5)0.2.6)safe to publishwould be the first releaseHTTP 000·refusing rather than assuming it is newNot reasoned about — run, with
Directory.Build.propstemporarily bumped for the second case anda deliberately bad host for the fourth.
Known window
The flat-container listing lags a push by a few minutes — measured at roughly four minutes for
0.2.5 — so re-tagging inside that window still slips through. That is a far narrower hole than
the one this closes, and closing it completely would mean trusting the registration index, which
is slower still. Recorded in the step's own comment rather than left implicit.
🤖 Generated with Claude Code
https://claude.ai/code/session_018wZEgtuzaZPswykiGEBxbz