openvmm: identify checkout builds by revision - #4135
Closed
Ben Hillis (benhillis) wants to merge 4 commits into
Closed
openvmm: identify checkout builds by revision#4135Ben Hillis (benhillis) wants to merge 4 commits into
Ben Hillis (benhillis) wants to merge 4 commits into
Conversation
added 4 commits
July 31, 2026 11:55
`openvmm --version` did not exist, and there was nothing to report if it had: the workspace set no `version`, so every crate in it was `0.0.0`. OpenVMM ships as a source archive that packagers build themselves, which rules out the usual approach of having CI inject a version at build time -- the packager builds long after our pipeline has exited, from a tree with no git history to recover a version from. The version therefore has to be committed to the tree. QEMU, systemd, the kernel, cloud-hypervisor and rustc all do this, and each falls back gracefully when `.git` is absent rather than deriving the release version from a tag. So: set `version` in `[workspace.package]`, inherit it in `openvmm` and `openvmm_entry`, and wire up clap's `version`. `OPENVMM_PKGVERSION` lets a packager append their own build identity, as QEMU's `-Dpkgversion` and cloud-hypervisor's `CH_EXTRA_VERSION` do; an empty value is ignored, since build systems routinely pass an undefined variable through as "". Two things fall out of that: - The Windows VERSIONINFO resource is a second version surface, stamped from `OPENVMM_MAJOR`/`MINOR`/`PATCH`/`REVISION` and defaulting to `0.0.0.0`. No in-repo caller sets those, so leaving it alone would have left one binary reporting `0.1.0-dev` from `--version` and `0.0.0.0` from its file properties. It now defaults to the crate version, with the env vars still overriding per-component so a pipeline can stamp a build number in. - `cargo xtask fmt` deliberately strips `version` from `[package]`, partly because doing so also makes a crate unpublishable. The three crates on its exception list now set `publish = false` explicitly, restoring the property the lint was relying on. Verified by building `openvmm` from an extracted archive with no `.git` anywhere above it, which is the case that actually matters.
The workspace version advances only in the reviewed pull request that selects the next release. Development-build identity is added separately from the committed product version. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 0ba1c0df-faf0-4a0e-b39d-c3eb0e363fce
Builds on the crate-based version by adding back the part of the tag-derived scheme that is actually worth having: the commit a build came from. `openvmm_build_info` resolves the version at build time. The version itself is still a committed fact inherited from `[workspace.package]`, so it travels inside the source archive and a packager building an extracted tree with no Git history reports the right thing. Git is consulted only to append `+g<revision>` to a build made from a checkout, as semver build metadata so it orders identically to the plain version. `OPENVMM_PKGVERSION` still replaces the lot. Deliberately omitted from the tag-derived design: - No `.openvmm-release.json` and no tag parsing. Nothing has to stamp metadata into the archive, so there is no release step that can silently fail and leave a shipped tarball reporting `0.0.0-dev`, and no tag/manifest agreement to validate in CI. - No dirty flag. Detecting a modified working tree means emitting a `rerun-if-changed` for every tracked file, which stats the entire repository on every build. The revision alone needs two files. The Git lookup rejects a repository that does not start exactly where OpenVMM does. Git searches parent directories, so an archive extracted inside an unrelated checkout would otherwise report that checkout's HEAD, which is the one failure mode here that is silent and wrong rather than merely absent. `product_version` is exposed separately from `version` and is what the snapshot manifest records, since a persisted field wants the upstream version rather than a distribution's build string. Verified from a checkout, from an archive extracted outside any repository, and from one extracted inside an unrelated repository.
Keep enriching ordinary checkouts with +g<sha>, but report the plain product version when HEAD carries openvmm-v<VERSION>. A checkout without tags fails safely toward development identity, while an extracted source archive remains plain because it has no repository. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 0ba1c0df-faf0-4a0e-b39d-c3eb0e363fce
|
This PR modifies files containing For more on why we check whole files, instead of just diffs, check out the Rustonomicon |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR introduces a unified “build identity” for OpenVMM by adding a dedicated openvmm_build_info crate that carries the canonical workspace version and optionally enriches it with Git revision data (without allowing Git data to “claim” release status). It then wires that resolved version into user-visible openvmm --version output and into persisted snapshot metadata.
Changes:
- Add
openvmm_build_infocrate with a build script that derivesOPENVMM_VERSION,OPENVMM_PRODUCT_VERSION, andOPENVMM_REVISION, using Git only when it’s safe to do so. - Define the canonical product version in
[workspace.package]and propagate it toopenvmm(and the new crate), ensuring Windows VERSIONINFO and CLI output remain consistent. - Update
openvmm_entryto report the resolved build identity for--versionand to persist the product version in snapshot manifests.
Reviewed changes
Copilot reviewed 11 out of 12 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| xtask/src/tasks/fmt/lints/package_info.rs | Expands version-allowed package exceptions and documents why those crates can carry versions. |
| vm/vmgs/vmgstool/Cargo.toml | Adds publish = false now that the crate carries an explicit version. |
| openvmm/openvmm/Cargo.toml | Inherits workspace version and marks crate non-publishable. |
| openvmm/openvmm/build.rs | Defaults Windows version resource components from the crate version when not overridden by OPENVMM_*. |
| openvmm/openvmm_entry/src/vm_controller.rs | Persists product_version (not distro/custom build strings) into snapshot manifests. |
| openvmm/openvmm_entry/src/cli_args.rs | Forces CLI name/version to reflect the OpenVMM product + resolved build identity; adds a regression test for --version. |
| openvmm/openvmm_entry/Cargo.toml | Adds dependency on openvmm_build_info. |
| openvmm/openvmm_build_info/src/lib.rs | Adds runtime accessor + embedded metadata section for build identity. |
| openvmm/openvmm_build_info/Cargo.toml | Defines new crate inheriting workspace version and disables publishing. |
| openvmm/openvmm_build_info/build.rs | Implements Git-aware (but safe) version enrichment and sets compile-time env vars for the crate. |
| Cargo.toml | Adds [workspace.package] version and registers openvmm_build_info in workspace dependencies. |
| Cargo.lock | Updates openvmm version and records the new openvmm_build_info package/dependency edge. |
Comment on lines
+146
to
+148
| // `name` is set explicitly because the version and help output otherwise | ||
| // report `CARGO_PKG_NAME`, which is the crate holding this parser | ||
| // (`openvmm_entry`) rather than the binary a user actually invoked. |
Member
Author
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.
Depends on #4132. Once that PR merges, this diff reduces to the Git-backed build identity.
This change adds
openvmm_build_infoand distinguishes source shapes without allowing a build variable to claim release status:<VERSION>+g<SHORT_SHA>;openvmm-v<VERSION>reports the plain version;OPENVMM_PKGVERSIONremains an explicit builder-supplied custom identity;The committed workspace version remains the source of truth. Git enriches it but never determines it.