Repository navigation
chore: adopt Central Package Management so a bump is one file (#684) - #689
Conversation
Move every NuGet version out of the nine .csproj files into a new Directory.Packages.props at the repo root. The csproj files keep bare PackageReference elements, including the PrivateAssets/IncludeAssets children where they existed. Directory.Build.props is untouched; it still does exactly one thing, RestorePackagesWithLockFile. No version changes hands. 33 distinct packages, zero cross-project disagreements, every floating range kept as it was. CPM rejects floating ranges with NU1011 unless CentralPackageFloatingVersionsEnabled is set, so it is set; the committed lock files pin what restores, not the ranges. The lock files are not byte-identical and cannot be: CPM emits lock format version 2 and reclassifies transitives that carry a PackageVersion as CentralTransitive. A per-entry comparison of all 443 entries across the nine locks shows identical resolved version, contentHash and dependencies for every package, so the resolved graph is the same one main had. Restore inputs that named the csproj or Directory.Build.props explicitly now name the props file too: the Dockerfile restore layer, the #315 locked-mode drift guard in ci.yml, the setup-dotnet cache key, the image-layer hashFiles keys, the dependency-submission and e2e-smoke path filters, and the pre-commit hook trigger.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (26)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe repository adopts Central Package Management through ChangesCentral NuGet package management
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The Central Package Management migration preserves the resolved dependency graph and updates restore and CI inputs consistently. No merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Linked Issues checkExplanation The PR satisfies the CPM migration, centralized version management, bare PackageReferences, version preservation, and regression-verification requirements in Resolution Update issue
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Closes #684.
What
Every NuGet version moves out of the nine
.csprojfiles into a newDirectory.Packages.propsat the repo root. The csproj files keep barePackageReferenceelements (childPrivateAssets/IncludeAssetsuntouched).Directory.Build.propsis not repurposed; it still only setsRestorePackagesWithLockFile.This is a refactor: no version changes hands. 33 distinct packages, zero cross-project disagreements (re-verified by script on
62107f2c), every floating range and every pin kept exactly. NoGlobalPackageReference.Acceptance evidence
Lock files are not byte-identical, and cannot be under CPM. Enabling
ManagePackageVersionsCentrallymakes NuGet write lock format"version": 2and relabel transitive packages that carry aPackageVersionentry asCentralTransitive. That reclassification is the whole diff. Per-entry comparison of old vs new locks, all nine projects:resolved,contentHashordependenciesTransitive→CentralTransitiveversionScript used (run from the branch, compares against
HEAD~1= main):.csprojcontainsVersion=on aPackageReferencedotnet build Cluckwork.sln: 0 warnings, 0 errorsdotnet test Cluckwork.sln: 2278 passed (Domain 365, AppHost 10, Application 234, Api.Integration 1669), matching baselinedotnet restore Cluckwork.sln --locked-modepasses on the committed locksTwo traps not in the brief, both handled here
10.*,1.*, ...) unlessCentralPackageFloatingVersionsEnabled=true. Set in the props file with a comment; the committed locks, not the ranges, pin what restores.Directory.Build.propsand now nameDirectory.Packages.propstoo:src/Cluckwork.Api/Dockerfilerestore layer (COPYbeforedotnet restore --locked-mode);docker build --target buildverified locally.ci.ymlRestore NuGet packages in Docker with committed lock files and locked mode #315 drift guard: the sed now perturbs thePackageVersionin the props file. Verified locally that the mutant fails withNU1004.ci.ymlsetup-dotnetcache-dependency-path;ci.ymlande2e-smoke.ymlimage-layerhashFileskeys.dependency-submission.ymlande2e-smoke.ymlpath filters..githooks/pre-committrigger.Docs: AGENTS.md (CI gates section), CONTRIBUTING.md dependencies, decision 146; the Microsoft.OpenApi and SSH.NET pin rationales are mirrored beside their
PackageVersionentries.Known and not this PR's: the weekly Dependabot
nugetjob may still show red from the pre-#685 CodeAnalysis.Common conflict.Summary by CodeRabbit
New Features
CI & Developer Experience
Documentation