Skip to content

docs(stovepipe): rewrite workflow RFC around poll/ingest/greenness design#275

Open
behinddwalls wants to merge 1 commit into
mainfrom
preetam/stovepipe-workflow-rfc
Open

docs(stovepipe): rewrite workflow RFC around poll/ingest/greenness design#275
behinddwalls wants to merge 1 commit into
mainfrom
preetam/stovepipe-workflow-rfc

Conversation

@behinddwalls

@behinddwalls behinddwalls commented Jun 26, 2026

Copy link
Copy Markdown
Collaborator

Summary

Why?

The previous workflow RFC described a webhook+poller, SHA-keyed, batch/bisection-heavy pipeline. The design has since moved to a poller-driven, VCS-agnostic model that records a greenness degree per commit and refines it to per-project granularity for deployment gating. The doc needed a full rewrite to reflect the design as it now stands rather than a delta.

What?

Rewrites doc/rfc/stovepipe/workflow.md as a self-contained design:

  • VCS-agnostic identity: every commit/ref/head is an opaque URI owned by a SourceControl extension (git://remote/repo/ref/…/<sha>); the build system sits behind the build-runner extension and yields a target graph.
  • Queue is the validation namespace (a named repo+ref) that namespaces Request IDs, is the ingest handle, and owns the last-green URI + greenness history — distinct from the messaging queue.
  • Greenness is a degree (0 green … 1 fully broken) with room for partial breakage once projects exist; "not recorded" is not-green for gating.
  • Two-phase pipeline: ingest → process → build → buildsignal → record (whole-repo greenness), then analyze → build → buildsignal → record (per-project greenness). record is re-entrant and non-terminal; process decides incremental-since-green vs full-monorepo via SourceControl ancestry (history-rewrite fallback).
  • Hooks extension is the downstream notification boundary for green/not-green events.
  • Carries over the fail-closed-to-not-green posture (DLQ reconciliation) and dedup on (Queue, head URI).
  • Ends with Open Questions: greenness degree semantics, webhook ingestion, project-mapping contract.

Test Plan

Issues

Stack

  1. @ docs(stovepipe): rewrite workflow RFC around poll/ingest/greenness design #275
  2. feat(stovepipe): add Request entity, Ingest RPC, and thin ingest controller #276

…sign

## Summary

### Why?

The previous workflow RFC described a webhook+poller, SHA-keyed, batch/bisection-heavy pipeline. The design has since moved to a poller-driven, VCS-agnostic model that records a greenness *degree* per commit and refines it to per-project granularity for deployment gating. The doc needed a full rewrite to reflect the design as it now stands rather than a delta.

### What?

Rewrites `doc/rfc/stovepipe/workflow.md` as a self-contained design:

- VCS-agnostic identity: every commit/ref/head is an opaque URI owned by a `SourceControl` extension (`git://remote/repo/ref/…/<sha>`); the build system sits behind the build-runner extension and yields a target graph.
- `Queue` is the validation namespace (a named repo+ref) that namespaces Request IDs, is the ingest handle, and owns the last-green URI + greenness history — distinct from the messaging queue.
- Greenness is a degree (`0` green … `1` fully broken) with room for partial breakage once projects exist; "not recorded" is not-green for gating.
- Two-phase pipeline: ingest → process → build → buildsignal → record (whole-repo greenness), then analyze → build → buildsignal → record (per-project greenness). `record` is re-entrant and non-terminal; `process` decides incremental-since-green vs full-monorepo via SourceControl ancestry (history-rewrite fallback).
- `Hooks` extension is the downstream notification boundary for green/not-green events.
- Carries over the fail-closed-to-not-green posture (DLQ reconciliation) and dedup on `(Queue, head URI)`.
- Ends with Open Questions: greenness degree semantics, webhook ingestion, project-mapping contract.
@behinddwalls behinddwalls force-pushed the preetam/stovepipe-workflow-rfc branch from 20b9d7d to 6305146 Compare June 26, 2026 05:24
@behinddwalls behinddwalls marked this pull request as ready for review June 26, 2026 05:25
@behinddwalls behinddwalls requested review from a team and sbalabanov as code owners June 26, 2026 05:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants