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 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 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