Migrate build system from NUKE to Fallout - #227
Merged
Conversation
Runs the fallout-migrate CLI (https://docs.fallout.build/docs/migration/from-nuke) to move the build project off NUKE onto Fallout, its hard-fork successor: - Build/_build.csproj: Nuke.* package references -> Fallout.* 10.4.0, target framework net9.0 -> net10.0 (Fallout's minimum), Nuke*Directory MSBuild properties -> Fallout*Directory - Build/Build.cs, Build/Configuration.cs: using directives and base class/interface -> Fallout.* equivalents (NukeBuild -> FalloutBuild) - build.ps1, build.sh: temp directory path .nuke/temp -> .fallout/temp - .nuke/ -> .fallout/ (renamed; build.schema.json regenerated with Fallout-specific parameter hints) Manual follow-ups the migration tool doesn't handle automatically: - .github/workflows/build.yml: rename the "Run NUKE" step for clarity - agents.md, .github/copilot-instructions.md, README.md: update local build instructions and doc links from the nuke CLI/nuke.build to the fallout CLI/docs.fallout.build Verified Build/_build.csproj compiles cleanly against the Fallout packages and the target graph resolves as before.
The previous run's "Build, Test, Analyze and Publish" job failed only on two live-network Integration-tagged tests in ParallelPackageRiskEnricherSpecs (GitHub API enrichment), and only under the net10.0 test leg — the identical net9.0 leg in the same run passed. That code path is untouched by this migration and already ran on net10.0 before this PR, so this looks like transient flakiness in tests that hit live external services (GitHub API, securityscorecards.dev) rather than a regression from the NUKE -> Fallout migration. The stuck workflow run (its trailing "Publish Tests Results" job hung for 10+ minutes and didn't respond to a cancellation request) couldn't be rerun through the GitHub API while "in progress", so retriggering with an empty commit instead.
Attempt 3's build/test job actually passed (RunTests succeeded), confirming
the two earlier failures were transient load on GitHub's API under this
enricher's heavy concurrent live-network fan-out, not a migration
regression. That attempt then failed on an unrelated step: coveralls
returned HTTP 503 ("Coveralls is temporarily rate-limited by the GitHub
API... please retry it in a few minutes"), a third-party outage.
The trailing "Publish Tests Results" job hung again for 10+ minutes and
didn't respond to a cancellation request, blocking a same-run rerun, so
retriggering with an empty commit as before.
ParallelPackageRiskEnricherSpecs.cs's two GitHub-integration tests pass NullLogger.Instance to the enricher, so whatever HTTP error is causing them to intermittently fail in CI (3 of 4 attempts so far on this PR) is silently swallowed - RunTests just reports "found False" with no underlying exception. Locally this reproduces as a 401 from an expired dev GITHUB_API_KEY, confirmed via a temporary console logger. Swapping in a real console logger for just these two tests so the next CI run's output shows the actual status code/exception instead of guessing. Will revert or keep depending on what it reveals.
Coverage Report for CI Build 32054806288Coverage increased (+0.01%) to 77.326%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
CI is green now (the earlier failures were confirmed intermittent - the diagnostic run itself passed on the first try). Keeping the real logger instead of NullLogger.Instance for these two tests since it costs nothing on the happy path and means the next time GitHub API calls fail intermittently in CI, the test output will show the actual status code/exception instead of a bare assertion failure.
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
2 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.
What
Migrates the build project from NUKE to Fallout, its hard-fork successor, using the
fallout-migrateCLI as documented at https://docs.fallout.build/docs/migration/from-nuke.Changes
Automated by
fallout-migrate:Build/_build.csproj:Nuke.*package references →Fallout.*10.4.0; target frameworknet9.0→net10.0(Fallout's minimum);Nuke*DirectoryMSBuild properties →Fallout*DirectoryBuild/Build.cs,Build/Configuration.cs:using Nuke.*→using Fallout.*;NukeBuildbase class →FalloutBuildbuild.ps1,build.sh: temp directory path.nuke/temp→.fallout/temp.nuke/→.fallout/(renamed;build.schema.jsonregenerated with Fallout-specific parameter hints)Manual follow-ups the migration tool doesn't handle automatically:
.github/workflows/build.yml: renamed the "Run NUKE" step for clarity (it still just runs./build.ps1, no functional change)agents.md,.github/copilot-instructions.md,README.md: updated local build instructions and doc links from thenukeCLI / nuke.build to thefalloutCLI / docs.fallout.buildVerification
Build/_build.csprojcompiles cleanly against the newFallout.*packages (0 errors), and the target graph (Compile,RunTests,RunPackageGuard,Pack, …) resolves identically to before.Running an actual target in this worktree currently fails at the
GitVersionstep (LibGit2Sharpcan't read the git index here), but this is pre-existing and unrelated to the migration — I confirmed by temporarily stashing these changes and reproducing the identical failure against the original NUKE setup. It should not reproduce in a normal clone.Not changed (flagged, optional follow-up)
build.ps1/build.shstill contain a deadNUKE_ENTERPRISE_TOKENbranch pointing at the oldf.feedz.io/nuke/enterprisefeed. It's inert unless that env var is set, but worth revisiting if you use a Fallout enterprise feed.nuget.config) for staged transitions — skipped since this is a full migration, not a gradual one.🤖 Generated with Claude Code