Build and publish NuGet.Client.EndToEnd.TestData if needed#7459
Open
martinrrm wants to merge 1 commit into
Open
Build and publish NuGet.Client.EndToEnd.TestData if needed#7459martinrrm wants to merge 1 commit into
martinrrm wants to merge 1 commit into
Conversation
Contributor
|
Since this PR is changing CI as it modifies YML files, please verify that you've addressed how this change should apply to release branches. Either:
|
Adds an opt-in, queue-time `PublishEndToEndTestData` parameter to the official pipeline that builds the NuGet.Client.EndToEnd.TestData package and publishes it (with an SBOM) as the `EndToEndTestData` pipeline artifact. The companion NuGet.Client-Pipelines change downloads that artifact and pushes it to the public dnceng nuget-build feed. - Bump NuGet.Client.EndToEnd.TestData to 1.0.3 (nuspec + Directory.Packages.props pin). - Thread `PublishEndToEndTestData` through official.yml -> pipeline.yml -> Build.yml (default false; non-RTM, official builds only). - Generate the package into an isolated staging directory ($(Build.StagingDirectory)\e2etestdata), deliberately outside the repo 'artifacts' tree so it bypasses MicroBuild signing (SignTool would recurse into and corrupt the bundled mock-package fixtures), BAR/Maestro publishing, and the product SBOM scan; verify exactly one package is produced, then publish it as the `EndToEndTestData` artifact. - Track the previously git-ignored InstallPackagesConfigLocal/InstallPackagesConfigLocalGraph.dgml test descriptor (force-added past the `packages/` .gitignore rule). It is an input used by InstallPackageTest.ps1, so without it the CI-generated package would be missing those fixtures. - Update CreateTestDataPackage.ps1 to locate GenerateTestPackages.exe under both local and CI output layouts and to fail with a clearer error when it is missing. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
4e16ac6 to
c5e4048
Compare
zivkan
reviewed
Jun 6, 2026
Comment on lines
+138
to
+142
| # The EndToEnd test data package bundles nested .nupkg fixtures as content. It is generated into a | ||
| # staging directory that is deliberately OUTSIDE the repo 'artifacts' tree so it is never signed | ||
| # (SignTool would recurse into and corrupt the nested fixtures), never picked up by BAR publishing, | ||
| # and never scanned by the product SBOM. It is published unsigned to the dnceng nuget-build feed | ||
| # via the '- output: nuget' block in pipeline.yml. |
Member
There was a problem hiding this comment.
So, the current design is manually queue an official build, setting the PublishEndToEndTestData parameter to true, then wait for the official build to complete, then run the release pipeline.
It seems to me we could have a single pipeline that both builds and publishes the package, so we don't need to queue two pipelines to perform one outcome.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug
Fixes:
Pipelines PR https://devdiv.visualstudio.com/DevDiv/_git/NuGet.Client-Pipelines/pullrequest/746014
Description
Adds the ability to publish a new version of the
NuGet.Client.EndToEnd.TestDatapackage, which is required to unblock the Apex integration tests.Because the package needs to be published in an AzDO dnceng feed, we need to do a CI to publish a new package version. This is the NuGet.Client half of a two-repo change, the companion PR in
NuGet.Client-Pipelinesperforms the actual push to the dncengnuget-buildfeed, this is becauseNuGet.Client-Pipelinesalready has a connection toNuGet Development - DevDivazure subscription and makes more sense since we also have package publish steps there.What this PR does
NuGet.Client.EndToEnd.TestDatato 1.0.3 (.nuspec+ theDirectory.Packages.propspin).PublishEndToEndTestDataparameter (defaultfalse), threadedofficial.yml → pipeline.yml → Build.yml. It only runs in non-RTM, official builds.GenerateTestPackages, runsCreateTestDataPackage.ps1, and generates the package into an isolated staging directory ($(Build.StagingDirectory)\e2etestdata), then verifies exactly one package was produced and publishes it (with an SBOM) as theEndToEndTestDatapipeline artifact.NuGet.Client-Releasepipeline downloads that artifact and pushes it to the public dncengnuget-buildfeed (companion PR)..dgmlfile to fix E2E testInstallPackagesConfigLocalWhy the package is isolated from
artifacts/The package bundles 700+ nested mock
.nupkgfixtures as content. Generating it outside the repoartifactstree keeps it out of: MicroBuild signing (SignTool recurses into and would corrupt the nested fixtures), BAR/Maestro publishing, and the product SBOM scan.How to publish a new version (rare):
PublishEndToEndTestData = true→ produces the artifact.PublishEndToEndTestData = trueand run only thePublish EndToEnd TestDatastage.**Possible Permissions needed: ** the
nuget-build-dnceng-publicservice connection must be authorized for theNuGet.Client-Releasepipeline.PR Checklist
[ ] Added tests