Uh oh!
There was an error while loading. Please reload this page.
Upmerge main into develop - #656
Merged
Merged
Conversation
…NOR as a public ref Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A tag-triggered release build checks out a detached HEAD, where GitRepository.Branch is null. Two specs assumed the ambient checkout was on a named branch and broke the release pack: - GitRepositoryWorktreeSpecs derived the worktree base ref from .Branch (null → empty), producing 'git worktree add -b … <empty>' which fails with 'fatal: invalid reference'. Base the worktree on HEAD instead, which resolves in both attached and detached states. - GitHubTasksSpecs.GitHubRepositoryFromLocalDirectorySpec builds branch-based URLs (GetGitHubDownloadUrl asserts Branch != null). Guard for a null branch and return early, mirroring the existing non-GitHub early-return. Both pass on a branch (unchanged) and no longer fail on a detached HEAD. Surfaced by the first real tag-triggered release (v10.4.0-rc.1). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The release pipeline was built around CalVer release/YYYY + legacy
support/* lines, so a legacy-style minor release line (release/v10.4)
cut from main is rejected at two gates:
- validate-ref in publish-packages-release.yml only matched
release/[0-9]{4} and support/*, so a v* tag on release/v10.4 fails
the reachability check and every downstream publish job is skipped.
- publicReleaseRefSpec in version.json didn't match release/vN.N, so
NB.GV treated such branches as non-public and git-sha-suffixed the
version instead of producing a clean -rc.N.
Teach both the release/v\d+\.\d+ shape so tag pushes on a release/v10.x
line validate and publish on their own.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>(cherry picked from commit 3595f0f)
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> (cherry picked from commit 0f008cb)
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> (cherry picked from commit 8bb241f)
10.0.6, 9.0.15 and 8.0.3 are all inside the affected ranges of five high-severity advisories (GHSA-23rf-6693-g89p, GHSA-8q5v-6pqq-x66h, GHSA-cvvh-rhrc-wg4q, GHSA-g8r8-53c2-pm3f, GHSA-mmjf-rqrv-855v) — uncontrolled resource consumption in XML decryption. Move each line to its first patched release: 10.0.10, 9.0.18, 8.0.4. Fallout.Common carries the package as a direct dependency, so every consumer inherits the vulnerable version transitively and has to pin around it locally. Both the central version list and build/_build.csproj are bumped; the build project turns off central package management, so its inline pin is separate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit bd6471b)
(cherry picked from commit 394a6a2)
(cherry picked from commit fcd2be0)
The generator's cache pin sat at v4 while #533 moved checkout, setup-dotnet, and upload-artifact to their current majors — cache was never in that PR's scope. v6.1.0 is current; v4 is two majors behind. - v5.0.0 moved to the node24 runtime and requires a self-hosted runner >= 2.327.1 - v6.0.0 updated dependencies and migrated to ESM The `path:` and `key:` inputs the generator emits are unchanged across both, so the emitted step needs no other edits. Covers the generated workflows, the hand-written publish-packages-* ones, the 14 Verify snapshots with a cache step, and the docs sample. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vn8JQZRwdoovPuctD21Wjx (cherry picked from commit 94fa5fc)
The generator hard-coded the four actions it emits, so a consumer who wanted a newer major — or a SHA pin — had to subclass GitHubActionsAttribute and reimplement step emission. Two repos migrating off NUKE carried custom step classes for exactly that (#533). Each emitting step now carries a normalizing property, forwarded from four new attribute properties: CheckoutAction, CacheAction, SetupDotNetAction, UploadArtifactAction A trailing '# comment' is split off before the value is classified, so a '/' or '@' inside it never sways the decision — that is what makes the SHA-pinning idiom work. What remains is a complete reference when it contains an '@', emitted verbatim; otherwise a bare ref appended to the pinned action, so "v8" becomes actions/checkout@v8. A ref that itself contains a '/' reads exactly like an owner/repo, so it takes a leading '@' — "@releases/v1" — and the ambiguous bare form is rejected rather than guessed at. Null or whitespace restores the default. The reference token must carry no whitespace: it is emitted into an unquoted YAML scalar, where a stray ': ' would corrupt the whole workflow file. All four are resolved up-front in GetConfiguration. The cache and artifact steps are conditional, so their overrides would otherwise go unvalidated — and silently ignored — whenever caching or publishing is off, surfacing the typo only when the step was re-enabled. Rejections name the property and workflow that carry the value, so the message points at the declaration to fix. Resolution lives in the step setters, so subclasses and hand-built steps get the same shorthand and validation. GitHubActionsCustomStep.Uses has no default to resolve against and is emitted verbatim, so it must now name its action in full — otherwise the shorthand documented for the built-in steps silently produced an unusable 'uses: v8', and a multi-line value could inject arbitrary keys into the generated workflow. GitHubActionsDefaults is internal: the properties take a plain string, so nothing a consumer writes needs the type. That also keeps it out of the Nuke.* transition shims, which mirror public types but cannot carry const members and would have exposed an empty class. Closes#534 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vn8JQZRwdoovPuctD21Wjx (cherry picked from commit 4695319)
The telemetry feature carried over from NUKE has been inert since the fork: its Application Insights endpoint was the original maintainer's and can't be reused, the client dependency was dropped (#79), and TrackEvent was a stub. It was kept dormant on the intent of wiring up a Fallout-owned backend later — an intent with no owner, endpoint, or plan. Per ADR-0010, Fallout collects no telemetry, so the subsystem is removed rather than left as a dormant liability. Removes the Telemetry classes and the [Telemetry] build extension, every call site (the FalloutBuild attribute, the config-generation hook, and the setup / add-package / cake-convert CLI events), the FALLOUT_TELEMETRY_OPTOUT / NUKE_TELEMETRY_OPTOUT env vars, the FalloutTelemetryVersion / NukeTelemetryVersion MSBuild property (including its legacy lift and FALLOUT001 warning), the FalloutTelemetryDocsUrl constant, and the test-run opt-out plumbing. Not a breaking change: the env var and property only ever gated a no-op, and an unset/unknown one is silently ignored. The .NET SDK's own DOTNET_CLI_TELEMETRY_OPTOUT is left in place. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit 3fb29a1)
The migrate tool rewrote NUKE's telemetry knobs to Fallout-branded equivalents: NukeTelemetryVersion → FalloutTelemetryVersion and NUKE_TELEMETRY_OPTOUT → FALLOUT_TELEMETRY_OPTOUT. With telemetry removed (ADR-0010) those targets no longer exist, so renaming would plant dead, telemetry-branded cruft in every migrated project. Drop the rename rules and strip the knobs instead: RewriteCsprojsStep removes the <(Nuke|Fallout)TelemetryVersion> element line, ScriptRewriter removes any (NUKE|FALLOUT)_TELEMETRY_OPTOUT assignment line (bash/pwsh/cmd spellings). Specs updated to assert the knobs are gone rather than renamed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit 1dd17fa)
Records the decision that Fallout collects no telemetry — reversing the prior "kept dormant, wire up a Fallout endpoint later" stance — and its rationale, non-breaking impact, and the alternatives (keep dormant / opt-in / local-only) that were rejected. Adds a "No telemetry" convention, drops the now-removed Microsoft.ApplicationInsights row from the dependency overview, updates the from-nuke migration guide to show the telemetry knobs are stripped, and rewords the build-events example that used telemetry as its illustration. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit a9cf97f)
Review feedback: the ADR was verbose and the conventions bullet was unnecessary — an AI agent isn't going to reintroduce telemetry by accident, and the stale "opt-out is set in test runs" bullet it replaced is now wrong either way. ADR-0010 stays the single record. The ADR loses the "Removed surface" recap (duplicated the PR body), and its context/alternatives are condensed; every decision it carried is intact. Its header also moves to the house `## Status` shape used by ADR-0007/0008. (cherry picked from commit d879e11)
… names The telemetry opt-out strip is line-based, so it handles bash `export`, PowerShell `$env:`, and cmd `set` alike — but only `export` was specced. Turn that spec into a theory over all three bootstrap-script spellings. Also renames both touched spec files to the AV1600 behaviour-focused naming the repo is migrating to (docs/agents/conventions.md). (cherry picked from commit 336bcfc)
Adds BuildContext — an internal, per-run, AsyncLocal-ambient scope activated at the top of BuildManager.Execute and disposed at method exit, so the process- global statics a build touches are owned by a scope rather than leaking across invocations. It takes over the Console.CancelKeyPress / ToolOptions.Created subscriptions, the cancellation-handler list (moved off BuildManager), and the teardown FT-1 centralised. BuildManager.CancellationHandler becomes a thin facade over BuildContext.Current — the first static-surface-over-the-context seam. Because the handler list is owned by the context and discarded wholesale on dispose, BuildExecutor's ExecuteAssuredTargets subscription, which was never explicitly unsubscribed, no longer persists across in-process invocations. Dispose splits by ownership: this scope's own subscriptions come off unconditionally, while the process-wide resets run only when the context is still Current, so a superseded scope disposing out of order cannot tear down state belonging to a newer run. Internal-only — not a public contract until the SDK lands (milestone #7). FT-2 / #307. (cherry picked from commit 404b5f1)
Covers the new surface: the Current lifecycle, the identity guard that stops a superseded context both from clobbering a newer Current and from running the process-wide resets, the cancellation-handler facade's no-op outside a run, and the per-run teardown across the in-memory sink, the tool-path resolver config, and the value-injection cache. The cache assertion reuses the counting-attribute harness the FT-1 specs use to make it observable. These specs read and mutate process-wide singletons and xUnit runs test classes in parallel, so they share a collection with the other specs over the same statics — otherwise one class's reset lands inside another's arrange. (cherry picked from commit c8849a5)
(cherry picked from commit b7e772f)
The existing rule was one abstract line and easy to ignore in practice (see PR #528's description). Break it into checkable rules -- one idea per sentence, no idioms, define jargon on first use, gloss cross-references -- and add two anti-pattern examples pulled from a real PR description. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> (cherry picked from commit 56733af)
Terms like shim, sentinel, and canonical type show up often in PRs and issues but are never defined anywhere, making descriptions hard to follow for non-native English readers. Add a short glossary and link to it from issue-and-pr-style.md's non-native-English guidance. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> (cherry picked from commit 4da31f4)
Bumps the github-actions-dependencies group with 2 updates: [actions/upload-artifact](https://github.com/actions/upload-artifact) and [actions/download-artifact](https://github.com/actions/download-artifact). Updates `actions/upload-artifact` from 4 to 7 - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v4...v7) Updates `actions/download-artifact` from 4 to 8 - [Release notes](https://github.com/actions/download-artifact/releases) - [Commits](actions/download-artifact@v4...v8) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions-dependencies - dependency-name: actions/download-artifact dependency-version: '8' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions-dependencies ... Signed-off-by: dependabot[bot] <support@github.com> (cherry picked from commit 0f5d2f0)
The release pipeline checks out the tag being released, so HEAD is detached and matches none of version.json's publicReleaseRefSpec entries — they are all branch refs, and NB.GV never tests that spec against refs/tags/*. NB.GV therefore treated every tag build as a non-public release and appended the git height to the package version: v10.4.0-rc.3 shipped 22 packages named 10.4.0-rc.3.geabd043cc2 rather than 10.4.0-rc.3. Setting PublicRelease explicitly on the Test + Pack step is the documented override and the only one that works here; adding a refs/tags pattern to publicReleaseRefSpec has no effect. Verified locally: Pack produces 10.4.0-rc.4.g03e52ff395 without it and a clean 10.4.0-rc.4 with it. This matters most at GA — a stable tag would otherwise publish with a prerelease-shaped suffix and sort below the version it claims to be. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
version.json pinned the prerelease to 10.4.0-rc.{height}, which made the rc
number a side effect of how many commits a promotion carried rather than a
statement of release intent. Promoting 19 commits off main took the next rc
from rc.3 to rc.23 — correct ordering, but a meaningless jump.
Pin it literally instead. Every commit on the branch now reports the same
version until someone bumps it in a PR, which is what an rc wants: the number
moves when we decide to cut, not when we merge. The git height still feeds the
fourth assembly-version component, so builds stay distinguishable.
The trade-off is that tagging twice without bumping republishes an existing
version, and `dotnet nuget push --skip-duplicate` swallows that silently — so
the runbook note calls out checking the number before tagging.
main keeps {height}: per-commit previews want a value that always moves on
its own.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>Every job downstream of test-and-pack was unreachable on a workflow_dispatch
run, so the manual path — the documented way to publish to nuget.org, and the
documented way to retry a partial publish — silently published nothing while
reporting success. Two independent causes:
validate-ref is skipped by design on workflow_dispatch (`if: event_name ==
'push'`), and a skipped job propagates through the dependency graph.
test-and-pack survives that with `always()`, but that rescues only itself: its
own dependents still saw a skipped ancestor and were skipped too. This hit all
three publish jobs, including the two that carry no condition of their own.
Separately, the nuget.org opt-in compared `inputs.publish-to-nugetorg == true`.
A `type: boolean` input is only a real boolean when the run starts from the
Actions UI; the REST API can only send strings, and `gh workflow run` rejects a
JSON boolean outright. Comparing a string to a boolean casts both to numbers
('true' → NaN, true → 1), so the opt-in never matched from the CLI — including
the exact invocation in docs/branching-and-release.md.
Both fixed: the publish jobs gate on `always() && needs.test-and-pack.result ==
'success'`, and the opt-in accepts the string as well as the boolean. Tag-push
behaviour is unchanged — validate-ref still gates it, and nuget.org still needs
both the flag and the environment approval.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>The environment URL read https://www.nuget.org/profiles/Fallout, which is not the publishing account — the packages live under the Fallout.build profile. It is the link a maintainer clicks from the deployment entry after approving a nuget.org push, so it sent them somewhere unrelated. Confirmed on the v10.4.0-rc.4 publish, which logged "Evaluated environment url: https://www.nuget.org/profiles/Fallout". Display-only: the URL never affected which packages were pushed or where. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The fallout-migrate CLI rewriter only swapped the `Nuke.` prefix, so a NUKE-era `using Nuke.Common.ProjectModel;` landed on the now-dead `Fallout.Common.ProjectModel` namespace — the solution types moved to `Fallout.Solutions` in #257. Add a rule mapping both the Nuke and interim Fallout `Common.ProjectModel` namespaces to `Fallout.Solutions`, run before the generic prefix swap so each reference migrates in a single edit. Mirrors the analyzer codefix from #253, which never reached the CLI tool. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit 8da363e)
The solution types shipped under `Fallout.Common.ProjectModel` in Fallout 11.0.1–11.0.12 and moved to `Fallout.Solutions` in 11.0.13 (#257), breaking that upgrade with no shim. Restore the common entry-point pattern (`[Solution] readonly Solution Solution;`) by mirroring `Solution` + `SolutionAttribute` back into the old namespace inside Fallout.Common. Shallow by design — deep graph navigation, GenerateProjects source-gen, and binary compat still require `fallout-migrate` — matching the ceiling of the generated `Nuke.Common.ProjectModel` shim. A new compile-time consumer sentinel (Fallout.Consumer.ProjectModelShim, in fallout.slnx) fails CI if the shim regresses. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit 63ac171)
… shim generator The new Fallout.Common.ProjectModel.Solution/SolutionAttribute entry-point shims are public types under Fallout.Common, so the Nuke.Common shim's 'Fallout.Common -> Nuke.Common' generator rule swept them up and emitted Nuke.Common.ProjectModel.Solution — which the 'Fallout.Solutions -> Nuke.Common.ProjectModel' rule also emits from the canonical type. Two partial declarations with different base classes → CS0263/CS0111, failing Compile. Give ShimAllPublicTypesUnder an ExceptNamespacePrefixes option and exclude Fallout.Common.ProjectModel from the broad Fallout.Common rule. Those types relocated to Fallout.Solutions in v11 and are shimmed by the dedicated rule; the Fallout.Common.ProjectModel re-exports are a Fallout-side grace shim that must not be re-shimmed into Nuke. Regenerated the affected Verify snapshots (attribute surface + the solution generator picking up the new sentinel consumer project #528 adds). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit 26280ad)
CodeRewriter.Rewrite had a single caller (RewriteCsFilesStep). Move its regex fields and Rewrite method directly into the step and delete the now-empty class. Rename the spec file/class to match. Mirrors the CsprojRewriter fold, so a migration step owns the rewrite rules for its artifact type instead of delegating them to a free-floating static class in Steps/. Raised in review on #528. No behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 9fb8800)
The dotnet-tool package id had been changed to Fallout.GlobalTools (plural)
ahead of first release. Revert it: Fallout.GlobalTool is the id the entire
10.2.x/10.3.x install base already has pinned (52 published versions, latest
10.3.49), so continuing to publish under it means nobody migrates and no id
has to be unlisted. Assembly/namespace stay Fallout.Cli; command stays
`fallout`.
- Fallout.Cli.csproj: <PackageId>Fallout.GlobalTool</PackageId>, with a comment
recording why it deliberately doesn't match the assembly name.
- templates/dotnet-tools.json + BuildScaffolder comments: `fallout :setup`
writes a `fallout.globaltool` pin into consumer repos again.
- UpdateNotificationAttribute: in-tool prompt says `dotnet tool update
Fallout.GlobalTool -g`.
- build/Build.cs: the Install target installed `Solution.Fallout_Cli.Name`
("Fallout.Cli"), which never matched the packed nupkg id. Point it at a new
GlobalToolPackageId constant instead.
Docs swept repo-wide for the plural id: README install + note, CONTRIBUTING,
introduction, 01-installation, 02-setup, 03-execution, github-actions,
rebrand-plan. docs/migration/from-globaltool-to-cli.md deleted — it documented
a GlobalTool -> Cli rename that is now explicitly never happening, and was
already draft:true with no inbound links.
Left alone: .config/dotnet-tools.json still pins fallout.cli 10.3.45. That is
the repo's own dogfood pin and flipping it needs a published Fallout.GlobalTool
build newer than 10.3.49; doing it here would regress `dotnet tool restore`.
Verified: pack produces Fallout.GlobalTool.*.nupkg; Fallout.Cli.Specs 47/47.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit e6e787c)Review feedback on #581: the Install target shouldn't carry yet another hardcoded copy of the package id. Fallout.ProjectModel already exposes MSBuild property access on the solution model, so walk the object path instead: Solution.Fallout_Cli.GetProperty("PackageId") // -> Fallout.GlobalTool Drops the GlobalToolPackageId constant added in the previous commit. The csproj is now the single source of truth for the id, so changing it later touches one file. No new API was needed — ProjectExtensions.GetProperty (src/Fallout.ProjectModel) has covered this since the NUKE days, and the same MSBuild-evaluation path is already exercised by this build at Build.cs:98 via GetTargetFrameworks(). Verified end-to-end against fallout.slnx: GetProperty("PackageId") on the Fallout.Cli project returns "Fallout.GlobalTool". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit cef0b37)
The "UPDATE RECOMMENDED FROM 5.1.0" header was hardcoded in NUKE 9885956 (March 2021) and never updated since, so it named a version no Fallout consumer has ever run. The header still earns its place — it gives the numbered steps context in a server-build warning — so only the version reference goes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit e735790)
docs/rebrand-plan.md is being removed — it describes a rename that has already landed and reads to AI tools as a live plan needing maintenance. The reason this PackageId deliberately diverges from the assembly name belongs with the package-id-as-consumer-contract discussion in #582. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 9abde1d)
(cherry picked from commit c832ec3)
Backport of the same fix on main. The manifest pinned fallout.cli 10.3.45 — an unlisted version of a retired package id — on the branch that is about to cut 10.4.0 GA. Fallout.GlobalTool is the id the CLI ships under, and 10.4.0-rc.5 is what this branch currently builds. Bump the pin to 10.4.0 after the GA tag; a manifest cannot float from a prerelease to a stable version on its own. Verified with `dotnet tool restore`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drops the -rc.5 prerelease tag so the branch stamps a GA core. The prerelease number on a release branch is a manual counter, so this is the bump that turns the next v10.4.0 tag into the GA release rather than another release candidate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The parameter description and its doc comment still named NUKE after the rebrand, so --help and the generated .fallout/build.schema.json told consumers the flag hides the NUKE logo. Regenerate the checked-in schema and update the four SchemaUtilitySpecs snapshots plus the inline expectation in CompletionUtilitySpecs, all of which embed the description. Closes#553 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit c14512d)
Both docs/adr/0010-no-telemetry-collection.md and the from-nuke.md migration guide had diverged only cosmetically from develop (path casing, and a couple of table rows already present on develop). Adopts develop's version verbatim so these two files no longer conflict in the upmerge PR.
Where main and develop diverged on the same lines, keep develop's version: the branching/versioning-model docs and version.json reflect develop's GitFlow reversion (#653), and the migration-engine files (ScriptRewriter folded away, RewriteCsFilesStep/RewriteCsprojsStep, their specs) keep develop's refactor. docs/rebrand-plan.md stays deleted, matching develop. Non-conflicting changes from main (workflow tweaks, generated tool wrappers, AbsolutePath fix, etc.) are carried through as-is.
Uh oh!
There was an error while loading. Please reload this page.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
Upmerge
mainintodevelop.All conflicts resolved in favor of
develop, per instruction:version.json,docs/branching-and-release.md,docs/adr/README.md,.github/workflows/publish-packages-release.yml— kept develop's GitFlow-reversion (Revert to classic GitFlow; stay on semver 10.x until a breaking change is needed #653) content.docs/rebrand-plan.md— stays deleted, matching develop.src/Fallout.Migrate/Steps/ScriptRewriter.cs+ its specs — stays deleted; develop's fold intoRewriteCsFilesStep/RewriteCsprojsStepwins.docs/adr/0010-no-telemetry-collection.md,docs/Migration/from-nuke.md— aligned to develop's path casing/content (separate prep commit).Non-conflicting changes from
main(workflow tweaks, generated tool wrappers,AbsolutePathfix, etc.) are carried through unchanged.gh pr viewreportsmergeable: MERGEABLE— no outstanding conflicts.