You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
No e2e coverage for the strong approval ceremony on a destructive job #178
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.
Activity
fix(approve): say what a failed confirmation expected, and correct tw…
fix(approve): correct the typed-confirmation contract and refuse an u…