Skip unnecessary cache checks

[kylewlacy]

Today, every time needs to be baked locally, we check the remote cache(s) first, in case we can fetch the result instead of building it ourselves.

When dealing with brioche-packages this is ideal! This is how Brioche can fetch packages we pre-built in CI. And even if you're modifying a package locally, you can still sometimes partially re-use build results.

But if you're working outside brioche-packages, this can lead to a lost of wasted checks against the official cache, which both delays the start of the build (wasting time) and creates extra unnecessary traffic for the official cache.

For custom caches, things are a bit murkier. If you have a self-hosted cache on your team, this feature also enables you to share private builds with little friction. That has the same problem though, where projects outside the scope of your team could be pinging the cache unnecessarily.

It feels like we should have a path to avoid checking the cache (or specific custom caches) in cases where a cache hit is impossible or very unlikely.

[kylewlacy]

Here's one way we could handle this: "cache scopes". I'll sketch out one way this could look:

In the brioche-packages repo, we add a new cache-scope field to the workspace file (brioche_workspace.toml):

cache-scope = "brioche-packages"

Then, for the cache config, we add an equivalent cache-scope field. The official cache would also be configured with cache-scope = "brioche-packages".

When we bake a recipe, we first find the cache scope of the project the recipe came from based on its metadata. Then, we only check the cache(s) configured with the same cache-scope (or just build locally if no cache matches).

---

I think if we moved forward with this, there's a lot of nuance still! We'd probably want to allow the cache scope to be set or modified by workspace, project, and maybe even by recipe (passed within the meta value for the recipe).

Also, we'd probably want more than just a single value for the cache scope. At minimum, we'd want both projects and caches to specify multiple cache scopes that should apply, then check caches where there's an intersection. We may even want more complex rules on the cache, something like:

• {include: ["brioche-packages"]} to include just brioche-packages
• {include: ["acme-corp/**"]} to include all tags starting with acme-corp/*
• {exclude: ["brioche-packages"]} to cache everything except things in the brioche-packages scope

...or maybe the cache itself could provide this configuration through a top-level brioche-cache-metadata.json file or something (which could even serve the dual purpose of validating that the cache is configured correctly).