Build and publish NuGet.Client.EndToEnd.TestData if needed#7459
Build and publish NuGet.Client.EndToEnd.TestData if needed#7459martinrrm wants to merge 1 commit into
Conversation
|
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>
martinrrm
force-pushed
the
dev-mruizmares-fixApexTests
branch
from
4e16ac6 to
c5e4048
Compare
| # 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. |
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.
There was a problem hiding this comment.
Yeah, that would be the easiest way to develop and publish the package. But TBH I don't see us publishing a new package in years, last version is from 2024 and we weren't using it. 1.0.0 is from 2020.
I just don't want to create a new pipeline for something that we might never use, I was thinking maybe Official can do the publishing too, but Official feels more like a build only pipeline.
We were doing something similar when we wanted to publish CommandLine packages, so I was following that.
I think we should choose the way that is easier for the team to maintain and do compliance on the pipeline, either a new one, keep it as two, or maybe even do everything as a new step in release pipeline, maybe we can just build this project and publish.
| <metadata> | ||
| <id>NuGet.Client.EndToEnd.TestData</id> | ||
| <version>1.0.0</version> | ||
| <version>1.0.3</version> |
There was a problem hiding this comment.
I'm trying to understand the publish/consume ordering and could use some help. This PR bumps the central NuGet.Client.EndToEnd.TestData pin to 1.0.3, but as I understand it 1.0.3 only lands in the dnceng nuget-build feed after someone manually queues an official build with PublishEndToEndTestData=true and then runs the companion release pipeline. Meanwhile CreateEndToEndTestPackage.proj consumes this package via (central package management) and restores it from nuget-build. So, my question is: how do we avoid a window where this is merged but 1.0.3 isn't on the feed yet. Wouldn't restore of that project fail with NU1102 until the publish happens? Is 1.0.3 already published, or does the pin bump need to wait for that? (I noticed the PR is currently mergeable_state: blocked, is that related?)
| - ${{ if eq(parameters.PublishEndToEndTestData, true) }}: | ||
| - output: pipelineArtifact | ||
| displayName: 'Publish EndToEnd TestData package' | ||
| condition: "and(succeeded(), eq(variables['BuildRTM'], 'false'), eq(variables['IsOfficialBuild'], 'true'))" |
There was a problem hiding this comment.
The runtime condition on the pipelineArtifact output duplicates the BuildRTM/IsOfficialBuild logic that also lives in Build.yml. If these conditions drift, the package could be generated but not published (or vice versa). Consider centralizing the "should we publish E2E test data" predicate so the generate step and the artifact output can't get out of sync.
dotnet-policy-service
Bot
added
the
Status:No recent activity
|
This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch. |
martinrrm
removed
the
Status:No recent activity
3 participants
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