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
refactor(buildrunner): trigger on batches, resolve changes internally
Change BuildRunner.Trigger to take batch identity — base []entity.Batch (the dependency batches) and head entity.Batch (the batch under test) — instead of controller-pre-resolved base/head []entity.Change, per the extension contract. Each implementation (buildkite, githubactions, fake) gains an injected changeset.Resolver and resolves the base and head batches' changes itself; the build controller drops its private collectChanges walk and loads the dependency batches as identity.
Status, Cancel, and the build id/status outputs are unchanged. The wiring injects the resolver into the fake build runner; the buildkite/githubactions Params gain a Resolver field.
Revises build-runner.md, which had deliberately kept batches out of the boundary — the base/head split survives, expressed as batch identity.
Copy file name to clipboardExpand all lines: doc/rfc/submitqueue/build-runner.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,23 +46,23 @@ See `extension/buildrunner/build_runner.go` for the exact Go signatures. The sec
46
46
47
47
### Trigger: base + head
48
48
49
-
`Trigger` takes two ordered lists of changes and a free-form metadata map:
49
+
> **Revised by [extension-contract.md](extension-contract.md).**`Trigger`now takes identity at the batch granularity — `base []entity.Batch` (the dependency batches) and `head entity.Batch` (the batch under test) — and the runner resolves each batch's changes itself through an injected `changeset.Resolver`. The base/head split below still holds; only the boundary type changed from resolved `[]entity.Change` to batch identity. The "rejected: list-of-lists of changes" note is superseded by that RFC's "identity in, resolve internally" principle.
50
50
51
-
-**`base`** — changes from the dependency batches (assumed-good prefix). Ordered.
52
-
-**`head`** — changes from the batch being verified. Ordered.
51
+
`Trigger` takes the base dependency batches, the head batch, and a free-form metadata map:
52
+
53
+
-**`base`** — the dependency batches (assumed-good prefix), ordered. The runner resolves their changes.
54
+
-**`head`** — the batch being verified. The runner resolves its changes.
53
55
-**`metadata`** — caller-supplied attributes (requester, ticket ID, trace ID, etc.) the provider MAY persist or echo back via `Status`. Schema is caller/provider-defined; the interface treats it as opaque. `nil` is equivalent to an empty map.
54
56
55
-
The provider applies `base` then `head` in order on top of the queue's target branch and validates the resulting tree. Validation is **implicit and holistic**: it is not a per-change action, it is what the provider does after applying everything.
57
+
The provider resolves and applies `base` then `head` in order on top of the queue's target branch and validates the resulting tree. Validation is **implicit and holistic**: it is not a per-change action, it is what the provider does after applying everything.
56
58
57
59
Why split base and head:
58
60
59
61
- The orchestrator's internal model already distinguishes them — a speculation path has a head batch and a list of base batches assumed to pass.
60
62
- Lets a provider cache or short-circuit the base when it has validated the same prefix before — a hot path for stacked-batch speculation.
61
63
- Lets the provider attribute terminal failure to base vs head in `BuildMetadata` without the orchestrator having to round-trip the split itself.
62
64
63
-
Rejected: a single flat `changes []entity.Change`. Provider would have to deduce base via prefix matching and could not distinguish "base broke" from "head broke" without out-of-band hints. Loses the orchestrator's clearest piece of structural information at the boundary for no gain.
64
-
65
-
Rejected: list-of-lists, one slice per batch. Pushes batch structure across the boundary, which the provider does not care about. The provider thinks in terms of "stuff to apply before" and "stuff to validate" — base / head matches that mental model. Batches are an orchestrator concept.
65
+
Rejected: a single flat input with no base/head split. Provider would have to deduce base via prefix matching and could not distinguish "base broke" from "head broke" without out-of-band hints. Loses the orchestrator's clearest piece of structural information at the boundary for no gain.
0 commit comments