Add Azure DevOps NuGet release pipeline for nuget.org publishing

[Mike Krüger (mkrueger)]

Summary

Adds .pipelines/CosmosDB-Shell-Release-NuGet.yml, a manual-only Azure DevOps (OneBranch) release pipeline that publishes the already-signed CosmosDBShell NuGet packages to nuget.org.

This is an ongoing process — opening as a draft while the one-time Azure DevOps / nuget.org setup is completed.

Split out from the FDD packaging PR "Build framework-dependent (FDD) NuGet packages and zips in Official pipeline" (#191) so the release/publish concern is reviewed independently.

How it works

• Does not build or sign anything — it consumes the already-signed packages produced by the CosmosDB-Shell-Official build via a pipelines resource.
• Validates the full package set before publishing, then pushes behind a manual approval on the nuget-org-release Azure DevOps Environment (via a deployment job).
• dryRun: true (default) validates the package set without pushing; re-run with dryRun: false to publish.
• trigger: none / pr: none — release is initiated manually only.

Publish contract

Validates and publishes:

• 6 RID-specific self-contained packages: CosmosDBShell.{win-x64,win-arm64,linux-x64,linux-arm64,osx-x64,osx-arm64}
• 1 pointer (non-RID) package: CosmosDBShell
• 1 framework-dependent package: CosmosDBShell.FrameworkDependent

Ordering note: the FDD validation expects packages produced by #191. The pipeline is manual/draft and won't run until setup is complete, so there's no hard merge-order dependency, but #191 should land before the first live release.

One-time setup required before first live run

1. nuget.org: own the CosmosDBShell and CosmosDBShell.FrameworkDependent package IDs and generate a scoped API key covering both.
2. Azure DevOps: create the nuget-org-cosmosdbshell NuGet service connection pointing at nuget.org with that key.
3. Azure DevOps: create the nuget-org-release Environment with the required approvers.
4. Register this YAML as a pipeline named CosmosDB-Shell-Release-NuGet.

Testing

• YAML validated (no schema/lint errors).
• No runtime execution yet — pending the setup steps above.

[github-code-quality]

Code Coverage Overview

Languages: C#

C# / code-coverage/dotnet

The overall coverage in commit 59402d6 in the dev/mkrueger/nuget-r... branch remains at 61%, unchanged from commit 50dea94 in the main branch.

---

_{Updated August 18, 2026 09:54 UTC}

[Copilot]

Pull request overview

Adds a manual-only Azure DevOps (OneBranch) release pipeline to publish the already-signed CosmosDBShell NuGet packages produced by the Official build pipeline to nuget.org, gated by an environment approval and supporting a default dry-run validation mode.

Changes:

• Introduces .pipelines/CosmosDB-Shell-Release-NuGet.yml with trigger: none / pr: none and dryRun + debug parameters.
• Downloads the cosmos_shell_all artifact from the CosmosDB-Shell-Official pipeline, validates the expected package set, and conditionally pushes to nuget.org behind a deployment/environment approval.

[Mike Krüger (mkrueger)]

Fixes

Copilot review comment (.pipelines/CosmosDB-Shell-Release-NuGet.yml): the RID validation only checked that at least one package matched each pattern, so a leftover duplicate would still pass and get pushed to nuget.org. Each RID pattern must now match exactly one file; a duplicate throws and lists the matched names. Verified locally against a valid set, a duplicate win-x64, and a missing linux-arm64 — all three behave correctly.

Stray Windows exes in the build artifact: cosmos_shell_all contained two loose files — out\win-x64\CosmosDBShell.exe and out\win-arm64\CosmosDBShell.exe — alongside the zips and nupkgs. They were kept only so BinSkim had PE files to scan (it doesn't descend into zip/nupkg archives). Fix:

• Added a step that copies those two exes to _binskim-scan\ outside out\ before the final trim.
• Switched ob_sdl_binskim_scanOutputDirectoryOnly to false so BinSkim scans the whole checkout instead of just out\ (same signed binaries, just picked up from the staged location).
• Dropped win-x64/win-arm64 from the trim step's keep-list.

Published artifact now contains only zip/nupkg/_manifest; BinSkim coverage is unchanged. Verified the copy/trim logic locally with a simulated out\ tree.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.pipelines/CosmosDB-Shell-Release-NuGet.yml:174

• The release validation requires a CosmosDBShell.FrameworkDependent.* package, but the Official pipeline’s package set validation only expects RID packages plus a single non-RID pointer (and it explicitly rejects CosmosDBShell.any.*). As written, this pipeline will fail validation against the current Official build artifacts and/or may allow an unintended any-RID package to be treated as the pointer.

                          # The framework-dependent tool package (requires .NET 10
                          # on the target machine) ships alongside the RID set.
                          $fdd = $packages | Where-Object { $_.Name -match '^CosmosDBShell\.FrameworkDependent\..+\.nupkg$' }
                          if (-not $fdd -or $fdd.Count -ne 1) {
                            $names = @($fdd | ForEach-Object { $_.Name })

.pipelines/CosmosDB-Shell-Release-NuGet.yml:13

• The one-time setup instructions reference a 'CosmosDBShell.FrameworkDependent' package ID, but this repo/pipelines don’t produce that package (the only expected packages are the RID-specific CosmosDBShell. packages plus a single non-RID pointer). This instruction is misleading for the required nuget.org ownership/API key scope.

This issue also appears on line 170 of the same file.

#   1. nuget.org: create/own the 'CosmosDBShell' package ID and the             #
#      'CosmosDBShell.FrameworkDependent' package ID under the 'cosmosdbshell'   #
#      organization and generate a scoped API key covering both.                #