Repository navigation
feat(version): stamp the git build id into fbuild and fbuild-daemon (#1742 follow-up 1) - #1769
Merged
Merged
Conversation
Two builds of the same workspace version were indistinguishable (#1742): an editable install that kept yesterday's binaries printed the same version as a fresh one, and a daemon left running from an older checkout looked current. Implement follow-up 1 of #1742. fbuild-core gains a build script that stamps FBUILD_BUILD_COMMIT (git rev-parse --short=12 HEAD) and FBUILD_BUILD_DIRTY (tracked-file status), plus a build_id module that reads them. Because every version-reporting crate depends on fbuild-core, one probe keeps the CLI and the daemon agreeing instead of duplicating git logic per binary. The probe is best-effort: no git or no .git degrades the stamp to "unknown" and never fails a build. Surfaced as: - fbuild --version: 2.5.47+git.5fca4d49135b[-dirty] (clap long_version; -V still prints the bare version, and the id is semver build metadata) - fbuild daemon status / daemon list: a Build: line, from the new build_id field on /health and /api/daemon/info. A differing daemon names both builds; a pre-#1742 daemon says so instead of printing blank. No fingerprint, cache key or endpoint derivation changed; this is diagnostic surface only.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the
 |
The nested HealthResponse/DaemonInfoResponse literals grew by one line in handlers/health.rs, and the inventory records line numbers.
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
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.
Why
Two builds of the same workspace version were indistinguishable (#1742). An
editable install that kept yesterday's
fbuild/fbuild-daemonprinted the same2.5.46as a fresh one, so a feature that had already landed looked missing andthe blame landed on fbuild instead of on the stale binary. The same ambiguity
made
fbuild daemon statususeless for "is this daemon from my checkout?"(#1739).
This implements follow-up 1 from #1742: embed a build id (git HEAD + dirty flag)
in the CLI and the daemon, and show it in
fbuild --versionandfbuild daemon status.What
crates/fbuild-core/build.rs(new) stampsFBUILD_BUILD_COMMIT(
git rev-parse --short=12 HEAD) andFBUILD_BUILD_DIRTY(
git status --porcelain --untracked-files=no). The probe is best-effort: nogit, no
.git, or a non-repository source tree degrades the stamp tounknownand never fails a build.cargo:rerun-if-changedon.git/HEAD/.git/indexis what makes the stamp follow the checkout; a changedrustc-envvalue recompilesfbuild-coreand relinks its dependents.fbuild-core::build_idis the single reader:COMMIT,dirty(),build_id()(5fca4d49c9ab,5fca4d49c9ab-dirty, orunknown),long_version()(2.5.47+git.5fca4d49c9ab-dirty).fbuild-corecarries thestamp for the whole workspace, so the CLI and the daemon agree without a
second git probe per binary.
fbuild --versionnow prints the long form via claplong_version;fbuild -Vstill prints the bare workspace version, so scripts that parse itare unaffected. The build id is valid semver build metadata.
fbuild daemon status/fbuild daemon listgained aBuild:line fromthe new
build_idfield on/healthand/api/daemon/info. When the daemon'sbuild differs from the CLI's, both are named; a daemon that predates this
change says so instead of printing a blank.
diagnostic surface.
Tests
build_id.rs(6) andcli::daemon_cmd::build_id_tests(3) are unit-tested pureformatters: clean vs dirty id, unstamped builds reporting
unknowneven whendirty, the long version staying version-parseable, and the three
Build:labelcases (match / differ / pre-#1742 daemon). RED-first: with the dirty suffix
disabled,
dirty_build_id_says_sofails withleft: "5fca4d49c9ab"vsright: "5fca4d49c9ab-dirty".Closes follow-up 1 of #1742 (the uv cache-key mitigation already landed in #1741).