fix(train)!: propose-change proposes only; retire its merge half (R11) #2040

Merged
pipeline-bot merged 1 commit from fix/r11-propose-only into trunk 2026-08-13 18:13:58 +00:00
Owner

Completes the fleet flip. Every project is release-gated, so the Release act owns merging — pipeline-propose-change arming the provider auto-merge would merge a change while the train was still deciding what the release carries.

The merge call is deleted, not bypassed. That workflow holds a merge-capable token; an unreachable merge path is still a merge path, one project CR back to continuous away from re-arming. mergeMode now defaults to propose-only and auto is a loud tombstone naming the train — silently downgrading an auto request to a proposal would be worse than the bug it replaces, because the caller would believe its change lands on its own while nothing merges it. A project left on continuous fails loudly at its machine PR (recoverable); a change that quietly disappears is not.

image-automation-consumer is re-pointed in the same commit per R11, and now asserts the absence of merge_when_checks_succeed and the merge POST, plus the tombstone and the new default. Verified red: re-adding the merge payload fails it.

Also deletes both stale VERSION files. This project is versionSource.kind: none — the control plane owns versions, from tags — and nothing reads them. The retired devbump cycle left them at 0.1.337-dev / 0.1.88-dev while shipping past v0.1.640, so their only reader was a human being told a number 300 releases stale.

Doc corrections: pipectl is 644 lines (not 654); the glob pipeline-promote-* matches three templates (not four). R11 marked DONE in the phase table with the reason all projects switched at once rather than one at a time.

129/129 guards, go build clean, render/query/dashboard/releaseapi tests pass.

This release will also be the first to write evidence natively to pkg/evidence/ — v0.1.641 deployed that change but ran the old template itself.

Completes the fleet flip. Every project is release-gated, so the Release act owns merging — `pipeline-propose-change` arming the provider auto-merge would merge a change while the train was still deciding what the release carries. **The merge call is deleted, not bypassed.** That workflow holds a merge-capable token; an unreachable merge path is still a merge path, one project CR back to `continuous` away from re-arming. `mergeMode` now defaults to `propose-only` and `auto` is a **loud tombstone** naming the train — silently downgrading an auto request to a proposal would be worse than the bug it replaces, because the caller would believe its change lands on its own while nothing merges it. A project left on `continuous` fails loudly at its machine PR (recoverable); a change that quietly disappears is not. `image-automation-consumer` is re-pointed in the same commit per R11, and now asserts the **absence** of `merge_when_checks_succeed` and the merge POST, plus the tombstone and the new default. Verified red: re-adding the merge payload fails it. **Also deletes both stale VERSION files.** This project is `versionSource.kind: none` — the control plane owns versions, from tags — and nothing reads them. The retired devbump cycle left them at `0.1.337-dev` / `0.1.88-dev` while shipping past v0.1.640, so their only reader was a human being told a number 300 releases stale. Doc corrections: pipectl is 644 lines (not 654); the glob `pipeline-promote-*` matches three templates (not four). R11 marked DONE in the phase table with the reason all projects switched at once rather than one at a time. 129/129 guards, `go build` clean, render/query/dashboard/releaseapi tests pass. This release will also be the **first to write evidence natively to `pkg/evidence/`** — v0.1.641 deployed that change but ran the old template itself.
fix(train)!: propose-change proposes only; retire its merge half (R11)
All checks were successful
pipeline/ci CI green @ fed5e8710acc
fed5e8710a
Every project is release-gated, so the Release act owns merging: the train
merges each green change through pipeline-integrate-rebase and
pipeline-integrate-merge. pipeline-propose-change arming the provider's
auto-merge would merge a change while the train was still deciding what the
release carries — the exact race the train exists to remove.

The merge call is DELETED, not merely bypassed. That workflow holds a token
that can merge, and an unreachable merge path is still a merge path: one
project CR set back to integrationMode: continuous would have re-armed it.

mergeMode now defaults to propose-only, and `auto` is a tombstone that
refuses naming the train. Silently downgrading an auto request to a proposal
would be worse than the bug it replaced — the caller would believe its change
lands on its own while nothing merges it. A project left on continuous
therefore fails loudly at its machine pull request, which is recoverable; a
change that quietly disappears is not.

image-automation-consumer is re-pointed in this same commit, per R11. It now
asserts the ABSENCE of merge_when_checks_succeed and of the merge POST, plus
the tombstone and the propose-only default. Verified red: re-adding the
merge payload fails the guard.

Also deletes both stale VERSION files. This project is
`versionSource.kind: none` — the control plane owns its version, from tags —
and nothing reads them. The retired auto-release devbump cycle left them at
0.1.337-dev and 0.1.88-dev while the project shipped past v0.1.640, so their
only reader was a human, told a number 300 releases stale. Closes the last
alias-set item but one in the overhaul ledger.

Doc corrections in passing: pipectl is 644 lines (not 654), and the literal
glob `pipeline-promote-*` matches three templates (not four).
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
sean/pipelines!2040
No description provided.