feat: add required cache-key input, native GC, and server-driven config for v2

[piob-io]

Summary

v2 of setup-docker-builder with three changes:

1. Required cache-key input replaces hardcoded GITHUB_REPO_NAME

Repos with multiple Dockerfiles (e.g., services/api/Dockerfile + services/web/Dockerfile) currently thrash each other's cache due to last-writer-wins commit semantics on a shared sticky disk key. cache-key makes the cache entity explicit — different Dockerfiles get different keys, eliminating cross-target thrashing.

# before (v1): implicit key = repo name → all targets share one cache
- uses: useblacksmith/setup-docker-builder@v1

# after (v2): explicit key per Dockerfile
- uses: useblacksmith/setup-docker-builder@v2
  with:
    cache-key: services/api/Dockerfile

stateHelper.setCacheKey() / getCacheKey() persists the value across setup → post phases, and commitStickyDisk() now passes it to the RPC.

2. BuildKit native GC replaces manual buildctl prune

• buildkitd.toml: gc = true with gcPolicy = [{ keepDuration = "192h", all = true }] (8-day retention)
• Removed max-cache-size-mb input and the entire manual prune block from post phase
• writeBuildkitdTomlFile now accepts an optional BuildkitdConfig parameter (falls back to DEFAULT_BUILDKITD_CONFIG)

3. Server-driven config infrastructure (src/server-config.ts)

Two primitives for future backend control without action updates:

• BuildkitdConfig: structured config for daemon startup (gc on/off, gcPolicy[], maxParallelism). Currently hardcoded; Phase 2 will read from GetStickyDisk RPC response.
• PreCommitHook[] + runPreCommitHooks(): ordered opaque shell commands run before commit. Each hook has command, timeoutSeconds, and failureMode (skip_commit | commit_anyway | abort). Currently empty list; Phase 3 PrepareCommit RPC will populate.

Post-phase flow:

PrepareCommitResponse { shouldCommit, hooks[] }
  → run hooks (if any, with timeout + failure handling)
  → if shouldCommit: commitStickyDisk(exposeId, size, cacheKey)

4. Cleanup: removed unused rollup build artifacts

rollup.config.js and rollup devDependencies removed — the repo switched to ncc bundling previously but never cleaned these up. dist/main.bundle.mjs (rollup output) was already absent.

Design doc: FastActions/fa#4249</n Public docs: useblacksmith/docs#228</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n</n">

Link to Devin session: https://app.devin.ai/sessions/1054a9452e8a49ccb891391e2327a612
Requested by: @piob-io

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled. (Staging)}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[bruce-y]

I think if we're going to turn GC back on we should probably remove the relevant code in our buildkit fork that alters the GC behaviour here that we added to support the previous usecase: useblacksmith/buildkit@e27a9da

[devin-ai-integration]

Good call. For context on the interaction with our v2 GC config:

Our policy is { keepDuration: "192h", all: true } — no keepBytes. So in pruneOnce, your commit's key condition:

if len(cr.refs) > 0 && (!opt.all || opt.keepBytes == 0) {
    cr.mu.Unlock()
    continue  // still skips layers with refs
}

evaluates to !true || 0 == 0 → true, meaning layers with active refs are still skipped. So the behavioral change in e27a9dac doesn't actually activate with our current config — it only kicks in when all: true AND keepBytes > 0 (size-based GC).

That said, agreeing it's worth reverting to stay closer to upstream. The other two fork commits (v0.29.1 sort fix, v0.29.2 debug logging) are independent and could be evaluated separately.

This is a BuildKit fork change though, not an action change — flagging for @piotr to decide whether to handle as part of this PR or separately.

[piob-io]

We will have to support both action versions concurrently for a while. If the same version behaves well enough for both, I'd delay the cleanup. However, if the patched binary behaves observably worse for the new setup, we need a way for actions at different versions to reference two different binaries. Devin, please analyze.

[devin-ai-integration]

Analyzed all three fork patches (v0.29.1–v0.29.3) against both action versions. The same binary works correctly for both v1 and v2 — no observable difference for either.

Per-patch analysis

Patch	What it does	v1 (gc: false, manual buildctl prune --keep-storage=X)	v2 (gc: true, keepDuration=192h, all=true, no keepBytes)
v0.29.1 (always sort)	Moves sortDeleteRecords outside the if gcMode block so candidates are sorted in non-GC mode too	✅ Needed — fixes random deletion order during manual prune	Neutral — in GC mode, sorting already happened before this patch (batchSize=1 picks the first sorted record)
v0.29.2 (debug logging)	Adds Infof for skipped-ref layers and first deletion candidate	Removed by v0.29.3 — no longer in the codebase	N/A
v0.29.3 (refs + --all)	When all=true AND keepBytes > 0: includes ref'd layers in candidate evaluation instead of skipping them	✅ Needed — v1's --keep-storage sets keepBytes > 0, so ref'd layers are correctly counted toward size budget	No-op — v2 has keepBytes=0, so the guard !opt.all || opt.keepBytes == 0 → true, and ref'd layers are still skipped (identical to upstream)

Why one binary is fine

The v0.29.3 behavioral change is gated by keepBytes > 0. v2 never sets keepBytes (our policy is purely time-based), so the patched code path is never reached. v2's pruneOnce executes identically to upstream BuildKit for our config.

v1 needs the patch active because manual prune uses --keep-storage which sets keepBytes > 0.

Sorting change (v0.29.1) is beneficial for both

The sort fix moves sortDeleteRecords(toDelete) to run unconditionally (when there are candidates), rather than only in GC mode. For v2 this is harmless (GC mode processes 1 record at a time anyway, sorting is just "pick the oldest"). For v1 it's a correctness fix.

Recommendation: keep the current binary for both versions. No cleanup needed until v1 is fully deprecated.