Skip to content

feat(build): add BuildManager extension and trim BuildStatus enum#167

Closed
behinddwalls wants to merge 1 commit into
mainfrom
preetam/build-ext
Closed

feat(build): add BuildManager extension and trim BuildStatus enum#167
behinddwalls wants to merge 1 commit into
mainfrom
preetam/build-ext

Conversation

@behinddwalls
Copy link
Copy Markdown
Collaborator

@behinddwalls behinddwalls commented May 29, 2026

Summary

Adds a vendor-agnostic BuildManager interface under extension/build
so the orchestrator can drive builds against an external provider
(BuildKite, Jenkins, an internal job runner, etc.) without coupling to
any one of them.

Interface

BuildManager exposes four verbs — Trigger, Status, Cancel,
Close:

  • Trigger returns (buildID, status, error); an implementation that
    can deduce an already-finished build returns its terminal status so
    the caller can skip the first Status poll, otherwise Accepted.
  • Status may be synchronous and lengthy (a provider round trip);
    Trigger/Cancel must return promptly.
  • The godoc spells out what is required of an implementation:
    concurrency safety, internal recovery from transient connectivity
    failures, transient-only local state, and plain errors left for the
    controller to classify per core/errs. No custom error sentinels
    ship yet — they land with the first implementation that needs them.

Entity changes

  • entity.BuildStatus is
    {Unknown, Accepted, Running, Succeeded, Failed, Cancelled}. This
    drops the provider-specific Queued/Blocked stages and renames
    Passed → Succeeded, while keeping Running as a first-class
    non-terminal state so callers can distinguish a queued/accepted build
    from one that is actively executing. Orchestrator build/buildsignal
    references use Accepted.
  • Adds entity.ChangeAction, entity.BuildChange,
    entity.BuildMetadata as Trigger inputs/outputs.

Out of scope

No backend implementation and no orchestrator wiring — those are
follow-ups.

Test Plan

  • ✅ `make fmt && make lint`
  • ✅ `make check-tidy && make check-gazelle && make check-mocks`
  • ✅ `bazel build //...`
  • ✅ `bazel test //... --test_tag_filters=-integration`
    (integration tests require Docker, not run here)

Issues

Stack

  1. @ feat(build): add BuildManager extension and trim BuildStatus enum #167
  2. feat(build): add noop BuildManager implementation #168
  3. feat(orchestrator): wire BuildManager into the build controller #169

@behinddwalls behinddwalls marked this pull request as ready for review May 29, 2026 21:31
@behinddwalls behinddwalls requested review from a team and sbalabanov as code owners May 29, 2026 21:31
## Summary

Adds a vendor-agnostic `BuildManager` interface under `extension/build`
so the orchestrator can drive builds against an external provider
(BuildKite, Jenkins, an internal job runner, etc.) without coupling to
any one of them.

### Interface

`BuildManager` exposes four verbs — `Trigger`, `Status`, `Cancel`,
`Close`:

- `Trigger` returns `(buildID, status, error)`; an implementation that
  can deduce an already-finished build returns its terminal status so
  the caller can skip the first `Status` poll, otherwise `Accepted`.
- `Status` may be synchronous and lengthy (a provider round trip);
  `Trigger`/`Cancel` must return promptly.
- The godoc spells out what is required of an implementation:
  concurrency safety, internal recovery from transient connectivity
  failures, transient-only local state, and plain errors left for the
  controller to classify per `core/errs`. No custom error sentinels
  ship yet — they land with the first implementation that needs them.

### Entity changes

- `entity.BuildStatus` is
  `{Unknown, Accepted, Running, Succeeded, Failed, Cancelled}`. This
  drops the provider-specific `Queued`/`Blocked` stages and renames
  `Passed → Succeeded`, while keeping `Running` as a first-class
  non-terminal state so callers can distinguish a queued/accepted build
  from one that is actively executing. Orchestrator build/buildsignal
  references use `Accepted`.
- Adds `entity.ChangeAction`, `entity.BuildChange`,
  `entity.BuildMetadata` as `Trigger` inputs/outputs.

### Out of scope

No backend implementation and no orchestrator wiring — those are
follow-ups.

## Test Plan

- ✅ \`make fmt && make lint\`
- ✅ \`make check-tidy && make check-gazelle && make check-mocks\`
- ✅ \`bazel build //...\`
- ✅ \`bazel test //... --test_tag_filters=-integration\`
  (integration tests require Docker, not run here)

## Issues

(none)
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.

1 participant