release: add OpenVMM prebuilt binaries - #4263
Draft
Ben Hillis (benhillis) wants to merge 2 commits into
Draft
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR generalizes the existing source-only OpenVMM release process into an openvmm-release pipeline that also produces and publishes prebuilt Linux musl binaries, while keeping Windows outputs as unsigned workflow artifacts, and updates the Guide to match.
Changes:
- Rename the Flowey pipeline and GitHub Actions workflow from “source release” to “release”.
- Build x86_64/aarch64 Linux musl
openvmmbinaries and upload them to the draft GitHub release alongside the vendor archive. - Produce unsigned Windows x86_64/aarch64
openvmm.exe(+ PDB when present) as architecture-specific workflow artifacts, and update release/packaging docs accordingly.
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| Guide/src/SUMMARY.md | Updates the Guide TOC to reference the renamed release page. |
| Guide/src/dev_guide/contrib/security_releases.md | Updates security release wording to align with the generalized release process. |
| Guide/src/dev_guide/contrib/openvmm_release.md | Expands release documentation to include Linux binaries and Windows artifact behavior. |
| Guide/src/dev_guide/contrib/openvmm_packaging.md | Clarifies which release assets are relevant for downstream source packaging vs prebuilt binaries. |
| flowey/flowey_lib_hvlite/src/_jobs/publish_openvmm_gh_release.rs | Extends the GitHub draft-release publisher job to upload Linux binaries in addition to the vendor archive. |
| flowey/flowey_hvlite/src/pipelines/openvmm_source_release.rs | Removes the old source-only pipeline implementation. |
| flowey/flowey_hvlite/src/pipelines/openvmm_release.rs | Adds the new release pipeline that builds Linux musl binaries and Windows unsigned artifacts. |
| flowey/flowey_hvlite/src/pipelines/mod.rs | Wires the new openvmm_release pipeline into the CLI/pipeline registry. |
| .github/workflows/openvmm-source-release.yaml | Removes the old autogenerated workflow for the source-only pipeline. |
| .github/workflows/openvmm-release.yaml | Adds the new autogenerated workflow for the generalized release pipeline. |
| .github/skills/guide-maintenance/SKILL.md | Updates code-to-Guide mapping for the new release pipeline and related jobs. |
| .flowey.toml | Updates Flowey’s workflow generation configuration to emit openvmm-release.yaml and run ci openvmm-release. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Ben Hillis (benhillis)
marked this pull request as ready for review
August 17, 2026 17:28
Ben Hillis (benhillis)
marked this pull request as draft
August 17, 2026 21:19
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 16 out of 16 changed files in this pull request and generated no new comments.
Suppressed comments (1)
flowey/flowey_lib_hvlite/src/_jobs/publish_openvmm_gh_release.rs:252
stage_linux_binaryusesfs_err::hard_linkto stage the Linux binaries. Hard-links can fail when the source artifact directory and the staging directory are on different filesystems (common when$RUNNER_TEMPand$GITHUB_WORKSPACEare mounted differently), which would make the release pipeline fail even though the build succeeded. Using a regular copy here is more robust and still cheap for a single binary per arch.
let staged = stage_dir.join(format!("openvmm-{target}"));
fs_err::hard_link(&bin, &staged)
.with_context(|| format!("failed to stage {} as {}", bin.display(), staged.display()))?;
Ok((staged.absolute()?, None))
Ben Hillis (benhillis)
added a commit
that referenced
this pull request
Aug 18, 2026
`openvmm --version` classifies every build as `release` or `development (not an official release)`. This removes that classification and reports only facts. ## Why The verdict is unverifiable, and wrong at the two edges that matter: - A Git-free tree reports **`release`** — but *any* modified tarball lacks Git metadata and so qualifies. RFC #4150 conceded this: the classification is *"descriptive, not proof that arbitrary Git-free source is official."* - An exact checkout of a published release commit reports **`not an official release`** — even when it produces what was released. The facts next to it (`+g<COMMIT>`, `.dirty`, `commit:`, `target:`) are true and can't be forged by rebuilding. Nothing consumed `BuildKind`; it was one line of output. ## Before / after ``` openvmm 0.1.0+g72d7a0fa6 -build: development (not an official release) version: 0.1.0 commit: 72d7a0f target: x86_64-unknown-linux-gnu ``` The version string is unchanged: checkouts still report `<VERSION>+g<COMMIT>`, dirty trees still append `.dirty`, Git-free trees still report the plain version, and tags remain publication markers rather than build-identity inputs. ## RFC #4150 A deliberate, narrow revision to shipped behavior. Decisions 1, 2, 5, 6 are untouched; the version-*string* semantics of 3 and 4 are preserved and only the printed verdict is removed. Decision 3's goal — *"locally rebuilt checkouts never claim official release identity"* — is served better when no build claims it. Proving a binary's origin is left to the tag, checksums, and provenance, as Decision 4 already assumed. Found while reviewing #4263, which would have shipped prebuilt binaries describing themselves as development builds. Split out so it isn't reviewed underneath release plumbing; #4263 will rebase on this. --------- Co-authored-by: OpenVMM Team <openvmm@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 07b35b40-9b80-40c7-963d-68f0a4190626
Generalize the manually dispatched release pipeline and add Linux musl release assets plus unsigned Windows workflow artifacts. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 07b35b40-9b80-40c7-963d-68f0a4190626
Denying warnings rewrites the tracked `.cargo/config.toml` in the checkout, which leaves the working tree dirty. `openvmm_build_info` then stamps every binary built afterwards `.dirty`, so the published release binaries would have advertised local modifications that do not exist. Add a `DenyWarnings` parameter to the shared cloud config so pipelines that hand artifacts to end users can opt out. The checkin gates already enforce warnings on every commit that can reach a release, so nothing is lost by disabling it here. Also note in the Guide that the published binaries report `<VERSION>+g<COMMIT>`, since they are built from a checkout. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 07b35b40-9b80-40c7-963d-68f0a4190626
Ben Hillis (benhillis)
force-pushed
the
copilot/openvmm-prebuilt-releases
branch
from
August 19, 2026 17:04
b2a8bf9 to
b98eab9
Compare
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.
Summary
openvmm-releasepipelineValidation
cargo check -p flowey_hvlite -p flowey_lib_hvlitecargo clippy --all-targets -p flowey_hvlite -p flowey_lib_hvlitecargo doc --no-deps -p flowey_hvlite -p flowey_lib_hvlitecargo nextest run --profile agent -p flowey_hvlite -p flowey_lib_hvlitecargo xflowey regencargo xtask fmt --fix