Skip to content

Point the scenarios at the package ids and version line that actually ship - #12

Merged
ChrisonSimtian merged 1 commit into
mainfrom
fix/stale-package-ids-and-float-range
Aug 22, 2026
Merged

Point the scenarios at the package ids and version line that actually ship#12
ChrisonSimtian merged 1 commit into
mainfrom
fix/stale-package-ids-and-float-range

Conversation

@ChrisonSimtian

Copy link
Copy Markdown
Contributor

Fixes all three canary scenarios. They were red for two unrelated reasons.

What changed

  • minimal + transition-shims float at 10.*-* instead of 2026.1.*-*. The 2026.1.x line was retired when the repo moved back to 10.x, and the last 2026.1.0 prereleases have since been deleted from the feed, so the range had no candidates and restore failed with NU1102. 10.*-* tracks the whole 10.x line, so it survives 10.410.5 without an edit. Floating is kept on purpose, per the locked decision in docs/DESIGN.md.
  • tool-manifest tracks Fallout.GlobalTool (singular) and reports on fallout.globaltools as retired. The two roles were the wrong way round.
  • The tool-list assertion is now ^fallout\.globaltool[[:space:]]. The old prefix match would have accepted the plural id and passed against the wrong package.
  • Dropped the stale fallout.globaltools source mapping. Fallout.* already routes the tool to the GitHub Packages feed.
  • Updated README.md, docs/DESIGN.md, Directory.Build.props and the scenario README, which all still quoted 2026.1.*-* or the plural id.

Why the tool ids were inverted

Fallout-build/Fallout#575 recorded the rename Fallout.GlobalToolFallout.GlobalTools, and this scenario was built to guard it. The rename was then reverted: Fallout.Cli.csproj sets <PackageId>Fallout.GlobalTool</PackageId> again. The plural id got exactly one nuget.org release, 10.4.0-rc.4, which has since been unlisted — so dotnet tool update Fallout.GlobalTools --prerelease had nothing to resolve. This is the regression the scenario exists to catch, just in the direction nobody expected.

Verification

Ran all three scenarios locally against the live feeds, not just inspected:

minimal            Fallout.Common/10.4.1-preview.1.g9467569f76   restore OK
transition-shims   Nuke.Common/10.4.1-preview.1.g9467569f76      restore OK
tool-manifest      fallout.globaltool 10.4.0                     update + restore + tool list OK

Both package scenarios resolve the current head of main. The tightened assertion was checked both ways: it matches the singular id and rejects the plural.

canary.yml parses as YAML; every edited XML and JSON file parses. No 2026.1 reference remains in the repo.

Notes

  • tool-manifest was already failing before the feed cleanup — it reads nuget.org only, so the deletions never affected it. minimal and transition-shims were green on 2026-08-17 and broke when the 2026.1.0 prereleases were removed.
  • The retired-id deprecation reporting step still passes continue-on-error: true, so it reports without failing the scenario. Deprecating the retired ids on nuget.org is still the manual action tracked in Fallout-build/Fallout#575.

… ship

All three scenarios were failing. Two separate causes.

The `minimal` and `transition-shims` scenarios floated at `2026.1.*-*`. That
version line was retired when the repo moved back to `10.x`, and the last
`2026.1.0` prereleases have now been deleted from the feed, so the range had no
candidates left and restore failed with NU1102. They now float at `10.*-*`,
which tracks the whole `10.x` line and does not need editing when the minor
moves. Floating is kept deliberately, per the locked decision in docs/DESIGN.md.

The `tool-manifest` scenario had the package ids inverted. It treated
`Fallout.GlobalTools` as the published id and `fallout.globaltool` as retired,
but `Fallout.Cli.csproj` sets `<PackageId>Fallout.GlobalTool</PackageId>` again,
so the singular id is canonical. The plural id got one nuget.org release
(`10.4.0-rc.4`, since unlisted), which is why `dotnet tool update` could not
find a version. The two roles are swapped back, so the scenario tracks the
singular id and reports on the retired ones. This is exactly the regression the
scenario exists to catch, in the opposite direction.

Also tighten the tool-list assertion to `^fallout\.globaltool[[:space:]]`. The
old `^fallout\.globaltool` prefix match would have accepted the plural id and
passed on the wrong package.

Drop the now-stale `fallout.globaltools` source mapping. The `Fallout.*` pattern
already routes the tool to the GitHub Packages feed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@ChrisonSimtian ChrisonSimtian added the bug Something isn't working label Aug 22, 2026
@ChrisonSimtian
ChrisonSimtian marked this pull request as ready for review August 22, 2026 12:48
@ChrisonSimtian
ChrisonSimtian merged commit 0ae4996 into main Aug 22, 2026
3 checks passed
@ChrisonSimtian
ChrisonSimtian deleted the fix/stale-package-ids-and-float-range branch August 22, 2026 12:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant