Learn

Hermetic builds

It works on my machine

Builds can quietly depend on things nobody wrote down: a tool on your laptop, a file in your home folder, the network.

Then the same code builds one way for you and another way for a teammate.

Sealed

A hermetic build is sealed: it depends only on its declared inputs. For blaze that's your source, your locked dependencies (Cargo.lock) and blaze's pinned toolchain.

That's the goal: nothing else on the machine gets in.

Two laptops

Two people build the same commit with blaze, on different laptops. What does a hermetic build promise them?

The same build time.Speed depends on the machine. Hermetic is about what comes out, not how long it takes.
A program that behaves the same, because the inputs are the same.Same inputs in, the same program out, whatever else each laptop has installed.
That both laptops have the same tools installed.The opposite: what else is installed shouldn't matter, because the build can't see it.

Show the answer

A program that behaves the same, because the inputs are the same. Same inputs in, the same program out, whatever else each laptop has installed.

One toolchain

Your project may pin a Rust version in rust-toolchain.toml. blaze uses its own pinned nightly instead, whatever the project says.

It downloads it once, and refuses any file whose hash doesn't match the one built into blaze.

Filed under a key

To keep a compiled function, blaze files it under a key: a hash of everything that could change the machine code that comes out.

If any of that changes, the key changes, and the old copy simply isn't found.

What goes in the key?

Tap the things that go into the key of a compiled function.

For each one, ask: could it change the machine code that comes out?

Show the answer

The key holds the function's name and a hash of its whole crate's source, plus the optimisation level, the target and blaze's own build, so editing any line of the crate, or renaming the function, gives it a new key; the time of day and your user name stay out.

Sealed where it matters

Build scripts and proc macros, the parts that run your dependencies' code during a build, already run in a sandbox: no network, and no writes outside their own folder.

Tests (sandboxed only if a workspace opts in, for now) and Windows (no sandbox yet) are still to close, so blaze's builds aren't fully hermetic yet.

Where tests are sandboxed, a pass is kept too: with BLAZE_TESTS=affected, cargo blaze test runs only the tests that haven't passed with their inputs as they are now.

When is a copy safe?

A kept build result is safe to reuse when...

...it was built on the same laptop.That's what hermetic avoids: the machine shouldn't matter.
...it was built recently.Age doesn't matter. A year-old copy is right if the inputs match, and a fresh one is wrong if they don't.
...nothing outside its inputs could have changed it.Then the same key really means the same result.

Show the answer

...nothing outside its inputs could have changed it. Then the same key really means the same result.

Discussion

Questions, corrections, ideas: anything about this page.