Update nuget.org publishing to use trusted publishing#8209
Update nuget.org publishing to use trusted publishing#8209andrewlock merged 5 commits intomasterfrom
nuget.org publishing to use trusted publishing#8209Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: df7ae4d58b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
BenchmarksBenchmark execution time: 2026-02-18 09:59:18 Comparing candidate commit 8b3cd12 in PR branch Found 13 performance improvements and 7 performance regressions! Performance is the same for 155 metrics, 17 unstable metrics. scenario:Benchmarks.Trace.ActivityBenchmark.StartStopWithChild net472
scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces net472
scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces net6.0
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorMoreComplexBody netcoreapp3.1
scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody netcoreapp3.1
scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeLegacyArgs netcoreapp3.1
scenario:Benchmarks.Trace.AspNetCoreBenchmark.SendRequest net6.0
scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces net6.0
scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice net472
scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice net6.0
scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice netcoreapp3.1
scenario:Benchmarks.Trace.CharSliceBenchmark.OriginalCharSlice net6.0
scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearchAsync netcoreapp3.1
scenario:Benchmarks.Trace.ILoggerBenchmark.EnrichedLog net6.0
scenario:Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark netcoreapp3.1
scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore netcoreapp3.1
scenario:Benchmarks.Trace.TraceAnnotationsBenchmark.RunOnMethodBegin net6.0
|
nuget.org publishing to use trusted publishing
There was a problem hiding this comment.
Pull request overview
Updates the dd-trace-dotnet GitHub release workflows to publish packages to nuget.org using NuGet “trusted publishing” (OIDC-based short-lived credentials) instead of a long-lived API key secret.
Changes:
- Grant
id-token: writein the release workflows to allow OIDC token issuance. - Replace
NUGET_API_KEYsecret usage withNuGet/login+NUGET_TRUSTED_PUBLISHING_USERNAME. - Use the temporary NuGet API key output from
NuGet/loginfordotnet nuget push.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| .github/workflows/create_normal_draft_release.yml | Adds OIDC permissions and switches secret passed to the reusable release workflow. |
| .github/workflows/create_hotfix_draft_release.yml | Adds OIDC permissions and switches secret passed to the reusable release workflow. |
| .github/workflows/_create_draft_release.yml | Implements trusted publishing via NuGet/login and uses its temporary API key for NuGet pushes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary of changes
Updates dd-trace-dotnet to publish NuGet packages using trusted publishing
Reason for change
From the documentation:
Implementation details
Followed the steps in the documentation (and this excellent blog post - recommend reading that for a brief summary 😉). Having used this personally, I found it "just works" but there are some caveats to using it for orgs.
Firstly, the trust policy is tied to a single account (i.e. mine), though it applies to
datadog-owned packages. If I get removed from the org, someone else would need to set up a trust policy. The details I used to create the policy are shown below:The trust policy is tied to my account via the
NUGET_TRUSTED_PUBLISHING_USERNAMEgithub secret. If we need to change to a different trust policy provided by a different nuget user, we should just need to update that secret to point to the new user.Additionally, I left the legacy
create_draft_release.ymlworkflow untouched (as opposed to the newcreate_normal_draft_releaseandcreate_hotfix_draft_releaseworkflows which use the_create_draft_releaseworkflow), so that we have a fallback that keeps using theNUGET_API_KEYapproach, in case this doesn't work on the next release for some reason!Test coverage
This is all just YOLO, we can't really test it very easily. That said, the current release tries to do a "noop" push to nuget.org of an existing package, to confirm permissions are set correctly, and that is still in place.
WE could theoretically test this, by heavily cutting out all the actual release bits out of
_create_draft_release.ymland trying to trigger a release, but that's frankly too risky for my liking. Given we still have the fallback release path at the moment, that's good enough for me