syncode/control

feat: measure what this control plane would have run #18

Merged

day01 merged %!d() commits from %!s() into %!s()

2026-08-13 11:21:30 +00:00

day01 commented

2026-08-13 11:17:32 +00:00

Owner

Roadmap step 5, done as a measurement rather than as a deployment.

Deciding which runs an event asks for is a function of the workflow files at a commit and the event itself. It needs no database, no node and no deployment, so it is measured here rather than by standing a second control plane beside the forge and waiting for pushes: the runs arise in memory, through the same trigger the service uses, and are thrown away once counted. Five repositories in eight seconds, against weeks of waiting for a live shadow to see the same thing.

Against the five SynCode repositories:

repository	forge	control
`syncode/meta`	1 × `docs.yml`	1 × `docs.yml`	agrees
`syncode/syncode`	1 × `build-image.yml`	1 × `build-image.yml`	agrees
`syncode/workflow`	0	0	agrees
`syncode/runner`	1 × `build-image.yml`	0	`requires exactly one job, got 5`
`syncode/control`	1 × `build-image.yml`	0	`requires exactly one job, got 4`

The two agreements are worth as much as the two failures: fetching files at a commit, parsing, evaluating triggers, filtering branches, compiling, lowering and expanding a matrix all come out right against real repositories. And every divergence there is has one cause — an execution plan holds a single job — which makes it the next thing to fix rather than a guess about where to look.

A run also names the workflow file it was compiled from. One commit can answer one event with several workflows, so without the file there is nothing to tell their runs apart, and nothing to line any of them up against on the forge. An origin that cannot name its file is dropped when the schema is applied, for the same reason an origin-less run is.

Supersedes #17, which built shadow mode into the service. That was the wrong order: it would have measured less, later, and put a new service on production to learn it.

Roadmap step 5, done as a measurement rather than as a deployment. Deciding which runs an event asks for is a function of the workflow files at a commit and the event itself. It needs no database, no node and no deployment, so it is measured here rather than by standing a second control plane beside the forge and waiting for pushes: the runs arise in memory, through the same `trigger` the service uses, and are thrown away once counted. Five repositories in eight seconds, against weeks of waiting for a live shadow to see the same thing. Against the five SynCode repositories: | repository | forge | control | | |---|---|---|---| | `syncode/meta` | 1 × `docs.yml` | 1 × `docs.yml` | agrees | | `syncode/syncode` | 1 × `build-image.yml` | 1 × `build-image.yml` | agrees | | `syncode/workflow` | 0 | 0 | agrees | | `syncode/runner` | 1 × `build-image.yml` | 0 | `requires exactly one job, got 5` | | `syncode/control` | 1 × `build-image.yml` | 0 | `requires exactly one job, got 4` | The two agreements are worth as much as the two failures: fetching files at a commit, parsing, evaluating triggers, filtering branches, compiling, lowering and expanding a matrix all come out right against real repositories. And every divergence there is has one cause — an execution plan holds a single job — which makes it the next thing to fix rather than a guess about where to look. A run also names the workflow file it was compiled from. One commit can answer one event with several workflows, so without the file there is nothing to tell their runs apart, and nothing to line any of them up against on the forge. An origin that cannot name its file is dropped when the schema is applied, for the same reason an origin-less run is. Supersedes #17, which built shadow mode into the service. That was the wrong order: it would have measured less, later, and put a new service on production to learn it.

day01 added 1 commit 2026-08-13 11:17:33 +00:00

feat: measure what this control plane would have run

		Deciding which runs an event asks for is a function of the workflow files at a
commit and the event itself. It needs no database, no node and no deployment,
so it is measured here rather than by standing a second control plane beside
the forge and waiting for pushes to arrive: the runs arise in memory, through
the same `trigger` the service uses, and are thrown away once counted.

Against the five SynCode repositories, three agree with the forge exactly and
two produce nothing at all, both for one reason: an execution plan holds a
single job, and their workflows have four and five. That is now a measurement
rather than a suspicion, and it is the only divergence there is.

A run also names the workflow file it was compiled from. One commit can answer
one event with several workflows, so without the file there is nothing to tell
their runs apart, and nothing to line any of them up against on the forge. An
origin that cannot name its file is dropped when the schema is applied, for the
same reason an origin-less run is.

day01 merged commit 69536407d1 into %!s()

2026-08-13 11:21:30 +00:00

day01 deleted branch feat/measure-what-this-control-plane-would-have-run

2026-08-13 11:21:31 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: syncode/control#18