Forward-port the release-pipeline fixes from release/v10.4 - #567
Merged
ChrisonSimtian merged 3 commits intoJul 26, 2026
Merged
Conversation
The release pipeline checks out the tag being released, so HEAD is detached and matches none of version.json's publicReleaseRefSpec entries — they are all branch refs, and NB.GV never tests that spec against refs/tags/*. NB.GV therefore treated every tag build as a non-public release and appended the git height to the package version: v10.4.0-rc.3 shipped 22 packages named 10.4.0-rc.3.geabd043cc2 rather than 10.4.0-rc.3. Setting PublicRelease explicitly on the Test + Pack step is the documented override and the only one that works here; adding a refs/tags pattern to publicReleaseRefSpec has no effect. Verified locally: Pack produces 10.4.0-rc.4.g03e52ff395 without it and a clean 10.4.0-rc.4 with it. This matters most at GA — a stable tag would otherwise publish with a prerelease-shaped suffix and sort below the version it claims to be. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit df3d4f2)
Every job downstream of test-and-pack was unreachable on a workflow_dispatch
run, so the manual path — the documented way to publish to nuget.org, and the
documented way to retry a partial publish — silently published nothing while
reporting success. Two independent causes:
validate-ref is skipped by design on workflow_dispatch (`if: event_name ==
'push'`), and a skipped job propagates through the dependency graph.
test-and-pack survives that with `always()`, but that rescues only itself: its
own dependents still saw a skipped ancestor and were skipped too. This hit all
three publish jobs, including the two that carry no condition of their own.
Separately, the nuget.org opt-in compared `inputs.publish-to-nugetorg == true`.
A `type: boolean` input is only a real boolean when the run starts from the
Actions UI; the REST API can only send strings, and `gh workflow run` rejects a
JSON boolean outright. Comparing a string to a boolean casts both to numbers
('true' → NaN, true → 1), so the opt-in never matched from the CLI — including
the exact invocation in docs/branching-and-release.md.
Both fixed: the publish jobs gate on `always() && needs.test-and-pack.result ==
'success'`, and the opt-in accepts the string as well as the boolean. Tag-push
behaviour is unchanged — validate-ref still gates it, and nuget.org still needs
both the flag and the environment approval.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit 1a64ac9)
ChrisonSimtian
added
bug
The environment URL read https://www.nuget.org/profiles/Fallout, which is not the publishing account — the packages live under the Fallout.build profile (22 packages). The link is what a maintainer clicks from the deployment entry after approving a nuget.org push, so it sent them somewhere unrelated. Display-only: the URL never affected which packages were pushed or where. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ChrisonSimtian
marked this pull request as ready for review
July 26, 2026 13:40
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.
Forward-ports the two release-pipeline fixes made on
release/v10.4while cuttingv10.4.0-rc.4. Both were found by shipping that rc;mainstill carries them, and any release branch cut frommainwould reinherit both.Workflow-only — no product code, no version.json change (the rc pin in #563 is release-branch-only by design and is deliberately not ported;
mainkeeps{height}for per-commit previews).1. Packages were stamped with a git-height suffix
v10.4.0-rc.3shipped 22 packages named10.4.0-rc.3.geabd043cc2. The pipeline checks out the tag, so HEAD is detached and matches none ofversion.json'spublicReleaseRefSpecentries — they're all branch refs, and NB.GV never tests that spec againstrefs/tags/*.PublicReleaseis now set explicitly on Test + Pack.Worst at GA: a stable tag would publish with a prerelease-shaped suffix and sort below the version it claims to be.
2. The whole
workflow_dispatchpublish path was unreachableTwo independent causes, both silent — the run reported success while publishing nothing (evidence:
test + pack: success, all three publish jobsskipped, green overall):validate-refis skipped by design onworkflow_dispatch, and a skipped job propagates through the graph.test-and-packsurvives withalways(), but that rescues only itself — its dependents still saw a skipped ancestor. This skippedpublish-github-packagesandpublish-github-releasesdespite them carrying no condition at all.inputs.publish-to-nugetorg == trueonly matches when the run starts from the Actions UI. The REST API can only send strings andgh workflow runrejects a JSON boolean outright, so string-vs-boolean cast both to numbers ('true'→ NaN) and the opt-in never matched from the CLI — including the invocation indocs/branching-and-release.md.All three publish jobs now gate on
always() && needs.test-and-pack.result == 'success', and the opt-in accepts the string as well as the boolean.Verified on
release/v10.4v10.4.0-rc.4published clean, unsuffixed packages, and the re-dispatch reached thenuget-orgapproval gate instead of skipping. Tag-push behaviour is unchanged —validate-refstill gates it, nuget.org still needs both the flag and the environment approval.Runbook wording is a separate follow-up PR.