Skip to content

[A-1638] Dogfood Cache v2 in Agent CI - #4252

Open
jamiemonserrate wants to merge 2 commits into
mainfrom
codex/a-1638-uncached-baseline
Open

[A-1638] Dogfood Cache v2 in Agent CI#4252
jamiemonserrate wants to merge 2 commits into
mainfrom
codex/a-1638-uncached-baseline

Document acknowledgements cache limitation

90fd832
Select commit
Loading
Failed to load commit list.
buildsworth-bk-app / Buildsworth review succeeded Aug 24, 2026 in 4m 12s

Review submitted — commented

Review summary: #4252

Change reviewed

PR #4252 implements A-1638 by dogfooding Cache v2 throughout the Agent repository's CI. It replaces the Linux container bind-mounted Go caches with .buildkite/cache.yml definitions for module caches, normal and race build caches, lint analysis data, per-cross-compile-target objects, E2E caches, the pinned bk executable, protobuf tools, and generated acknowledgements.

The pipeline now assumes the dogfood cache AWS role and makes the cache registry, store, agent token, and ambient AWS credentials available where cache commands run. The affected scripts restore and save purpose-specific entries, use designated single writers for sharded jobs, and include platform/toolchain/dependency inputs in their keys. The acknowledgements path also pins go-licenses, restores a target-specific generated file, and opts the release build into reusing it.

Context and evidence examined

  • Read the full 14-file, 771-line PR diff and every changed file.
  • Read Linear issue A-1638, which is in review and asks the team to dogfood Cache v2 in this repository and report the findings.
  • Traced the changed pipeline commands through the cache CLI implementation, including configuration loading, key resolution, fallback boundaries, API lookup, archive paths, and save/restore behavior.
  • Traced the binary build and acknowledgements generator, protobuf installation path, test-shard writers, E2E trigger, and bk CLI consumer.
  • Reviewed the complete PR conversation and prior buildsworth threads. The cache registry's branch- and pipeline-scoped save policy answers the earlier fork-write trust-boundary question, and the earlier go-licenses version omission was fixed by pinning the tool and keying the acknowledgement entry on its version file.
  • Compared the current commit with the previous reviewed commit. The latest commit only documents the deliberately accepted acknowledgements limitation in .buildkite/cache.yml and the PR description.

Checks performed

  • bash -n / sh -n passed for all changed shell scripts.
  • Both .buildkite/pipeline.yml and .buildkite/pipeline.e2e.yml parsed successfully with buildkite-agent pipeline upload --dry-run --no-interpolation (16 main-pipeline steps and one E2E step). The local shallow checkout prevented the dry run from evaluating if_changed against a merge base, but it did not prevent pipeline parsing.
  • All ten cache definitions loaded, validated, resolved their configured key inputs, and reached expected cache misses against a local mock cache API using the installed buildkite-agent cache command.
  • The local environment did not contain the Go toolchain, so I did not run go test ./..., go build, or Go formatting/lint commands. I also did not perform a live S3/cache-registry round trip.
  • GitHub reported the category-label and both Socket checks passing. The Agent CI build #14047 was still pending when the review was submitted. Direct Buildkite API inspection was unavailable to the configured token, so no job logs were inspected.

Findings and verdict

No new inline findings were raised in this pass.

The previous blocking concern was that go.mod is not a complete input for the cached acknowledgements artifact: a source-only import change can make a package from an already-listed module newly reachable while leaving the exact cache key unchanged. The author explicitly accepted that narrow stale-attribution risk for this dogfood iteration and documented the conditions and trade-off in both the cache definition and PR description. The previous changes-requested review was therefore dismissed rather than left as an unresolved block.

I submitted a COMMENT review, not an approval. The implementation has no newly identified issue, but the release-attribution risk was accepted rather than removed, so the review does not put an approval behind that author-owned trade-off.

Submitted review: #4252 (review)

Trigger source: automatic.