fix: mxcli new warns instead of failing when the devcontainer binary can't be fetched (closes #1365)

[stagknee]

Closes #1365.

What it does

• The Windows/macOS part of step 7 (downloading the Linux mxcli for the devcontainer) moves into fetchDevcontainerMxcli(path, out, errOut).
  • A download failure is now a Warning: on stderr with the existing mxcli setup mxcli --output ./mxcli hint, like step 6's first-build warning, and new carries on to its "Project created / Next steps" output and exits 0.
  • The Linux branch (hard link or copy of itself) is unchanged.
• Dev builds skip the download with a note instead of asking for a release that doesn't exist. This is decided by hasPublishedRelease() next to mxcliReleaseTag(). It's false for an unstamped go build (Version == "", which reports 0.1.0 → v0.1.0, the 404 in the issue), and for tags that aren't nightly or vX.Y.Z (make build outside git, untagged checkouts). Stamped releases, nightlies and git describe past a tag download as before. mxcliReleaseTag() itself is unchanged, so setup mxcli behaves as before.
• The downloader is a package var (downloadDevcontainerBinary) so tests can stand in for the network.
• CHANGELOG (Unreleased → Fixed), a finding in findings/cmd-mxcli/, and a stale "must exit 1" comment fixed in cmd_new_test.go.

Evidence

• Test-first (cmd_new_devcontainer_test.go). With the step extracted but the old behaviour kept:

  • the download-error test failed because stderr had no warning;
  • the dev-build subtests (4 version shapes) failed with "dev build must not attempt a download, got 1 call(s)".

  All pass with the fix. A success-path test pins the tag that release, nightly and describe builds request.

• go test ./cmd/mxcli/ on Windows: an identical failure list with and without the change (pre-existing Windows/env failures; Five tests fail on Windows (POSIX file-mode assertions + a path assumption) — never run there until now #897, On Windows, go test ./... writes into the developer's real ~/.mxcli: tests override only HOME, which os.UserHomeDir() ignores there (follow-up to #897) #1256). The focused New|Setup|Mxcli|Devcontainer run passes. go vet is clean for windows, linux and darwin.

• Linux (golang:1.26.6-bookworm, ANTLR 4.13.2, the same as CI): make grammar build test check-mdl check-findings check-conformance check-migration-reference lint-go all pass.

• Not run: a real mxcli new end to end (it needs a Mendix download). Step 7 is covered by the unit tests on the extracted function.

🤖 Generated with Claude Code

[github-actions]

AI Code Review

What Looks Good

• The PR successfully addresses issue mxcli new exits 1 at step 7 when the Linux devcontainer binary can't be downloaded, although the project is complete (always fails with a dev build) #1365 by making mxcli new resilient to devcontainer binary download failures
• Test-first approach is properly implemented: new tests fail before the fix and pass after
• Comprehensive test coverage for the new behavior including error cases, dev builds, and success paths
• Clear separation of concerns: extracted download logic into a reusable function with proper error handling
• Appropriate use of stdout/stderr (normal messages to stdout, warnings to stderr)
• Good testability through dependency injection (package var for downloader)
• CHANGELOG entry accurately describes the fix
• Stale comment in test file properly updated
• All existing tests continue to pass (with noted pre-existing failures unrelated to this change)
• Linux build and test suite passes completely
• Finding properly recorded in the correct location per project conventions

Recommendation

Approve. The PR is well-implemented, thoroughly tested, and follows all project conventions. The minor warning message formatting issue is trivial and doesn't affect functionality. The fix correctly resolves the reported issue where mxcli new would fail with exit code 1 when the devcontainer binary couldn't be downloaded, despite steps 1-6 having already created a complete project. Now it shows a warning and continues to completion, matching the behavior of other non-fatal warnings in the command.

---

Automated review via OpenRouter (Nemotron Super 120B) — workflow source