ESRP.Release.NuGet.BVT.Case04.B 1.0.194576.104

ESRP Release NuGet BVT package

This disposable package validates NuGet publishing through ESRP Release in PPE and NuGet INT only. The release endpoint is https://ppe.api.esrp.microsoft.com/, and the release stages set ob_release_environment: Test. No production target is configured.

Supported Loop release cases

One build creates the exact standard-release set 1-16, 18-22, 27-29. One release run expands that set into 24 stable jobs in a single governed stage. Each case submits exactly once through EsrpReleaseCanary@15; all cases are independent except case 5, which depends on successful case 1 and reuses case 1's exact package, version, path, and SHA-256 hash to exercise the Publisher's idempotent 409 behavior. The pipeline does not rewrite expected-negative task failures into successful stage results, so results must be compared with each stage's expected category.

Package descriptors and verification manifests are stored outside payloads. The reusable release job deletes and recreates its case-specific publish directory, verifies every descriptor hash, and copies only the explicitly listed release files. Case 21 intentionally lists two unrelated files in addition to its valid package; no descriptor or verification manifest is submitted.

The default organization is esrprelease. Valid default package identifiers are unique per case under ESRP.Release.NuGet.*, and versions are unique per build. Cases 18 and 29 use distinct valid identifiers outside that reserved prefix. Case 27 uses an unknown organization. Case 28 passes quoted mixed casing and surrounding whitespace and expects organization normalization.

Only expected publish-success cases 1-4, 19-21, 28 run the existing NuGet INT verification script. It downloads each package from the NuGet INT V3 feed and records package and hash evidence in the OneBranch output artifact.

Local validation

Run from nuget-test, matching the build pipeline working directory:

.\New-NuGetBvtScenarios.ps1 `
  -OutputDirectory .\.validation-artifacts `
  -PackageId ESRP.Release.NuGet.BVT `
  -VersionPrefix 1.0.123456 `
  -BuildId 123456 `
  -SourceVersion local `
  -SourceBranch local
.\Test-NuGetBvtScenarios.ps1 -OutputDirectory .\.validation-artifacts

The validator enforces the exact 24 case IDs, unique numbering and generated versions, package and symbol counts, readable identities, intended malformed archive/nuspec defects, manifest references and hashes, metadata isolation, case 5 replay identity, and absence of a standalone submission ZIP.

Raw publish-actions manifest cases

Cases 32-34 use esrp-release@0.2.0-nuget-publish-actions-organization.2, the exact package consumed by ADO-task commit b8bd125229b730234ce81682a2b5421cfb644219, instead of EsrpReleaseCanary@15. The direct tool uses a checked-in npm lockfile and npm ci, so transitive versions and integrity hashes cannot drift. This preserves the intentionally missing, malformed, or version 2.0 manifest; the task would otherwise replace each input with a valid version 1.0 manifest. Each raw submission must create an ESRP release ID and reach the exact expected Publisher validation error in a failed terminal release state.

Cases 25 and 26 run the Canary task with the organization input omitted or whitespace-only. They are expected to fail task validation before release creation, so neither case should produce an ESRP release ID.

Case 50 creates a valid 260 MiB NuGet package on the release agent and submits it through the direct result-capturing client. The ADO task reads but does not enforce Release.MaxFileSizeInMB, so setting that variable would not test the boundary. The direct path must create an ESRP release ID before the NuGet endpoint rejects the package at its documented approximate 250 MB upload limit, without adding a 260 MiB build artifact.

Cases 37 and 38 generate and submit four fresh package identities across the esrprelease and esrprelease-org routes. Both organizations allow the same ESRP.Release.NuGet.* prefix. The expected configuration maps esrprelease to App ID 844687cd-117b-4aa0-8ada-ba7c4648cceb and esrprelease-org to App ID 071dee24-d305-48b7-9db5-f0294829221a. Successful independent publication proves that each selected organization accepted and published its unique package; it does not by itself prove which App ID Publisher resolved for that route.

The current single submission covers 32 Loop cases: 1-16, 18-22, 25-29, 32-34, 37-38, 50. A build-time matrix check rejects missing or extra case IDs and keeps publishing disabled by default.

The same stage also runs six supplemental prefix-reservation jobs from merged PR 25025. They verify shared-prefix publication through both organizations, owner publication under the Primary and Secondary delegated prefixes, and cross-organization rejection for each delegated prefix. These jobs strengthen cases 17, 24, 37, and 38 but are not counted as additional Loop case IDs.

Held Loop cases

Cases 17, 23-24, 30-31, 35-36, 39-49, 51-55 remain held. Verified blockers include isolated PPE tenant/policy/identity mutations, controlled NuGet endpoint fault injection (cases 47-49), Scan-owner approval for the existing EICAR test package (case 51), a Release UI token-login automation identity with the required application ID and roles (cases 52-54), and a Terrapin-authorized identity plus Event Grid/telemetry evidence access (case 55).

Successful publication is necessary but not sufficient to close cases 37 and 38: the post-run evidence must retain Publisher PublishConfiguration telemetry and confirm the resolved App ID matches the selected organization.

Publishing remains disabled by default. Enable it only after the NuGet INT prefix, owner, app-registration trusted-publishing policy, PackageManagerMaster namespace mapping, EsrpReleaseCanary@15 task, and Publisher PPE configuration are ready.