fix(workflows): don't fail nuget publish when release tag already exists - #1405
Merged
harshithmohan merged 1 commit intoAug 16, 2026
Merged
Conversation
The daily build republishes packages whose version wasn't bumped since the last successful run. dotnet nuget push --skip-duplicate already tolerates this for the package itself, but rickstaa/action-create-tag was still hard-failing every Publish *Nuget job on reruns because the git tag from the prior publish already exists.
Foowy
force-pushed
the
fix/publish-nuget-tag-exists
branch
from
August 16, 2026 09:25
a668fa5 to
9385c09
Compare
Foowy
marked this pull request as ready for review
August 16, 2026 09:25
|
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
2 tasks
harshithmohan
pushed a commit
that referenced
this pull request
Aug 16, 2026
#1405's tag_exists_error: false never took effect: action-create-tag's existence check is git tag -l, a local check, but the daily-build runner does a fresh checkout with no tags fetched — it always sees 'not exists' locally and tries to create+push the tag fresh, which the remote then rejects since the tag is already there. force_push_tag force-pushes unconditionally, which is a no-op when the tag already points at the same commit.
Closed
3 tasks
Foowy
added a commit
to Foowy/ShokoServer
that referenced
this pull request
Aug 16, 2026
…fy remote tag state Follow-up to ShokoAnime#1406. Thanks to revam for flagging that force_push_tag: true works but does so blindly, with no comparison against what the remote tag currently points to — since this repo's checkout intentionally doesn't fetch tag history, there was no way to detect a release tag pointing at an unexpected commit before overwriting it. Two fixes: - Replace the rickstaa/action-create-tag step with inline git ls-remote logic: query the remote tag directly (a lightweight network call, no history fetch) and only skip/create the tag when the remote either doesn't have it yet or already points at the exact commit being published. Fail loudly instead of overwriting if it points anywhere else. - Restore 1:1 parity with the archived brandedoutcast/publish-nuget action, which ShokoAnime#1401 didn't actually achieve: that action queried NuGet.org's own version index up front and skipped pack/push/tag entirely for an already-published version, so an unchanged-version day was a silent no-op. The composite action always ran pack/push/tag unconditionally and relied only on --skip-duplicate to no-op the package push, while the tag step still ran every time regardless — that decoupling is the actual root cause of the Shoko.Abstractions tag conflict across ShokoAnime#1401/ShokoAnime#1405/ShokoAnime#1406. Added a "Check if version is already published" step that queries NuGet.org's flat-container index and gates Pack/Push/Tag on the version being genuinely new. Verified the git ls-remote logic against three simulated cases on a local checkout replicating CI's shallow, tags-excluded actions/checkout@v7 default (new tag, idempotent same-commit rerun, tag pointing at a different commit), and the NuGet.org version-check logic against real data (existing package+version, nonexistent version, nonexistent package/404).
Foowy
added a commit
to Foowy/ShokoServer
that referenced
this pull request
Aug 16, 2026
…fy remote tag state Follow-up to ShokoAnime#1406. Thanks to revam for flagging that force_push_tag: true works but does so blindly, with no comparison against what the remote tag currently points to — since this repo's checkout intentionally doesn't fetch tag history, there was no way to detect a release tag pointing at an unexpected commit before overwriting it. Two fixes, both additive to the existing rickstaa/action-create-tag step rather than replacing it: - A "Check remote tag state" step runs git ls-remote before the tag step (a lightweight network call, not a history fetch) and only lets the tag step run when the remote either doesn't have the tag yet or already points at the exact commit being published. If it points anywhere else, the job fails loudly instead of the tag step force-overwriting it. - Restore 1:1 parity with the archived brandedoutcast/publish-nuget action, which ShokoAnime#1401 didn't actually achieve: that action queried NuGet.org's own version index up front and skipped pack/push/tag entirely for an already-published version, so an unchanged-version day was a silent no-op. The composite action always ran pack/push/tag unconditionally and relied only on --skip-duplicate to no-op the package push, while the tag step still ran every time regardless — that decoupling is the actual root cause of the Shoko.Abstractions tag conflict across ShokoAnime#1401/ShokoAnime#1405/ShokoAnime#1406. Added a "Check if version is already published" step that queries NuGet.org's flat-container index and gates Pack/Push/Tag on the version being genuinely new. Verified the git ls-remote logic against three simulated cases on a local checkout replicating CI's shallow, tags-excluded actions/checkout@v7 default (new tag, idempotent same-commit rerun, tag pointing at a different commit), and the NuGet.org version-check logic against real data (existing package+version, nonexistent version, nonexistent package/404).
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
3 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
brandedoutcast/publish-nugetaction with a custom composite action.Publish * Nugetjobs (Shoko.Abstractions,Shoko.QueueProcessor,Shoko.BuildTools,Shoko.BuildTools.Targets): https://github.com/ShokoAnime/ShokoServer/actions/runs/31938406541dotnet nuget push --skip-duplicatecorrectly tolerates republishing a package whose version wasn't bumped since the last successful run, but the subsequentrickstaa/action-create-tag@v1step has no equivalent tolerance — it hard-fails with "Updates were rejected because the tag already exists in the remote" whenever the git tag from that prior publish is still there. This will happen on every daily run between version bumps, so the nuget-publish jobs are currently broken onmaster.tag_exists_error: falseon the tag-creation step so it skips (rather than fails) when the tag is already present, matching the idempotent behavior of the push step above it.Test plan
master, both failing identically on all four publish jobs with "tag already exists"mastercompletes the publish jobs successfully