fix(workflows): force-push the release tag on nuget publish - #1406
Merged
harshithmohan merged 1 commit intoAug 16, 2026
Merged
Conversation
ShokoAnime#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
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
tag_exists_error: falseon therickstaa/action-create-tag@v1step to stop the daily nuget-publish jobs failing on unbumped versions. That did not actually fix it — confirmed on the next "Build (Daily)" run after fix(workflows): don't fail nuget publish when release tag already exists #1405 merged, still failing identically: https://github.com/ShokoAnime/ShokoServer/actions/runs/31939093126action-create-tag's existence check (entrypoint.sh) isgit tag -l "${TAG}"— a local tag check. The daily-build runner does a fresh checkout with no tags fetched, so the action always sees the tag as "not existing" locally, takes the create-fresh-tag path, and attempts a plaingit push origin "$TAG"— which the remote rejects because the tag from the prior publish is already there.tag_exists_erroronly gates the branch that runs when the local check finds the tag, so it never even executes.force_push_tag: trueinstead. This unconditionally doesgit tag -fa+git push --force, which succeeds regardless of whether the local checkout knows about the existing tag, and is a no-op in practice since it's re-pointing the tag at the same commit it already points to.Test plan
masterafter it mergedmastercompletes the publish jobs successfully