-
-
Notifications
You must be signed in to change notification settings - Fork 204
Setup trusted publishing #3204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setup trusted publishing #3204
Conversation
|
Hi @Smaug123, I was inspired by how this was set up at GR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR aims to set up trusted publishing for NuGet packages but doesn't fully implement the feature. The changes separate the release workflow from the main CI workflow and add explicit Build and Pack stages to the Release pipeline. However, the implementation still relies on API key authentication through the NuGet/login action rather than implementing true OIDC-based trusted publishing.
Key changes:
- New dedicated release workflow (
.github/workflows/release.yml) triggered on pushes to main - Release publishing removed from the main CI workflow
- Build and Pack stages added to the Release pipeline in
build.fsx
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
.github/workflows/release.yml |
New workflow for NuGet package releases using NuGet/login action for API key retrieval |
.github/workflows/main.yml |
Removed the publish step that ran on main branch pushes |
build.fsx |
Added Build and Pack stages to the Release pipeline |
CHANGELOG.md |
Added entry for version 7.0.4 documenting the trusted publishing feature |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: Obtain NuGet key | ||
| # this hash is v1.1.0 | ||
| uses: NuGet/login@d22cc5f58ff5b88bf9bd452535b4335137e24544 | ||
| id: login | ||
| with: | ||
| user: ${{ secrets.NUGET_USER }} | ||
| - name: "Publish" | ||
| env: | ||
| NUGET_KEY: ${{ steps.login.outputs.NUGET_API_KEY }} |
Copilot
AI
Dec 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation doesn't appear to use NuGet's trusted publishing (OIDC-based authentication). True trusted publishing would eliminate the need for API keys and the NuGet/login action. Instead, this still relies on the NUGET_API_KEY output from the login action, which defeats the purpose of trusted publishing.
For actual trusted publishing, you should:
- Configure trusted publishing in your NuGet.org account settings for this package
- Remove the
NuGet/loginaction step - Modify the
dotnet nuget pushcommand inpushPackagefunction to use the--skip-duplicateflag without requiring an API key when running in GitHub Actions with proper permissions
Reference: https://learn.microsoft.com/en-us/nuget/nuget-org/publish-with-github-actions
| - name: Obtain NuGet key | |
| # this hash is v1.1.0 | |
| uses: NuGet/login@d22cc5f58ff5b88bf9bd452535b4335137e24544 | |
| id: login | |
| with: | |
| user: ${{ secrets.NUGET_USER }} | |
| - name: "Publish" | |
| env: | |
| NUGET_KEY: ${{ steps.login.outputs.NUGET_API_KEY }} | |
| - name: "Publish" | |
| env: |
Smaug123
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks correct to me assuming you're OK with the unconditional publish. Copilot is simply wrong about not requiring a NuGet API key at all.
.github/workflows/release.yml
Outdated
| DOTNET_CLI_TELEMETRY_OPTOUT: true | ||
|
|
||
| jobs: | ||
| build: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This release has become unconditional, if I understand correctly - personally I would prefer to ensure the tests have run first, but 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that is fair.
Fixes #3203