ci(nuget): switch publishing to NuGet.org Trusted Publishing

[yilmaztayfun]

What changed

publish-nuget.yml now authenticates to NuGet.org via Trusted Publishing (OIDC) instead of a long-lived API key secret.

• Added id-token: write to the workflow permissions so GitHub can issue an OIDC token.
• Added a NuGet/login@v1 step that exchanges that token for a short-lived nuget.org API key.
• The push step now reads steps.nuget-login.outputs.NUGET_API_KEY instead of secrets.NUGET_API_KEY.
• The old "API key secret is not configured" guard was replaced with a checklist that surfaces the likely policy/permission mismatch if the token exchange returns nothing.

Why

No durable publishing credential is stored in GitHub anymore, so there is nothing to rotate and nothing to leak. This follows the NuGet Trusted Publishing docs.

Reviewer notes

• Placement is deliberate: the temporary key is valid for 1 hour and is single-use, so the login step sits immediately before the push — after build, test, pack, and artifact upload — rather than at the top of the job.
• The nuget.org policy is bound to this file's name. Renaming publish-nuget.yml will break publishing until the policy is updated. The policy's Workflow File field must be exactly publish-nuget.yml, with no .github/workflows/ prefix.
• This workflow uses no environment:, so the policy's Environment field must be left empty.

Required before the next release

• Add a NUGET_USER repository secret containing the nuget.org profile name (not the e-mail address). This is the value NuGet/login sends during the token exchange; the docs recommend a secret over hardcoding.
• The Trusted Publishing policy on nuget.org already exists (added by @tayfunyilmaz-burgantech). Verify owner/repo/workflow match burgan-tech / aether / publish-nuget.yml.
• After the first successful publish, the now-unused NUGET_API_KEY secret can be deleted. No other reference to it remains in the repo.

For private repositories a new policy starts temporarily active for 7 days and goes inactive if no publish happens in that window, so the first release should run within a week of the policy being created.

Testing

Not exercised end-to-end — this workflow only runs on release-v* branches, so the OIDC exchange is first verified by the next real release run. The NUGET_USER secret must be in place before that.

🤖 Generated with Claude Code

Summary by Sourcery

Switch NuGet publishing workflow to use NuGet.org Trusted Publishing via OIDC-issued short-lived API keys instead of a stored API key secret.

CI:

• Update publish-nuget GitHub Actions workflow permissions to allow OIDC token issuance for NuGet Trusted Publishing.
• Integrate NuGet/login action to obtain a short-lived NuGet.org API key immediately before package push and wire the publish step to use its output.
• Replace the previous missing-secret guard with an error checklist tailored to Trusted Publishing configuration (NUGET_USER, policy matching, id-token permission).

[sourcery-ai]

Reviewer's Guide

The workflow for publishing NuGet packages has been migrated from using a long-lived NuGet.org API key secret to NuGet.org Trusted Publishing via GitHub OIDC, introducing a NuGet/login step, updating permissions, and adjusting the publish step’s key handling and failure diagnostics.

Sequence diagram for NuGet Trusted Publishing workflow

sequenceDiagram
    participant Workflow
    participant NuGet_login
    participant NuGet_org
    participant Publish_step

    Workflow->>Workflow: id-token: write permission
    Workflow->>NuGet_login: run NuGet/login@v1 with user secrets.NUGET_USER
    NuGet_login->>NuGet_org: exchange OIDC token for short-lived API key
    NuGet_org-->>NuGet_login: NUGET_API_KEY
    NuGet_login-->>Workflow: outputs.NUGET_API_KEY

    Workflow->>Publish_step: env NUGET_API_KEY=steps.nuget-login.outputs.NUGET_API_KEY
    Publish_step->>Publish_step: check [ -z "$NUGET_API_KEY" ]
    alt NUGET_API_KEY empty
        Publish_step->>Publish_step: print Trusted Publishing checklist
        Publish_step->>Publish_step: exit 1
    else NUGET_API_KEY present
        Publish_step->>NuGet_org: publish packages to NuGet.org
    end

Loading

File-Level Changes

Change	Details	Files
Switch NuGet publishing authentication from a stored API key secret to NuGet.org Trusted Publishing via GitHub OIDC.	Grant id-token: write in workflow permissions so GitHub can issue an OIDC token. Add a NuGet/login@v1 step that exchanges the OIDC token for a short-lived NuGet.org API key, configured with the NUGET_USER secret. Wire the publish step to read NUGET_API_KEY from the nuget-login step output instead of the NUGET_API_KEY repository secret. Keep the login step directly before the publish step to align with the short lifetime and single-use nature of the temporary key.	.github/workflows/publish-nuget.yml
Improve failure handling and guidance when the NuGet API key is missing or not returned by Trusted Publishing.	Replace the old guard that checked for a missing NUGET_API_KEY secret with a check that verifies the OIDC token exchange returned an API key. Update the error message and checklist to surface likely configuration issues with NUGET_USER, the Trusted Publishing policy owner/repo/workflow mapping, and id-token permissions. Remove references to the obsolete NUGET_API_KEY secret from the workflow.	.github/workflows/publish-nuget.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[coderabbitai]

Warning

Review limit reached

@yilmaztayfun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 98 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: bba791af-b3a2-4fe1-a254-40f952553c65

📥 Commits

Reviewing files that changed from the base of the PR and between 4aa4fbf and 804f91d.

📒 Files selected for processing (1)

• .github/workflows/publish-nuget.yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE