Release bundles: one job fetches every dependency, every later job and environment runs offline from it issue #87
open andymccall opened this · 0 comments
andymccall
Second of three (after issue #86 environments): build once, deploy the same bytes everywhere. Andy (2026-10-26): "we're doing the same release in both environments, but the source has already been obtained, checked, catalogued and filtered before we reach prod."
One job fetches; every other job is offline. A bundle job is the only one with egress (network "egress" { allow … }, §4.3.1). It resolves every dependency the release needs into a content-addressed bundle:
vendored crates, npm/pip/Gradle packages, container images, binaries, as the project's own lockfiles name them (cargo vendor, pip download --require-hashes…; the bundle step runs them, it does not guess);
an SBOM of all of it;
the job's provenance (in-toto/SLSA style: which run, which state, which image), signed by the runner and the hub, logged in the transparency log.
A bundle is an artifact kind the hub stores by BLAKE3 like any other, but immutable, retained while any environment's deployment names it, and with its SBOM and provenance shown on the run.
Policy on the way in (the "checked, filtered" part): a repository or organisation may set rules a bundle must pass before any environment accepts it: licences allowed, known-vulnerable versions refused (against an advisory database the hub keeps a copy of), hosts the bundle job may reach. A refusal names the package and the rule.
Notes: the egress proxy relays bytes untouched and never opens TLS, so it records which hosts a job reached but not what it fetched; content comes from the lockfile-driven fetch, checked by hash, not from interception. The OxygenFlow images (images/rust, images/android) are already built this way by hand; this makes it a pipeline feature.
Second of three (after issue #86 environments): build once, deploy the same bytes everywhere. Andy (2026-10-26): "we're doing the same release in both environments, but the source has already been obtained, checked, catalogued and filtered before we reach prod."
One job fetches; every other job is offline. A bundle job is the only one with egress (
network "egress" { allow … }, §4.3.1). It resolves every dependency the release needs into a content-addressed bundle:cargo vendor,pip download --require-hashes…; the bundle step runs them, it does not guess);A bundle is an artifact kind the hub stores by BLAKE3 like any other, but immutable, retained while any environment's deployment names it, and with its SBOM and provenance shown on the run.
Policy on the way in (the "checked, filtered" part): a repository or organisation may set rules a bundle must pass before any environment accepts it: licences allowed, known-vulnerable versions refused (against an advisory database the hub keeps a copy of), hosts the bundle job may reach. A refusal names the package and the rule.
Notes: the egress proxy relays bytes untouched and never opens TLS, so it records which hosts a job reached but not what it fetched; content comes from the lockfile-driven fetch, checked by hash, not from interception. The OxygenFlow images (images/rust, images/android) are already built this way by hand; this makes it a pipeline feature.