The tap job matched the literal v0.1.0 url line, so bumping the pin
broke the release render. The pin is now matched generically and
marked in-source as a placeholder the workflow rewrites; the tap
always ships the release tarball with its real sha256.
All consumers live in packaging already: the formula codesigns at
install, and the CI and release workflows codesign the built binary.
The macOS dir held nothing else.
The tap repo is a publish target like the snap store: the release
workflow rewrites the in-repo formula's url/sha256 for the release
tarball and pushes it to homebrew-ecrou. No token, no update — tags
still release.
CI runs fmt/clippy/test plus a real alpine boot on a macos-26 runner
with libkrun from the krun tap; the release workflow ships a signed
darwin-arm64 tarball beside the snaps. The formula installs from the
tap, carries the runtime kegs (libkrun, e2fsprogs, libarchive), and
codesigns the binary with the hypervisor entitlement — Hypervisor
.framework grants VM creation only to entitled binaries on current
macOS, the same requirement krunkit's formula signs for.
The payload's stdout is a serial console, so fastfetch reads a tty
and decorates its output with cursor escapes; the ^OS: anchor
matched nothing and would have failed a green run. --pipe --logo
none prints a plain key-value list, and a sed strips anything left
before the grep. SPEC records the first measured apt wall time: 24 s
cache-warm, boot included.
The snap only got built at tag time, so the pack rotted between
releases; ci now packs it on every change, the same action the
release workflow uses, and boots it twice: an alpine uname check
that proves the machine virtualized under strict confinement, and
apt update + install fastfetch on ubuntu, which is T8 — a real
package install through the TSI proxy, the staged e2fsprogs, and
the exit-code path, with the wall time as the standing
re-measurement of the ln driver's throughput.
Same dlopen as the snap stages for: the runner has e2fsprogs but not
the lib, and the first cold pull would fail. The t64 name with a
fallback keeps it honest if the runner image changes base.
The T6 run boots from a block device now; an engine without the blk
feature fails the lookup for krun_add_disk and the audit never sees a
machine. Same feature set as the snap ships.
The version: key in snapcraft.yaml was a second number to bump by
hand, and between releases it read whatever it was left at. The ecrou
part now sets its version from [workspace.package] at pull time —
the same value clap reports with --version — so Cargo.toml is the
only place a version lives, and the release workflow stamps only
that. A missed match fails the pack loudly.
The test has been declared as CI-only since it landed and never ran
anywhere. The job builds the engine from the tag the snap bundles,
takes libkrunfw from the pool, opens /dev/kvm, and runs the ignored
test with ECROU_BIN and LD_LIBRARY_PATH pointed at them.
The arm64 runner leg builds that platform natively, where libkrun
compiles and the libkrunfw part picks the arm64 pool .deb on its own.
Both snaps upload as artifacts and publish to stable from one job.
Testing runs the pre-commit trio on pushes to main and PRs.
Releasing builds the snap on plain vX tags and publishes it to the
stable store channel; rc tags fail the version gate and leave the
publish job skipped.
vhaudiquet