Repository navigation
cmux-tui: a new build stamp no longer recompiles cmux-tui-core - #21980
Conversation
…amp does not recompile it cmd_server.rs read CMUX_TUI_BUILD_COMMIT, CMUX_MUX_BUILD_COMMIT and CMUX_TUI_GHOSTTY_COMMIT with option_env!. rustc tracks them in dep-info, so every new stamp recompiled cmux-tui-core (18-21 s per stamp in the Linux build pool). The binary now reads them (as version_string did) and installs a BuildStamp in core at the top of main; identify and ping read it. A mux without it (tests, embedders) reports null, as an unstamped build does. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Receipt for
|
|
Bead |
Correctness review (subagent)Head reviewed: Result: no blocker. Merge is safe after you decide on the should-fix item.1. Readers of the stamp
2. Paths that now report
|
|
Found 3 test failures on Blacksmith runners: Failures
|
…e install rule Review of the build-stamp move: identify_and_ping_return_build_metadata compared null with null; it now installs a known stamp and checks the literal values in identify and ping. install_build_stamp says every entry point that serves identify or ping must call it. build_stamp() says why the filter runs after the TUI-then-MUX fallback. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Bugbot needs on-demand usage enabledBugbot uses usage-based billing for this team and requires on-demand usage to be enabled. A team admin can enable on-demand usage in the Cursor dashboard. |
Resolution of the review findings
f41a71f is a rustfmt order fix only ( Testbox at dc61324: |
|
Shipped in:
|
…#28787) release::DISTRIBUTION_VERSION read CMUX_TUI_DISTRIBUTION_VERSION with option_env!, and the Linux pool stamps it per build (0.0.0-r2.sha-<stamp>, macos-cross.sh, cmux-tui-build-package.yml), so every stamp recompiled cmux-tui-core and everything above it. #21980 moved core's other stamps to the binary (install_build_stamp); release.rs came a day later with its own. Core now reads release::distribution_version(): the value the binary installs at start (install_distribution_version, next to install_build_stamp), the same filter (a placeholder stamp is not a release), and the workspace crate version until then (core's tests, which saw the same value before). The binary keeps its own DISTRIBUTION_VERSION constant and DISTRIBUTION_STAMP, the one option_env! read. Test: cargo test -p cmux-tui-core --lib only_a_release_stamp_is_reported_as_the_release Agent-Session: https://cmux.com/deeplink/agent?id=aid-2f016c499153c1bead46 Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: cmux-bot[bot] <348531757+cmux-bot[bot]@users.noreply.github.com>
Summary
cmd_server.rsin cmux-tui-core readCMUX_TUI_BUILD_COMMIT,CMUX_MUX_BUILD_COMMITandCMUX_TUI_GHOSTTY_COMMITwithoption_env!. rustc records these in dep-info, so every new build stamp recompiled cmux-tui-core and, through it, cmux-remote.Now only the binary crate reads the stamp at compile time:
cmux-tui-core/src/server/daemon_build.rs: a newBuildStampin aOnceLock, set byinstall_build_stamp(first call wins). Thestamped_build_commit()andstamped_ghostty_commit()functions read it.cmux-tui/src/main.rs:build_stamp()reads the env values in the same order as before (TUI, then MUX; an empty value counts as no stamp).main()installs it as its first step after the link-token take, before any mode can serveidentifyorping.version_string()reads the samebuild_stamp().null, which is what an unstamped build reported before.cmux-relay has the same pattern, but it is not in the cmux-tui bin graph (it is only a dev-dependency of cmux-remote), so this PR does not change it.
Proof (Blacksmith Testbox, 32 vCPU,
cargo build -v -p cmux-tui --bin cmux-tui --locked)Stamps A=
aaaa…and B=bbbb…(40 hex), ghosttycccc…. The same tree for each pair.Pool Linux twin settings (
CARGO_INCREMENTAL=0 CARGO_PROFILE_DEV_DEBUG=0,CMUX_TUI_DISTRIBUTION_VERSIONandCMUX_GIT_SHORT_SHAfollow the stamp),--timings:After the change these units still rebuild for each new stamp: cmux-tui (18.4 s), acpmux (16.7 s, from
CMUX_GIT_SHORT_SHA/SOURCE_DATE_EPOCH), cmux-remote (9.6 s, fromCMUX_TUI_DISTRIBUTION_VERSIONinssh_bootstrap.rs), and the cmux-build-identity build script. Those are not in this PR.Incremental dev profile, only the commit and ghostty stamps changed: before, the build compiled cmux-build-identity, cmux-remote, cmux-tui-core and cmux-tui. After, it compiled only cmux-build-identity and cmux-tui, and every library was Fresh.
Readers, after the change, through a real headless daemon socket (
identifyandping) and--version. The values are identical to the before-change binary with the same stamp:The A and B binaries (after the change) have the same size (1183893440 bytes). Of the 380 differing bytes, 360 are in the 9 stamp strings. The other 20 are the ELF
.note.gnu.build-idhash (offset 812-831; section at 0x31c).Tests
cargo fmt --check -p cmux-tui-core -p cmux-tui: okcargo test -p cmux-tui-core --lib identify_and_ping_return_build_metadata: okcargo test -p cmux-tui --test resource_cli_v2 --test cli -- startup_help_and_version_use_the_public_command_name machine_agent: 3 okcargo clippy --locked -p cmux-tui-core -p cmux-tui --all-targets -- -D warnings: okNo new tests.
🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need.Summary by cubic
Moves build stamp reading out of
cmux-tui-coreso a new stamp no longer recompiles it.cmd_server.rspreviously readCMUX_TUI_BUILD_COMMIT,CMUX_MUX_BUILD_COMMIT, andCMUX_TUI_GHOSTTY_COMMITwithoption_env!, which rustc tracked in dep-info and forcedcmux-tui-core(andcmux-remotethrough it) to rebuild on every stamp change. Now only thecmux-tuibinary reads the environment at compile time and installs aBuildStampin core at startup.main()installs the stamp as its first step, before any mode can serveidentifyorping; reading order is unchanged, and an empty value still counts as no stamp.null, same as an unstamped build.identify_and_ping_return_build_metadatanow installs a known stamp and asserts its literal values inidentifyandping.cmux-tui-corestaying Fresh.cmux-relayhas the same pattern but sits outside the cmux-tui bin graph, so it is unchanged here.Written for commit dc61324. Summary will update on new commits.