chore(globaltool)!: rename Fallout.GlobalTool → Fallout.Cli#206
Merged
Conversation
3 tasks
Better install ergonomics: `dotnet tool install Fallout.Cli` is easier to
type and remember than `dotnet tool install Fallout.GlobalTool`. The
COMMAND name stays `fallout`; only the NuGet package ID and the C# project
name change.
## What's renamed
- `src/Fallout.GlobalTool/` → `src/Fallout.Cli/` (directory + `.csproj`)
- `tests/Fallout.GlobalTool.Tests/` → `tests/Fallout.Cli.Tests/`
- Namespace sweep: `namespace Fallout.GlobalTool[.*]` → `namespace Fallout.Cli[.*]` (48 .cs files)
- `fallout.slnx` — project paths updated
- `AssemblyInfo.cs` — `InternalsVisibleTo("Fallout.GlobalTool[.Tests]")` → `InternalsVisibleTo("Fallout.Cli[.Tests]")`
- `tests/Fallout.Cli.Tests/Fallout.Cli.Tests.csproj` — ProjectReference path
- `build/Build.cs` — `Solution.Fallout_GlobalTool` → `Solution.Fallout_Cli` (auto-generated identifier from the renamed project)
- `Directory.Packages.props` — comment update
- `src/Fallout.Build/Telemetry/Telemetry.cs` — telemetry cookie name and comment
- `src/Fallout.Build/Utilities/SchemaUtility.cs` — doc comment
- `src/Fallout.Build/Execution/Extensions/UpdateNotificationAttribute.cs` — `dotnet tool update Fallout.GlobalTool -g` → `Fallout.Cli -g` (also fixed the stale `nuke :update` to `fallout :update`)
- `tests/Fallout.SourceGenerators.Tests/StronglyTypedSolutionGeneratorTest.Test#Solution.g.verified.cs` — regenerated to match the renamed project
- `src/Fallout.Cli/templates/dotnet-tools.json` — template now emits `fallout.cli` pin with `_FALLOUT_CLI_VERSION_` placeholder, so `fallout :setup` creates the new shape for new repos
- `src/Fallout.Cli/Program.Setup.cs` (`WriteBuildScripts`) — token name change
- Docs sweep across `docs/**`, `CLAUDE.md`, `CONTRIBUTING.md` (excluding `CHANGELOG.md` historical entries and `docs/rebrand-plan.md`, which now carries a note explaining the post-rebrand tool rename)
## NOT in this PR (deliberate)
- **This repo's `.config/dotnet-tools.json`** stays pinned to `fallout.globaltool` 10.3.37 — the only version of `Fallout.Cli` doesn't exist on nuget.org yet (this PR creates it). Otherwise the PR's own `dotnet tool restore` would fail. **Follow-up PR** flips this manifest to `Fallout.Cli` once the new package is live on nuget.org.
- `Fallout.GlobalTool 10.3.x` versions already on nuget.org stay published. Old consumers keep working until they re-run `fallout :setup` or update their manifest by hand.
## Release / nuget.org reservation gotcha
`Fallout.Cli` is a new package ID under the `Fallout.*` prefix reservation. Per the prefix-gotcha [pattern](https://github.com/ChrisonSimtian/Fallout/issues/33 follow-ups), the FIRST push of a new `Fallout.X` ID must be a manual web upload to nuget.org; subsequent CI pushes succeed. So after this PR merges:
1. `release.yml` runs and packs `Fallout.Cli.10.3.x.nupkg`.
2. The `nuget push` step will 403 on `Fallout.Cli` (other packages publish normally because of `--skip-duplicate`).
3. Maintainer manually web-uploads ONE `Fallout.Cli.*.nupkg` (either from the failed CI run's artifacts or the locally-packed prerelease in `output/packages/`).
4. Subsequent CI publishes succeed.
A locally-packed prerelease (`Fallout.Cli.10.3.39-g7885ec5647.nupkg`) is included in `output/packages/` after a local `dotnet pack` — that's the .nupkg to web-upload to reserve the ID before merge if desired.
## Verification
- `dotnet build src/Fallout.Cli/Fallout.Cli.csproj` — 0 errors, only pre-existing warnings.
- `dotnet test tests/Fallout.Cli.Tests/` — 17/17 passed.
- `dotnet test tests/Fallout.SourceGenerators.Tests/` — 6/6 passed (the strongly-typed solution generator emits `Fallout_Cli` / `Fallout_Cli_Tests` properties in the expected alphabetical position).
- `dotnet pack src/Fallout.Cli/Fallout.Cli.csproj -c Release -o output/packages` — produces `Fallout.Cli.10.3.39-g7885ec5647.nupkg`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ChrisonSimtian
force-pushed
the
feature/rename-globaltool-to-cli
branch
from
May 27, 2026 00:34
ef973e0 to
122bbf5
Compare
This was referenced May 27, 2026
ChrisonSimtian
added a commit
that referenced
this pull request
May 27, 2026
…209) Two small follow-ups after the Fallout.GlobalTool → Fallout.Cli rename (#206) and the first-publish 403 we hit on the release pipeline (#208). ## 1. Flip this repo's `.config/dotnet-tools.json` to `Fallout.Cli` `Fallout.Cli 10.3.41` is now live on nuget.org (post-merge release pipeline rerun published it once the org-ownership issue cleared). Switching this repo's local tool manifest from the legacy `fallout.globaltool 10.3.37` pin to `fallout.cli 10.3.41`. Verified locally: > dotnet tool restore Tool 'fallout.cli' (version '10.3.41') was restored. Available commands: fallout Restore was successful. ## 2. Document the nuget.org first-publish gotcha in CLAUDE.md The "release pipeline" section already mentioned the `Fallout.*` prefix reservation but didn't cover the operational footgun we just hit: the nuget.org upload UI defaults the package owner to your personal account, not the org. Even after a successful upload that reserves the ID, the org's `NUGET_API_KEY` 403s on subsequent CI pushes until ownership is transferred to the org. Added two short paragraphs to the "Release pipeline" section walking through: 1. The owner-defaults-to-personal trap (with the fix), linked to #208. 2. The 5-30 min validation lag between upload-accepted and API-key-permission-propagated. So next time someone (likely future-Claude or future-Chris) adds a new `Fallout.X` package, this footgun is the first thing they see. ## Refs - #206 — Fallout.GlobalTool → Fallout.Cli rename (merged). - #208 — bug report for the ownership-mismatch we hit (will close once this doc note lands). Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ChrisonSimtian
added a commit
that referenced
this pull request
May 27, 2026
Two gaps in the README, both surfaced by Chris during the Fallout.GlobalTool → Fallout.Cli rename (#206): 1. No `dotnet tool install -g Fallout.Cli` one-liner anywhere on the landing page. The closest install command was `Fallout.Migrate` in the migration section, which doesn't help people who just want to install the build CLI. 2. No mention of the `Fallout.GlobalTool` → `Fallout.Cli` rename for existing users. If you installed `Fallout.GlobalTool` (10.3.37 ever shipped) and now install `Fallout.Cli`, both packages claim the `fallout` command — dotnet errors out on the second install with `Tool 'fallout' is already installed`. New "Install" section after "Migrating from NUKE": - `dotnet tool install -g Fallout.Cli` as the install one-liner. - A note callout for upgraders pointing them at `dotnet tool uninstall -g Fallout.GlobalTool` first. - Link to the full installation guide on docs.fallout.build (which covers the local-tool-manifest flow, shell completion, etc.). Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ChrisonSimtian
added a commit
that referenced
this pull request
May 27, 2026
…nfig group (#211) Two small cosmetic follow-ups noted but never tracked after the bootstrapper deprecation (#203) and the Fallout.Cli rename (#206) landed. ## 1. Remove `Program.Build()` and its sole caller `Program.Build(buildScript, args)` was a fire-and-forget process spawner that shelled out to `build.sh` / `build.ps1`. It existed for one path: when `fallout :complete` ran the first time in a repo (before any build had populated `.fallout/build.schema.json`), it primed the pump by spawning the shim with `--completion`. Now that: - Shims are thin (just `dotnet tool restore` + `dotnet fallout`), so spawning them is a longer subprocess hop than calling the in-tool runner directly. - `HandleShellCompletionAttribute` writes the schema on **every** non-legacy build invocation (not just `--completion`), so any normal `fallout <target>` run generates it. …the priming logic is redundant. Drop `Build()` and replace the call site in `Program.Complete.cs` with a plain `return 1;` (first TAB still shows no completions when no schema exists; the user's next `fallout <target>` run populates it and TAB works thereafter). Matches what already happened on the ground but didn't get cleaned up. Also drops now-unused `using System.Diagnostics;` and `using Fallout.Common.Tooling;` from `Program.cs`. ## 2. Surface `.config/dotnet-tools.json` in the IDE config link group `Fallout.Common.targets` already links the boot shims (`build.cmd`, `build.ps1`, `build.sh`) and the config files (`global.json`, `nuget.config`, `parameters.json`, etc.) into the build project so they show up in IDE solution explorers under the `boot/` and `config/` virtual folders. `.config/dotnet-tools.json` was missing from that list — it's a declarative tool-version pin in the same shape as `global.json` / `nuget.config`. Added it to the `config` ItemGroup (alongside `global.json`, `version.json`, etc.) with the same `Exists()` guard the other entries use. Cosmetic — only affects IDE solution-explorer rendering. No build behavior change. ## Verification - `dotnet build src/Fallout.Cli/Fallout.Cli.csproj` — 0 errors, only pre-existing warnings. - `dotnet test tests/Fallout.Cli.Tests/` — 17/17 passed. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
ChrisonSimtian
added a commit
that referenced
this pull request
May 27, 2026
… CLAUDE.md Three breaking changes shipped under 10.3.x patch releases over the past two days: - #206 chore(globaltool)!: rename Fallout.GlobalTool → Fallout.Cli - #204 feat(globaltool)!: thin shims + local tool manifest, drop build.cmd - #212 fix(security)!: AES-GCM v2 secret format with per-secret salt+nonce CHANGELOG.md has had an `[Unreleased] — 11.0` heading with extensive breaking-change entries since the takeover (STJ migration, schema rewrite, etc.), but `version.json` stayed pinned at 10.3 and every release shipped as 10.3.x. Net effect: consumers updating from 10.3.40 → 10.3.45 silently inherited a package rename and a secret- format change — exactly the failure mode semver exists to prevent. This PR bumps `version.json` to 11.0 so the next release becomes 11.0.x. The 10.3.x releases on nuget.org are already published and stay where they are; this PR stops the bleeding from this point forward. Also adds a **Semver policy** section to CLAUDE.md so the rule is explicit and reviewer-enforceable: - Any `!` commit (or flagged breaking change) requires bumping the major in `version.json` in the same PR. - Patch increments from git-height are reserved for non-breaking fixes. - Reviewer responsibility: block merge until the bump is in. - Add a CHANGELOG.md entry under `[Unreleased] — <next-major>`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ChrisonSimtian
added a commit
that referenced
this pull request
May 27, 2026
… CLAUDE.md (#220) Three breaking changes shipped under 10.3.x patch releases over the past two days: - #206 chore(globaltool)!: rename Fallout.GlobalTool → Fallout.Cli - #204 feat(globaltool)!: thin shims + local tool manifest, drop build.cmd - #212 fix(security)!: AES-GCM v2 secret format with per-secret salt+nonce CHANGELOG.md has had an `[Unreleased] — 11.0` heading with extensive breaking-change entries since the takeover (STJ migration, schema rewrite, etc.), but `version.json` stayed pinned at 10.3 and every release shipped as 10.3.x. Net effect: consumers updating from 10.3.40 → 10.3.45 silently inherited a package rename and a secret- format change — exactly the failure mode semver exists to prevent. This PR bumps `version.json` to 11.0 so the next release becomes 11.0.x. The 10.3.x releases on nuget.org are already published and stay where they are; this PR stops the bleeding from this point forward. Also adds a **Semver policy** section to CLAUDE.md so the rule is explicit and reviewer-enforceable: - Any `!` commit (or flagged breaking change) requires bumping the major in `version.json` in the same PR. - Patch increments from git-height are reserved for non-breaking fixes. - Reviewer responsibility: block merge until the bump is in. - Add a CHANGELOG.md entry under `[Unreleased] — <next-major>`. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merged
2 tasks
ChrisonSimtian
added a commit
that referenced
this pull request
May 27, 2026
…l→Cli migration guide (#225) Closes the two follow-ups noted in #220's PR body — the v11 record now covers every breaking change that shipped under 10.3.x and were catalysed by the semver-policy fix. CHANGELOG.md — three new entries under [Unreleased] — 11.0, most-recent first: - #214 AES-GCM v2 secret format - #206 Fallout.GlobalTool → Fallout.Cli package rename - #204 thin shims + dotnet-tools manifest + GitHubActions generator regen (PR-B of #203) docs/migration/from-globaltool-to-cli.md — focused migration guide covering the three consumer scenarios (global install, local manifest, shims) plus the affected-versions table noting both the renamed Fallout.GlobalTool freeze at 10.3.40 and the 10.3.41-47 Fallout.Cli unlist done via tools/Unlist-NugetPackage.ps1.
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
Better install ergonomics:
dotnet tool install Fallout.Cliis easier to type and remember thandotnet tool install Fallout.GlobalTool. The COMMAND name staysfallout; only the NuGet package ID and the C# project name change.What's renamed
src/Fallout.GlobalTool/→src/Fallout.Cli/(directory +.csproj)tests/Fallout.GlobalTool.Tests/→tests/Fallout.Cli.Tests/namespace Fallout.GlobalTool[.*]→namespace Fallout.Cli[.*](48 .cs files viagit mv+ content sweep)fallout.slnxproject pathsAssemblyInfo.cs— InternalsVisibleTo entriesbuild/Build.cs—Solution.Fallout_GlobalTool→Solution.Fallout_Cli(the strongly-typed solution generator emits the new identifier from the renamed project)src/Fallout.Build/Telemetry/Telemetry.cs— telemetry awareness cookie namesrc/Fallout.Build/Execution/Extensions/UpdateNotificationAttribute.cs—dotnet tool update Fallout.GlobalTool -g→Fallout.Cli -g(also fixed a stalenuke :updatetofallout :updatewhile in the neighbourhood)tests/Fallout.SourceGenerators.Tests/StronglyTypedSolutionGeneratorTest.Test#Solution.g.verified.cs— updated to match the renamed projectsrc/Fallout.Cli/templates/dotnet-tools.json— template now emitsfallout.clipin with_FALLOUT_CLI_VERSION_placeholder, sofallout :setupcreates the new shape for new reposdocs/**,CLAUDE.md,CONTRIBUTING.mdNOT in this PR (deliberate)
.config/dotnet-tools.jsonstays pinned tofallout.globaltool10.3.37 —Fallout.Clidoesn't exist on nuget.org yet (this PR creates it). Otherwise the PR's owndotnet tool restorewould fail. A follow-up PR flips this manifest toFallout.Clionce the new package is live on nuget.org.CHANGELOG.mdhistorical entries — left as-is per project convention. Future entries describe the rename.docs/rebrand-plan.md— kept; the mapping row forNuke.GlobalToolnow points toFallout.Cliwith a note explaining the post-rebrand tool rename.Fallout.GlobalTool 10.3.xversions already on nuget.org stay published. Old consumers keep working until they re-runfallout :setupor update their manifest manually.Release / nuget.org reservation gotcha
Fallout.Cliis a new package ID under theFallout.*prefix reservation. Per the prefix-gotcha, the FIRST push of a newFallout.XID must be a manual web upload to nuget.org; subsequent CI pushes succeed. After this PR merges:release.ymlruns and packsFallout.Cli.10.3.x.nupkg.nuget pushstep will 403 onFallout.Cli(other packages publish normally because of--skip-duplicate).Fallout.Cli.*.nupkgto reserve the ID.A locally-packed prerelease (
Fallout.Cli.10.3.39-g7885ec5647.nupkg) is sitting inoutput/packages/after a localdotnet pack— that's available to upload before the merge to pre-reserve the ID.Verification
dotnet build src/Fallout.Cli/Fallout.Cli.csproj— 0 errors, only pre-existing warnings.dotnet test tests/Fallout.Cli.Tests/— 17/17 passed.dotnet test tests/Fallout.SourceGenerators.Tests/— 6/6 passed (the strongly-typed solution generator emitsFallout_Cli/Fallout_Cli_Testsproperties in the expected alphabetical position).dotnet pack src/Fallout.Cli/Fallout.Cli.csproj -c Release -o output/packages— producesFallout.Cli.10.3.39-g7885ec5647.nupkg.Test plan
ubuntu-latestCI goes green —dotnet tool restorestill resolvesfallout.globaltool10.3.37 (manifest unchanged); the renamed project compiles; tests pass.Fallout.Cli.*.nupkgto nuget.org to reserve the ID (either pre-merge from the local pack, or post-merge from the release-pipeline artifact)..config/dotnet-tools.jsonto pinFallout.Cli.