build: prevent version drift with CPM and Dependabot grouping - #135
Merged
Conversation
Cat5Dog2
force-pushed
the
chore/deps-2026-08
branch
from
August 5, 2026 01:56
b4680b2 to
d5de28f
Compare
Cat5Dog2
force-pushed
the
chore/central-package-management
branch
from
August 5, 2026 02:00
6847c0e to
ed9108c
Compare
Cat5Dog2
changed the title
Cat5Dog2
changed the title
Moves all PackageVersion entries into a root Directory.Packages.props and strips the inline versions from the three project files. The drift this repo just hit was cross-project: Web.Tests sat on Test SDK 18.6.0 while E2ETests was on 18.7.0, and nothing in the build objected. Under CPM that state is unrepresentable, because the version exists in exactly one place. Dependabot grouping reduces how often the versions are allowed to diverge; CPM removes the ability to express the divergence at all. They address the same failure from different ends. Versions are written as literals rather than shared MSBuild properties, which departs from the usual CPM style. A $(Var) indirection is only worth having if Dependabot can resolve and rewrite it, and if it cannot, the failure is the silent one this whole exercise is about: no PR gets opened and nothing announces that. Keeping ASP.NET Core and EF Core moving together is already handled by the aspnetcore-efcore group, so the indirection buys little and risks a lot. Resolved versions are unchanged from the previous commit: verified with dotnet list package across all three projects. Build clean, 240 unit tests, 8 Playwright E2E tests, dotnet format --verify-no-changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three changes to the nuget ecosystem, plus a correction to an earlier claim of mine. Scan directories gain "/". Both the CPM manifest added in the previous commit and the existing dotnet-tools.json live at the repository root, which /src/** and /tests/** do not cover. This, not a gap in Dependabot, is why dotnet-ef sat on 10.0.9 while EF Core moved: Dependabot has discovered and analyzed dotnet-tools.json since 2024 (dependabot-core#8889 and #10269). An earlier commit message in this branch stated the opposite and was wrong. Grouping ASP.NET Core, EF Core and dotnet-ef together is the substantive fix. They ship as one train, and splitting them into separate PRs is what let Design/Tools drift ahead of SqlServer. Major bumps stay ungrouped so something like ImageSharp 3.x to 4.0 still lands on its own. The limit goes from five to ten. At the limit Dependabot defers opening the remaining PRs to a later run rather than dropping them, but nothing reports the deferral, so four packages sat on 10.0.9 with no PR and no signal. github-actions is deliberately left ungrouped. Dependabot already emits one PR per action across every workflow that uses it, which is what #130 did for setup-dotnet across five files, so a group adds nothing there while making unrelated major bumps share a PR and a CI failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cat5Dog2
force-pushed
the
chore/central-package-management
branch
from
August 5, 2026 03:17
ed9108c to
425ea66
Compare
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.
#134 has been folded into this PR and closed, following review. That removes the stacked-base problem and cuts production deploys from three to two.
Corrections from review
Three claims in the original version were wrong. Thanks for catching them.
1. "Dependabot does not watch
dotnet-tools.json" — incorrectIt has since 2024: discovery in dependabot-core#8889, update analysis in dependabot-core#10269.
The real reason
dotnet-efwas stranded on 10.0.9 is that the scan directories were only/src/**and/tests/**, and the manifest sits at the repository root. Adding"/"brings it into scope, and addingdotnet-efto theaspnetcore-efcoregroup means it now moves in the same PR as EF Core.2. Grouping every GitHub Action together is too broad
The original rationale — that a group was needed to update one action across several workflows — was simply wrong. Dependabot already emits one PR per action spanning every workflow that uses it; #130 updated
setup-dotnetacross five files with no grouping at all.A group would only make unrelated major bumps share a PR and a CI failure, so the group is removed. Only the limit increase (2 → 5) remains.
3. "Updates that hit the limit are dropped and never return" — overstated
The accurate statement is that PR creation is deferred until a slot frees up, and that the deferral is never reported. Corrected in both the commit messages and this description.
Why both CPM and the Dependabot config are needed
The drift here came in three distinct kinds:
dotnet-ef10.0.9"/"Grouping lowers how often versions are allowed to diverge, but the structure that permits divergence survives. Under CPM a version exists in exactly one place, so cross-project drift becomes unrepresentable rather than merely unlikely.
Changes
Commit 1 — CPM
Directory.Packages.propsat the repository root (20PackageVersionentries)Version=attributes stripped from the three project files (26PackageReferenceentries)Commit 2 — Dependabot configuration
"/"added to the nuget scan directoriesaspnetcore-efcore(includingdotnet-ef),test-tooling,azureDesign decision: literal versions, not shared MSBuild properties
Conventional CPM style would bundle the 10.0.x packages behind something like
$(MicrosoftPlatformVersion). This PR writes literals instead.The indirection is only worth having if Dependabot can resolve and rewrite it. If it cannot, the failure mode is precisely the silent one this whole exercise is about: no PR gets opened, and nothing announces it. Keeping ASP.NET Core and EF Core moving in step is already the
aspnetcore-efcoregroup's job, so the property buys little and risks a lot. The reasoning is recorded in a comment at the top ofDirectory.Packages.props.Verification
Resolved versions are identical to #133, confirmed with
dotnet list packageacross all three projects. The CPM migration changes no versions.scripts/build.ps1— 0 warnings, 0 errorsscripts/test.ps1— 240 passed, 0 failedscripts/test-e2e.ps1 -InstallBrowsers— 8 passed, 0 failedscripts/format.ps1— OKWith CPM enabled, any
PackageReferencestill carrying aVersion=fails the build with NU1008, so the build itself catches an incomplete migration.To confirm after merging
Parsing the YAML does not prove that discovery and grouping behave as intended. Once this reaches the default branch, check the Dependabot Update logs to confirm both
Directory.Packages.propsanddotnet-tools.jsonare actually detected.The manifest is at the repository root rather than
.config/dotnet-tools.json, so that placement in particular is worth confirming empirically. If it goes undetected, moving it under.config/is the fallback.🤖 Generated with Claude Code