Skip to content

refactor(platform)!: move CI clients out of extension/ to platform/ - #579

Merged
mnoah1 merged 1 commit into
mainfrom
preetam/fix-buildrunner
Aug 12, 2026
Merged

refactor(platform)!: move CI clients out of extension/ to platform/#579
mnoah1 merged 1 commit into
mainfrom
preetam/fix-buildrunner

Conversation

@behinddwalls

@behinddwalls behinddwalls commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

Summary

Why?

platform/extension/buildrunner/{buildkite,githubactions} were filed as extensions, but neither is one. Per CLAUDE.md, an extension/{ext} package holds the behavioral interface, its Config, and the Factory interface — platform/extension/buildrunner/ had no Go package at its root at all, just two impl directories under an empty namespace. Both packages say so in their own doc comments: "It intentionally holds no BuildRunner interface or domain entity types."

What they actually are is vendor HTTP clients over platform/http — REST calls plus provider-specific vocabulary (Buildkite's state strings, GitHub Actions' status/conclusion pair, id encoding). That makes them siblings of platform/http and platform/errs, not extensions. The real BuildRunner contracts already live where they belong, at submitqueue/extension/buildrunner and stovepipe/extension/buildrunner; these clients are what those extensions' backends wrap.

What?

Moves both packages up to platform/buildkite and platform/githubactions and deletes the now-empty platform/extension/buildrunner/. Pure relocation — no behavior, no signatures, no test logic changed.

Import paths and Bazel labels updated across the four consumer packages ({submitqueue,stovepipe}/extension/buildrunner/{buildkite,githubactions}), which keep their platformbuildkite/platformgithubactions aliases.

platform/README.md gains an entry for the two clients and a line on the platform/ vs platform/extension/ test, so the next vendor client lands in the right place.

In doc/rfc/stovepipe/steps/build.md, only the adopted option is repathed. The rejected alternatives there describe a shared BuildRunner interface, which genuinely would have been an extension — so their platform/extension/buildrunner references are correct as written and left intact. The adopted option now also records why the shipped package is not an extension: it is precisely the option that declines to define a shared interface.

Test Plan

  • bazel test //platform/buildkite/... //platform/githubactions/... //submitqueue/extension/buildrunner/... //stovepipe/extension/buildrunner/... — 8/8 pass
  • bazel build //... — 309 targets
  • make fmt (no changes), make lint, make check-gazelle, make check-tidy

## Summary

### Why?

`platform/extension/buildrunner/{buildkite,githubactions}` were filed as extensions, but neither is one. Per [CLAUDE.md](CLAUDE.md), an `extension/{ext}` package holds the behavioral interface, its `Config`, and the `Factory` interface — `platform/extension/buildrunner/` had no Go package at its root at all, just two impl directories under an empty namespace. Both packages say so in their own doc comments: "It intentionally holds no BuildRunner interface or domain entity types."

What they actually are is vendor HTTP clients over `platform/http` — REST calls plus provider-specific vocabulary (Buildkite's state strings, GitHub Actions' status/conclusion pair, id encoding). That makes them siblings of `platform/http` and `platform/errs`, not extensions. The real `BuildRunner` contracts already live where they belong, at `submitqueue/extension/buildrunner` and `stovepipe/extension/buildrunner`; these clients are what those extensions' backends wrap.

### What?

Moves both packages up to `platform/buildkite` and `platform/githubactions` and deletes the now-empty `platform/extension/buildrunner/`. Pure relocation — no behavior, no signatures, no test logic changed.

Import paths and Bazel labels updated across the four consumer packages (`{submitqueue,stovepipe}/extension/buildrunner/{buildkite,githubactions}`), which keep their `platformbuildkite`/`platformgithubactions` aliases.

`platform/README.md` gains an entry for the two clients and a line on the `platform/` vs `platform/extension/` test, so the next vendor client lands in the right place.

In [doc/rfc/stovepipe/steps/build.md](doc/rfc/stovepipe/steps/build.md), only the *adopted* option is repathed. The rejected alternatives there describe a shared `BuildRunner` **interface**, which genuinely would have been an extension — so their `platform/extension/buildrunner` references are correct as written and left intact. The adopted option now also records why the shipped package is not an extension: it is precisely the option that declines to define a shared interface.

## Test Plan

- ✅ `bazel test //platform/buildkite/... //platform/githubactions/... //submitqueue/extension/buildrunner/... //stovepipe/extension/buildrunner/...` — 8/8 pass
- ✅ `bazel build //...` — 309 targets
- ✅ `make fmt` (no changes), `make lint`, `make check-gazelle`, `make check-tidy`
@behinddwalls
behinddwalls marked this pull request as ready for review August 12, 2026 03:55
@behinddwalls
behinddwalls requested review from a team and sbalabanov as code owners August 12, 2026 03:56
@mnoah1
mnoah1 added this pull request to the merge queue Aug 12, 2026
Merged via the queue into main with commit d9f97f6 Aug 12, 2026
27 checks passed
@mnoah1
mnoah1 deployed to stack-rebase August 12, 2026 14:19 — with GitHub Actions Active
@behinddwalls
behinddwalls deleted the preetam/fix-buildrunner branch August 12, 2026 14:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants