feat(stovepipe): add BuildRequest/BuildSignal queue contract#376
Merged
behinddwalls merged 2 commits intoJul 20, 2026
Merged
Conversation
roychying
requested review from
a team,
behinddwalls and
sbalabanov
as code owners
July 15, 2026 21:45
mnoah1
approved these changes
Jul 16, 2026
roychying
force-pushed
the
chenghan.ying/stovepipe-build/buildsignal-queue-contract
branch
from
July 16, 2026 18:11
e9cb9e4 to
75f2997
Compare
behinddwalls
approved these changes
Jul 20, 2026
behinddwalls
temporarily deployed
to
stack-rebase
July 20, 2026 18:14 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
JamyDev
pushed a commit
that referenced
this pull request
Jul 24, 2026
## Why?
Stovepipe's pipeline needs two more internal queue stages to carry a
request through building and polling its build result: `build`
(process/analyze hands off a request once its build scope is decided)
and `buildsignal` (build hands off the triggered build so its status can
be polled to a terminal state). Both stages' wire payloads need to be
defined before their controllers can be implemented, per the algorithms
in `doc/rfc/stovepipe/steps/build.md` and `buildsignal.md`.
## What?
- Added `buildsignal.proto` / generated `buildsignal.pb.go`, defining
`BuildSignal { id }` — the build id to poll, following the same "id
only" convention as the rest of the internal pipeline (producer and
consumer share the store, so redelivery stays idempotent).
- Added `TopicKeyBuildSignal` alongside the existing `TopicKeyBuild` in
`topics.go`, and the `BuildSignal` alias in `messagequeue.go`.
- - Renamed `process_test.go` → `messagequeue_test.go` since its
round-trip and topic-key-binding guard tests are package-wide, not
process-specific, and extended them to cover `BuildSignal` (round-trip
test, wire-format check, and the `TestTopicKeysBindEveryTopicKey` drift
guard).
## Test Plan
- `make build` and `make test` - all clean
## Issue
<!--
Link the issue here.
- Use 'Closes #123' if this is the final fix.
- Use 'Part of #123' or just '#123' if the feature is still in progress.
-->
JamyDev
pushed a commit
that referenced
this pull request
Jul 24, 2026
## Why?
Stovepipe's pipeline needs two more internal queue stages to carry a
request through building and polling its build result: `build`
(process/analyze hands off a request once its build scope is decided)
and `buildsignal` (build hands off the triggered build so its status can
be polled to a terminal state). Both stages' wire payloads need to be
defined before their controllers can be implemented, per the algorithms
in `doc/rfc/stovepipe/steps/build.md` and `buildsignal.md`.
## What?
- Added `buildsignal.proto` / generated `buildsignal.pb.go`, defining
`BuildSignal { id }` — the build id to poll, following the same "id
only" convention as the rest of the internal pipeline (producer and
consumer share the store, so redelivery stays idempotent).
- Added `TopicKeyBuildSignal` alongside the existing `TopicKeyBuild` in
`topics.go`, and the `BuildSignal` alias in `messagequeue.go`.
- - Renamed `process_test.go` → `messagequeue_test.go` since its
round-trip and topic-key-binding guard tests are package-wide, not
process-specific, and extended them to cover `BuildSignal` (round-trip
test, wire-format check, and the `TestTopicKeysBindEveryTopicKey` drift
guard).
## Test Plan
- `make build` and `make test` - all clean
## Issue
<!--
Link the issue here.
- Use 'Closes #123' if this is the final fix.
- Use 'Part of #123' or just '#123' if the feature is still in progress.
-->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why?
Stovepipe's pipeline needs two more internal queue stages to carry a request through building and polling its build result:
build(process/analyze hands off a request once its build scope is decided) andbuildsignal(build hands off the triggered build so its status can be polled to a terminal state). Both stages' wire payloads need to be defined before their controllers can be implemented, per the algorithms indoc/rfc/stovepipe/steps/build.mdandbuildsignal.md.What?
buildsignal.proto/ generatedbuildsignal.pb.go, definingBuildSignal { id }— the build id to poll, following the same "id only" convention as the rest of the internal pipeline (producer and consumer share the store, so redelivery stays idempotent).TopicKeyBuildSignalalongside the existingTopicKeyBuildintopics.go, and theBuildSignalalias inmessagequeue.go.process_test.go→messagequeue_test.gosince its round-trip and topic-key-binding guard tests are package-wide, not process-specific, and extended them to coverBuildSignal(round-trip test, wire-format check, and theTestTopicKeysBindEveryTopicKeydrift guard).Test Plan
make buildandmake test- all cleanIssue