Publish with trusted publishing, from a tag - #18
Conversation
Replaces the long-lived NUGET_API_KEY with an OIDC exchange for a short-lived key, takes the version from the tag rather than a typed input so it is recorded in git, and adds a dry run that exercises the trusted publishing policy without publishing. Also runs the audit and formatting checks the job previously skipped, so it cannot publish while ci.yml is red.
|
Warning Review limit reached
Next review available in: 7 seconds Limit details: You’ve used all 3 included reviews currently available under your plan. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Comment |
1 participant
Closes #14.
What changes
secrets.NUGET_API_KEY, long-livedworkflow_dispatchonlyv*tag push, plus dispatch for dry runsci.ymlrunsThe credential
This is the org's most-downloaded package at 66,043, and it was the one holding a standing publish credential. The runner now mints a short-lived token that nuget.org exchanges for a key scoped by policy. Nothing is stored and nothing can be replayed.
umbraco-pwahas published this way since August, so this is a known-good pattern rather than a first attempt.Once a publish succeeds without it, delete
NUGET_API_KEYfrom repository secrets and revoke it on nuget.org.The version
dotnet pack /p:Version=${{ inputs.version }}meant the published version was whatever someone typed into a dispatch box. Nothing recorded which commit produced1.2.3. It now comes from the tag, and a tag that is notvMAJOR.MINOR.PATCHfails the run rather than publishing something odd.The dry run, which is the point
The OIDC exchange runs on dry runs too. Obtaining a key publishes nothing, so a dispatch with
dry_runticked genuinely verifies the trusted publishing policy is configured correctly.That is deliberate.
.github/DELIVERY.mdrecords what happens otherwise: a release gate whose first execution is a real release. That costumbraco-pwaa failed 0.3.0 publish tonight, on a gate that had been merged weeks earlier and had never once run.Please dispatch this with
dry_runticked before tagging anything.A correction to #14
I claimed the old workflow had no test step and "will publish from a red tree". That was wrong; it ran
dotnet testbefore pushing. The accurate point is narrower: it ran its own tests but not the audit, formatting or dependency-free checks fromci.yml, so those could be red while it published. This adds them.Checked before committing
dotnet format --verify-no-changesexits 0 onmaintoday, so the new formatting step will not fail the first run on unrelated drift.