The problem
The strong approval ceremony — the typed confirmation guarding a destructive
or migration job — has no end-to-end coverage.
The only job run in the e2e suite is chore, which declares
data_effect: none (e2e/testdata/postgres/ob.yml.tmpl:37-42), driven with
y\n (e2e/server_test.go:397-400). That is the one-time class, not the
strong one. The unit test added in #171 covers ob approve --plan, and nothing
covers ob job run --plan or the inline ob job run <id> prompt against a
real binary.
Two e2e helpers still encode the pre-#171 rule and describe it as general:
e2e/apps/one-app-one-host.sh:54-63 — approval_answer supplies the release
ID when the class is strong.
e2e/server_harness_test.go:385-400 — releaseIDRe extracts a release ID to
feed the prompt.
Both are reached only from deploy helpers today, so nothing is broken. But a
destructive job added to the fixture later would fail confusingly against a
helper that looks like it handles the strong class in general.
Proposed change
Add a destructive manual job to an e2e fixture and drive the strong ceremony
against the real binary: the wrong token refused, the job name accepted, and
the summary naming the job. Then make the two helpers say which class they
handle, or teach them the job case.
Scope and safety
Test-only. No product change.
Found while auditing #171.
The problem
The strong approval ceremony — the typed confirmation guarding a
destructiveor
migrationjob — has no end-to-end coverage.The only job run in the e2e suite is
chore, which declaresdata_effect: none(e2e/testdata/postgres/ob.yml.tmpl:37-42), driven withy\n(e2e/server_test.go:397-400). That is the one-time class, not thestrong one. The unit test added in #171 covers
ob approve --plan, and nothingcovers
ob job run --planor the inlineob job run <id>prompt against areal binary.
Two e2e helpers still encode the pre-#171 rule and describe it as general:
e2e/apps/one-app-one-host.sh:54-63—approval_answersupplies the releaseID when the class is strong.
e2e/server_harness_test.go:385-400—releaseIDReextracts a release ID tofeed the prompt.
Both are reached only from deploy helpers today, so nothing is broken. But a
destructive job added to the fixture later would fail confusingly against a
helper that looks like it handles the strong class in general.
Proposed change
Add a
destructivemanual job to an e2e fixture and drive the strong ceremonyagainst the real binary: the wrong token refused, the job name accepted, and
the summary naming the job. Then make the two helpers say which class they
handle, or teach them the job case.
Scope and safety
Test-only. No product change.
Found while auditing #171.