kunobi-ninja/kache v0.25.0

v0.25.0: faster cold builds, planner login

on GitHub

Cold builds through kache are much closer to plain Cargo, and the planner service can now authenticate people and CI jobs without a shared secret. Nothing in this release invalidates an existing cache.

On gpui-kit v0.6.4 (8 CPUs, cargo -j8, default config, fresh store and target each run) a cold build went from 206 s to 137 s. Plain Cargo takes 121 to 126 s on the same machine, so a cold build through kache is still about 10% slower. Warm builds are unaffected.

Speed

• Unrelated cold compiles no longer wait for each other (#1116). Two compiles shared a queue slot when they had the same compiler, crate name and output kind, even though only an identical cache key can be served by someone else's result. That serialized every build script (all named build_script_build), every crate present in two versions, and every same-named C source, such as the parser.c of each tree-sitter grammar. Waiting is now per cache key. Library crates also stopped counting as link jobs: Cargo passes --emit=link for an rlib, but rustc writes that archive itself, so the scheduler was admitting half as many compiles as Cargo started. On the gpui-kit build, time spent waiting for a permit fell from 398 s to 11 s summed over all wrapper processes. Cold build: 206 s to 144 s.
• The first compile of a crate skips the dependency pre-pass (#1117). Before every lookup kache runs rustc once to list the crate's inputs. When the store holds no entry for that crate name, no key can match, so kache now compiles first and keys from the dep-info rustc emits. This used to need input_predictions, which is off by default. 764 of 1062 units took the new path, and pre-pass time fell from 65 s to 12 s. Cold build: 146 s to 137 s. It does not apply when a remote or a fallback compiler cache is configured, or to a crate name the store has seen before, which includes every build script after the first.

Planner authentication

This section only matters if you run or use kache-service.

• kache login and GitHub Actions OIDC (#1115). The service accepted one optional shared bearer token. It can now also accept a Kunobi account and a GitHub Actions job's own identity token. With no provider configured it stays anonymous, as before, and --token works unchanged.

  On a developer machine, log in once:

  kache login            # opens a browser
  kache login --device   # for a machine without one
  kache logout

  In GitHub Actions the client fetches the job's token itself. The job needs:

  permissions:
    id-token: write

  On the service, enable the providers you want:

  kache-service --oidc-issuer <issuer> --oidc-client-id <client-id>
  kache-service --github-oidc-audience https://kache.example.com --github-owner your-org

  The service refuses to start with an audience and no owner, because that would trust every repository on GitHub. The Helm chart has matching auth.oidc.* and auth.githubOidc.* values.

  The client picks a credential in this order: KACHE_PLANNER_TOKEN, then the Actions job token, then your stored session. The last two are sent only over HTTPS or to loopback, and a session goes only to a planner you ran kache login against. A planner URL that arrives through a project's config cannot collect your credentials. If no credential resolves, the request goes out without one and kache plans locally.

  Setup details are in Remote service: Authentication.

Fixed

• Plan ids are unique across replicas (#1113). An id was plan- plus the millisecond timestamp, so two requests in the same millisecond, or on two replicas, shared one. It is now plan- plus a UUID.

Changed

• kache-service serves /v1/prefetch-plan only (#1113). /v2/prefetch-plan was the same handler under a second name and now returns 404. The kache client rewrites a configured /v2 endpoint to /v1, so existing client configs keep working. Update anything else that calls the /v2 path directly.

Contributors

Full changelog: v0.24.0...v0.25.0