You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
### Why?
The `BuildRunner` interface needs an in-tree noop implementation to
unblock wiring tests, and the orchestrator's build stage needs to drive
the new contract end-to-end: trigger the runner, persist the result,
and poll `Status` until terminal so the batch state machine can react.
### What?
Stacks on top of the BuildRunner interface and `PublishAfter` PRs.
Implements the contract and wires it into the orchestrator pipeline.
The build poll loop runs as queue traffic inside the existing
`buildsignal` consumer (no separate stage). On each delivery it calls
`BuildRunner.Status`, persists the result via `BuildStore.UpdateStatus`,
publishes the batch ID to `speculate` so the state machine re-evaluates,
and re-publishes itself via `Publisher.PublishAfter` until the build
reaches a terminal state. A webhook-capable backend can publish into
the same topic — the consumer cannot tell a poll-driven message from a
push.
Pieces:
- `extension/buildrunner/noop`: a `BuildRunner` stub that returns
`BuildStatusSucceeded` immediately. Useful as a wiring backstop and a
best-case baseline.
- `orchestrator/controller/build`: assembles `base` from
`batch.Dependencies` and `head` from `batch.Contains`, calls
`Trigger`, persists the initial `Build{Accepted}` via
`BuildStore.Create` (`ErrAlreadyExists` is swallowed for redelivery),
publishes to `buildsignal`.
- `orchestrator/controller/buildsignal`: the polling consumer described
above. `PollDelayAcceptedMs=5000`, `PollDelayRunningMs=2000` by
default (vars so tests can override).
- `example/server/orchestrator/main.go`: passes the `BuildRunner` to
both `build.NewController` and `buildsignal.NewController`; pipeline
diagram updated.
0 commit comments