ci: gate NuGet push behind builds and release#7
Merged
Conversation
The nuget job only needed the version job, so it packed and pushed to NuGet.org in parallel with the platform builds. A failing Windows build would skip the GitHub release but leave the tool already published — a permanent state, since a NuGet version can only be delisted, never re-pushed. Gate the nuget job on [version, build, release] so the package goes out only after all six platforms build and the GitHub release is published. The GitHub release with attested binaries stays the source of truth; the NuGet package never points at a version with no release.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the release workflow so NuGet publishing is properly gated behind successful platform builds and the GitHub release job, preventing packages from being pushed when a release is skipped due to build failures.
Changes:
- Update the
nugetjob dependency graph to wait forbuildandrelease(not justversion) before running.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
158
to
162
| nuget: | ||
| name: 📦 Pack NuGet Tool | ||
| needs: version | ||
| needs: [version, build, release] | ||
| runs-on: ubuntu-latest | ||
| steps: |
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
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.
Problem
The `nuget` job only declared `needs: version`, so it packed and pushed to NuGet.org in parallel with the platform builds:
```
version
├─ build (matrix: 6 RIDs incl. win-x64, win-arm64)
├─ release needs: [version, build] ← gated on all builds
└─ nuget needs: version ← NOT gated
```
If a Windows build failed, `release` was correctly skipped — but `nuget` had already run `dotnet nuget push`. The result is a tool live on NuGet.org with no corresponding GitHub release or binaries. And it's permanent: a NuGet version can only be delisted, never re-pushed under the same number.
Fix
```yaml
nuget:
needs: [version, build, release] # was: version
```
The package now publishes only after all six platforms build and the GitHub release is published. The GitHub release (with attested binaries) stays the source of truth; the NuGet package can never point at a version that has no release.
Trade-off
Because `release` carries `if: startsWith(github.ref, 'refs/tags/v')`, the `nuget` job is now also skipped on `workflow_dispatch` runs — so dispatch no longer produces a test `.nupkg` artifact. The push step was already tag-guarded and never ran on dispatch, so only test-packing is lost. Acceptable for the consistency gain.