Skip to content

Reduce CI binary build fan-in - #4213

Open
lox wants to merge 3 commits into
mainfrom
reduce-ci-binary-fan-in
Open

Reduce CI binary build fan-in#4213
lox wants to merge 3 commits into
mainfrom
reduce-ci-binary-fan-in

Disable end-to-end test result caching

7f1eac0
Select commit
Loading
Failed to load commit list.
buildsworth-bk-app / Buildsworth review succeeded Aug 8, 2026 in 8m 44s

Review submitted — commented

Review summary: buildkite/agent PR #4213

Change reviewed

This PR reduces CI fan-in around cross-platform binary builds. It replaces the single 22-target build-binary matrix dependency with three cohorts in .buildkite/pipeline.yml:

  • build-core-linux-binary: Linux amd64 and arm64, consumed by E2E, version, CLI, and Docker checks.
  • build-package-linux-binary: six additional Linux architectures consumed by Debian/RPM packaging.
  • build-binary: the remaining 14 release-only targets.

Consumers now depend only on the cohorts that produce the artifacts they download, while GitHub release assembly still waits for all three cohorts. The PR also mounts persistent Go build and module caches into the E2E compose service and adds -count=1 to the E2E go test invocation so test results are not reused.

No Linear issue identifier was present in the branch name, PR title, or PR description.

What I examined

I read the complete diff and the full changed files:

  • .buildkite/pipeline.yml
  • .buildkite/docker-compose.yml
  • .buildkite/steps/e2e-tests.sh

I also traced the affected artifact and execution paths through:

  • .buildkite/pipeline.e2e.yml and .buildkite/Dockerfile-e2e
  • .buildkite/steps/build-binary.sh and scripts/build-binary.sh
  • .buildkite/steps/build-debian-packages.sh
  • .buildkite/steps/build-rpm-packages.sh
  • .buildkite/steps/build-github-release.sh
  • .buildkite/steps/build-docker-image.sh
  • .buildkite/steps/check-version-string.sh
  • .buildkite/steps/test-bk.sh

The E2E child pipeline runs on Linux amd64 and downloads that exact artifact. The Docker build downloads Linux amd64 and arm64. Debian and RPM consume only the union of the core and package cohorts. GitHub release assembly downloads all binaries and retains dependencies on every cohort. The provenance-attestation naming template is unchanged across the split.

I fetched the complete PR conversation, inline review comments, review-thread metadata, and prior reviews. There were no inline threads or PR comments to deduplicate, no outstanding prior buildsworth concerns, and no human blocking review. A prior buildsworth review had already found no issues on the earlier revision.

Verification performed

  • Parsed .buildkite/pipeline.yml with the repository's buildkite-agent pipeline upload --dry-run --reject-parse-warnings --no-interpolation path successfully.
  • Programmatically expanded the base and changed binary matrices. Both produce the same 22 unique OS/architecture targets, with no missing, added, or duplicated target; the new cohort counts are 2, 6, and 14.
  • Checked every declared pipeline dependency against the parsed step keys; no dependency references were missing.
  • Compared each narrowed consumer's downloaded artifact set with the artifacts available from its declared cohorts; all required artifacts are covered.
  • Ran bash -n .buildkite/steps/e2e-tests.sh successfully.
  • Ran git diff --check origin/main...HEAD successfully.
  • Confirmed that -count=1 is passed after gotestsum's --, so it reaches go test while compilation/module caches remain reusable.
  • Confirmed the E2E cache mounts and environment variables follow the existing lint and agent compose-service pattern.
  • Observed Buildkite agent build #13872 complete successfully via the GitHub commit status (Build #13872 passed (8 minutes, 16 seconds)). The label and Socket checks also passed.

I did not run go test ./...; the environment did not have the Go toolchain, and this PR changes no Go source. Docker Compose validation was not available because Docker was absent. Direct Buildkite API access to individual jobs was unavailable with the session token, so the fresh build's overall successful GitHub status—not individual job logs—was verified.

Findings and verdict

I found no actionable correctness, security, data-integrity, or contract issues. In particular, the matrix split preserves all release artifacts and attestation filenames, and each consumer remains gated on every cohort it needs. Persisting the E2E build/module caches does not enable successful test-result reuse because the final revision explicitly uses -count=1.

I submitted a COMMENT review with no inline findings. The change modifies the release pipeline's artifact dependency graph, so the review leaves final sign-off to a human rather than approving it automatically.

Trigger source: automatic.