Menu

Learn

Sharing work

Your store

Everything blaze compiles goes into a store on your disk: compiled functions, macro expansions, build-script runs, the standard library and, if you opt in, test passes.

Every checkout of yours uses the same store.

Look before you compile

Each entry is filed under its key. Before compiling anything, blaze looks the key up: if it's in the store, the work is already done.

An old branch

You switch back to a branch you built yesterday, with the same blaze, and nothing on it has changed since. What happens to its functions?

  1. It's compiled again, to be safe.Same inputs give the same key and the same result, so compiling again would only make the same thing.
  2. Each is found in the store under the same key, and used as is.Each crate's source hashes the same as yesterday, so every key matches again and yesterday's results are used.
  3. blaze asks you which version to use.There's nothing to choose: the key says exactly which result fits.
Show the answer

Each is found in the store under the same key, and used as is. Each crate's source hashes the same as yesterday, so every key matches again and yesterday's results are used.

A shared store

A store can also live somewhere else: a shared folder, an S3 bucket or blaze's cache server. Pushing sends your entries there; pulling brings other people's back.

Your laptop builds and pushes to a shared store; a teammate's build of the same code finds the work there instead of compiling it.

With BLAZE_REMOTE set, blaze pulls when it starts and pushes as it goes; no build waits on the network.

A teammate's store

A teammate pushed their work. You pull, then build the same commit with the same blaze. What happens?

  1. blaze compiles everything again, because it was built on another machine.The machine isn't part of the key: the same blaze, target and source give the same key, and the same result.
  2. You also get their uncommitted edits.Keys come from inputs. Different source gives different keys, so their edits never match your code.
  3. Their compiled functions come from the store, and only what's missing is compiled.Their results have the same keys as yours would, so they fit.
Show the answer

Their compiled functions come from the store, and only what's missing is compiled. Their results have the same keys as yours would, so they fit.

Names you can check

The files a store sends are named by a hash of their bytes, so neither the store nor the network can swap them unnoticed. But anyone who can write to a shared store could add wrong code under real keys.

To stop that, a shared store's manifests can be signed, and blaze can refuse any not signed by a key you trust.

Running work elsewhere

Sending long builds and test runs off to other machines is called remote execution. blaze doesn't do it.

It isn't built or designed yet: the shared store comes first. blaze's own CI doesn't fill a shared store yet either.

Which works today?

Which of these can blaze do today?

  1. Run your test suite on a farm of other machines.That's remote execution, which isn't built.
  2. Push compiled work to a shared store, and pull it back.Push and pull work today, to a shared folder, an S3 bucket or blaze's cache server.
Show the answer

Push compiled work to a shared store, and pull it back. Push and pull work today, to a shared folder, an S3 bucket or blaze's cache server.

Where to go next

Installing is one line: curl -fsSL https://ix.dev/blaze | sh. Install has the other ways in, Usage the day to day. The course map shows what you've done.

Discussion

Questions, corrections, ideas: anything about this page.

Sign in with GitHub to comment.