Add FileAssert validation for Tool package size and contents#51
Merged
Conversation
Adds a new [package]-tagged FileAssert test group (.fileassert.yaml) that validates every packed .nupkg (Core, Language, Stdlib, Tool) right after dotnet pack in build.yaml's per-OS build job: - Size budgets: Tool nupkg must stay under 70 MiB (regression guard for the historical 435 MB native-asset bloat); Core/Language/Stdlib under 5 MiB. - Content assertions: expected DLLs and README present in each package; Tool package additionally asserts exactly 8 native runtime assets (the curated RID allowlist) and zero stray .pdb files under runtimes/**, guarding the TrimPublishedNativeAssets fix. Updates ROADMAP.md's Package validation gate entry to reflect that content assertions are now automated; only the tool and library-consumer smoke tests remain open. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Per feedback, the FileAssert package tests were massively overscoped: they froze the exact set of native runtime assets (count: 8) and asserted every transitive dependency DLL and multi-TFM lib path for all four packages. That locks in incidental implementation details this early-stage project will keep changing, for no real regression-guard benefit. Scoped down to just the two checks with a genuine historical justification: - Tool nupkg max-size 70 MiB (the package previously bloated to ~435 MB). - Tool package contains its main assembly + README, and has no stray .pdb files under the native runtimes folder (the actual cause of that bloat). No checks are applied to Core/Language/Stdlib packages or their multi-TFM layout - those never had a size problem and this project's packaging is still evolving. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
1 participant
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.
This pull request adds automated validation for the contents and size of the NuGet package produced by the build, ensuring that the package remains within its size budget and does not accidentally include debug symbol files that previously caused excessive bloat. The changes introduce new FileAssert tests and integrate them into the build workflow.
Package validation enhancements:
.fileassert.yaml: Added a newpackagetest group with tests to ensure the NuGet package stays under 70 MiB, contains required files (main assembly andREADME.md), and does not include unwanted.pdbfiles in native runtime assets. This guards against past regressions where debug symbols caused the package to balloon in size.Build workflow integration:
.github/workflows/build.yaml: Added a step to run the new FileAssert package validation tests as part of the build pipeline, providing early detection of packaging issues.