Track the current majors for the actions the generator emits#533
Conversation
actions/setup-dotnet@v4 runs on the node20 runtime, which GitHub has scheduled for removal; v5 moves to node24 and is otherwise input-compatible, so the generated global-json-file step is unchanged apart from the tag. Every consumer inherits the pin from the generator, so a stale tag can only be worked around by replacing the whole run step. Quartz.NET carried exactly that workaround under NUKE. Covers the generator, the 28 Verify snapshots that assert the emitted YAML, the CI-docs sample, and this repo's own workflows (the generated ones would change on the next regeneration anyway). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extends the setup-dotnet bump to the other two actions the generator pins, and carries setup-dotnet to v6 — v5 was already superseded while this PR sat open. setup-dotnet v4 -> v6 (v6.0.0, 2026-07-16) checkout v6 -> v7 (v7.0.0, 2026-06-18) upload-artifact v5 -> v7 (v7.0.0, 2026-02-26) Same argument as before: consumers can't move these forward without replacing the emitted steps wholesale. test262-harness-dotnet does exactly that today — it carries custom step classes purely to reach checkout@v7 and upload-artifact@v7, which the generator can just emit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
lahma
changed the title
|
Widened while this sat open, and the setup-dotnet target moved. setup-dotnet@v5 was already stale. v6.0.0 shipped 2026-07-16, after this PR was opened against v5. Pushed the pin to v6 rather than landing a version that's superseded on arrival. Added checkout and upload-artifact, the other two actions the generator pins — v6→v7 and v5→v7. Folded into this PR rather than a second one because both touch the same 28 Verify snapshots and would conflict. Retitled accordingly; the branch name still says The motivating case is now concrete: test262-harness-dotnet carries custom step classes today solely to reach checkout@v7 and upload-artifact@v7. With this merged those classes delete outright. Specs re-run: 131 passed, 0 failed. |
|
Should we setup some sort of "heads-up tests"? Meaning: something that notifies us, when a new release is out.. |
NUKE is no longer maintained, so transitive-dependency advisories against it are never fixed upstream — build/_build.csproj carried three pins that existed only to route around that. Fallout is the maintained hard-fork successor. Mechanics: `fallout-migrate` handles the Nuke.* -> Fallout.* rewrite, the MSBuild property renames and .nuke -> .fallout. The one thing it can't is Nuke.Common.ProjectModel, which maps to Fallout.Solutions rather than a 1:1 prefix swap. CI shape changes with it. Fallout's generator no longer emits ./build.cmd steps — it emits setup-dotnet + `dotnet tool restore` + `dotnet fallout`, so the CLI is pinned in .config/dotnet-tools.json and build.ps1/build.sh are thin shims that restore it and forward. The setup-dotnet override goes with it: the generator emits its own step now, driven by global.json, which already pins 10.0.100. Ours existed only because NUKE emitted no SDK setup at all — keeping it would produce two setup-dotnet steps per job. Note this is a step back from @v5 to Fallout's @v4 until the upstream bump lands (Fallout-build/Fallout#533). The checkout / upload-artifact overrides stay. Fallout pins @v6 and @v5, the same versions NUKE did, so #162's argument is unchanged — those two custom steps are still the only way to reach @v7. Same PR upstream retires them. Pin cleanup, verified by restore rather than assumed: - NuGet.Packaging and YamlDotNet dropped; Fallout's transitive versions are clean and neither is referenced by the build code - System.Security.Cryptography.Xml kept; Fallout ships 10.0.6, inside the affected range of five advisories Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
I think easiest option would be to allow user's to override the action name/version via attribute property, then lagging a bit behind wouldn't stop users from getting the latest by updating their build. |
I agree. Should we get this one out to bump versions and at the same time open a gh issue to track this as a long-term solution? |
Either one is fine, but "separation of concerns"-wise, yes :) |
3 participants
The GitHub Actions generator hard-codes the action versions it emits, so a consumer can't move any of them forward — the only escape is subclassing
GitHubActionsAttributeand replacing the emitted steps. This moves all three to their current majors:actions/setup-dotnetactions/checkoutactions/upload-artifactsetup-dotnet@v4additionally runs on the node20 runtime GitHub has scheduled for removal.Why it matters downstream
Two repos migrating off NUKE hit this:
setup-dotnet@v5, because NUKE emitted no SDK setup at all. Dropped on migration, accepting@v4as a temporary step back.checkout@v7andupload-artifact@v7, with the stated intent of tracking action majors independently of the framework version. Those classes exist only because the generator's pins lag.That's the argument for the generator tracking current majors: every consumer that wants them otherwise reimplements step emission, and those reimplementations then drift from the framework's own output.
Scope
docs/05-cicd/github-actions.mdsample outputpublish-packages-*ones (the generated ones would change on the next regeneration regardless)One
checkout@v6string remains inGitHubActionsStepPipelineSpecs— that's a user-suppliedGitHubActionsCustomStepfixture, not a generator pin, so it's arbitrary sample input.dotnet test tests/Fallout.Common.Specs— 131 passed, 0 failed.🤖 Generated with Claude Code