fix(ci): derive package-validation dependency ranges from Directory.Packages.props - #125
Merged
ncipollina merged 1 commit intoSep 2, 2026
Conversation
…ackages.props (#122) inspect-packed-nupkgs.sh's assert_dependency_range hardcoded each expected third-party dependency range as a duplicate literal, separate from the Directory.Packages.props PackageVersion that already states the same policy. Dependabot updates the latter but not the former, so a correct package bump (e.g. PR #121's TUnit.Core update) failed validation until someone noticed and hand-edited the script (5cfe446). assert_dependency_range now looks up the expected range from Directory.Packages.props itself, evaluated via `dotnet msbuild -getItem` (SDK-native, no new CI dependency) and matched by dependency ID via jq. The validator still independently compares that authoritative value against the actually-packed .nuspec - only the duplicated literal is gone, not the check's strength. A missing Directory.Packages.props entry now fails with a distinct diagnostic instead of masquerading as a packed-range mismatch. Adds inspect-packed-nupkgs.tests.sh, a dependency-free regression suite proving both the pass and fail cases, including the exact "bump only the props file" scenario from issue #122, wired into package-validation.yaml. Amends ADR-0031 to record the drift and the fix. Closes #122 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GMQEjFrUVGYkctE3ECfRuA
ncipollina
deleted the
fix/122-package-validation-dependency-range-drift
branch
September 2, 2026 19:37
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.
Summary
inspect-packed-nupkgs.sh'sassert_dependency_rangehardcoded each expected third-party dependency range as a literal separate fromDirectory.Packages.props'sPackageVersion, which already states the same policy for MSBuild. Dependabot updates the latter but not the former, so a correctly-packed bump (PR chore: Bump the dotnet-minor-patch group with 3 updates #121'sTUnit.Coreupdate) failed validation until manually patched (5cfe446).assert_dependency_rangenow derives its expected range fromDirectory.Packages.propsitself (viadotnet msbuild -getItem:PackageVersion, SDK-native, plusjq, already a CI dependency) instead of a duplicated string. The validator still independently compares that value against the actually-packed.nuspec— only the duplicated literal is gone.inspect-packed-nupkgs.tests.sh, a dependency-free regression suite proving pass/fail cases including the exact "bump only the props file" scenario from [Bug]: package-validation dependency-range literals drift when Dependabot bumps Directory.Packages.props #122, wired intopackage-validation.yaml.Fixes all five current dependency-range checks structurally:
Compono.XunitV3,Compono.NSubstitute,Compono.Bogus,Compono.TUnit,Compono.MSTest.Closes #122
Test plan
dotnet build Compono.slnx— cleandotnet test Compono.slnx -f net10.0— 976/976 passed.github/scripts/inspect-packed-nupkgs.tests.sh— all regression cases pass (matching range, mismatched range, bump-only-props-file, bump-with-stale-nuspec, missing-authoritative-entry diagnostic, real-repo sanity check)inspect-packed-nupkgs.shagainst real output — all five dependency-range checks pass, readingDirectory.Packages.propsdirectlyTUnit.CoreinDirectory.Packages.propsonly (to[1.65.68, 2.0.0)), repackedCompono.TUnit, ran the validator without touching the script — passed. Reverted the bump and repacked back to the original range — passed again.🤖 Generated with Claude Code
https://claude.ai/code/session_01GMQEjFrUVGYkctE3ECfRuA