-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Consider adding a shipping package baseline test #28129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for contacting us. |
Post-build hook in arcade would be useful in creating a check for this. https://github.com/dotnet/aspnetcore/blob/master/eng/AfterSolutionBuild.targets |
I'm not sure what would be needed here nor how additional automation would help. If we need to check prior to the release, manifest files e.g. \vsufile\patches\sign\NET\CORE_BUILDS\2.1.X\2.1.31\20210916-02\assets\orchestration-metadata\manifests\aspnet.xml, \vsufile\patches\sign\NET\CORE_BUILDS\3.1.X\3.1.20\3.1.120-servicing-015384\manifest.json, or \vsufile\patches\sign\NET\NET_CORE\5.0.11\configs\manifests\manifest.json are available when internal builds are announced. Looking back, the eng/Baseline.xml file e.g. https://github.com/dotnet/aspnetcore/blob/release/2.1/eng/Baseline.xml and (for 2.1) https://github.com/dotnet/versions/blob/main/build-info/dotnet/product/cli/release/2.1/build.xml and similar files are available after every release. /cc @mkArtakMSFT because this relates to validating fixes are in a release |
/btw John's suggestion won't help because we always ship everything in every release, with the minor exception of targeting packs. Where we do incremental shipment (in release/2.1), Arcade isn't involved. |
In any case, I have no way to know when we'd do this, if do something, and cleared the milestone for now. Suggestions for "maybe" items @adityamandaleeka @rafikiassumani-msft @mkArtakMSFT @Pilchie❔ |
As part of the postmortem for a 5.0.1 issue where we needed to mark Identity.Specficiation.Tests as shipping. It seems worth adding a test with baselines to track the total set of packages we ship, similar to how we track the list of assemblies in the shared fx here: https://github.com/dotnet/aspnetcore/blob/master/src/Framework/test/TestData.cs.
The analogy would be something that just enumerates all the nupkgs in the shipping artifacts and fails if there's a mismatch from the list so we can track/be explicitly intentional about changes in the packages we ship.
The text was updated successfully, but these errors were encountered: