openvmm: report a version

[bitranox]

openvmm --version did not exist, so a deployed binary could not identify itself. Today the only way to tell which revision a binary came from is to hash it and look that hash up in a record kept somewhere else, which answers "is this the same binary as before" but never "which revision is this one".

This wires up clap's version flag and builds the string from the crate version plus the git revision:

$ openvmm --version
openvmm 0.0.0 (3148a7cc9ea8eaa7b7c61cb59d26880f809fe5a6)

The revision comes from the existing build_rs_git_info helper, already used by build_info, burette and underhill_init. Unlike those, the error is ignored here rather than unwrapped: they are always built inside a checkout, while openvmm is also built from release tarballs and vendored sources, where a missing repository should degrade the version string rather than fail the build.

The command name is set explicitly. clap otherwise takes it from the crate and reports openvmm_entry, which is neither the binary name nor what the usage line already prints.

Every crate in the workspace is at 0.0.0, so the revision currently carries all of the information. The flag gets more useful for free if a real version is ever set.

[Copilot]

Pull request overview

Adds support for openvmm --version in openvmm_entry, formatting the reported version as the crate version plus (when available) the git revision captured at build time, while allowing builds from tarballs/vendored sources to succeed without a git repository.

Changes:

• Wire up clap’s --version output to use CARGO_PKG_VERSION plus optional BUILD_GIT_SHA.
• Ensure the clap-reported command name is openvmm (instead of the crate name).
• Add unit tests for the version string formatting logic and emit git info from the build script (non-fatal on failure).

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
openvmm/openvmm_entry/src/cli_args.rs	Adds version string formatting, a lazily-initialized version string, sets clap command name/version, and adds unit tests.
openvmm/openvmm_entry/Cargo.toml	Adds build_rs_git_info as a build dependency.
openvmm/openvmm_entry/build.rs	Emits git metadata in the build script but tolerates missing git/repo.
Cargo.lock	Records the new build dependency in the lockfile.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated no new comments.

[jstarks]

@benhillis has been working on some version changes as well.

[benhillis]

@bitranox

Thanks for doing this. The name = "openvmm" part is a legit bug.

We are actually in the process of formalizing our version and release process (see draft PR #3989), and we're planning on doing tag-based versioning versus using the crate version. If you're open to dropping the other versioning changes I'd be happy to take the clap fix.

[benhillis]

See above comment.

[bitranox]

Whatever you want to cherry-pick works for me, so take the clap fix in whatever shape suits #3989.

One request for the version work itself, from the development side: could the build carry the git revision somewhere? Tag-based versioning identifies releases well, but during development most builds sit between tags, and several builds share the same nearest tag, so a tag alone cannot tell them apart.

Either shape would do the job:

• fold it into --version via something like git describe --tags --always --dirty, which gives v1.2.3-14-gabc1234: still meaningful for a release build, and it identifies an untagged one. With no tags in the repo yet it degrades to a bare sha, which is the situation today.
• or keep --version purely tag-based and add a separate flag, --version-git or similar, so the release string stays exactly what your process defines and the revision lives beside it.

The second may suit you better if you want --version to mean the released version and nothing else.

The practical reason this PR read the revision at build time: we run openvmm builds on test hosts and need to know which binary is actually deployed, and --version is the only thing that answers that without keeping a table of hashes on the side. The build script can shell out to git and ignore a failure, so a tarball or vendored build still compiles and just reports the version alone.

I have the PR reduced to only the clap fix locally and can push that whenever you like, or leave it as it stands if you would rather cherry-pick from it.