fix(e2e): correct stale provisioning docs + cli.rs drift, skip suite when staging unseeded #446
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/PMS-656-e2e-provisioning-cleanups"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
Three E2E-provisioning cleanups (PMS-656), surfaced while re-provisioning the shared E2E account after a staging data wipe.
1. Stale docs (docs/e2e.md, e2e/README.md)
Both instructed the operator to elevate the E2E account with
UPDATE users SET role = 'admin'because "first SSO login JIT-creates the row as technician". Not true since MAPPS-330:place_bunyip_user(src/modules/auth/middleware.rs) JIT-creates the shadow row asadminin an auto-provisioned personal tenant, andeffective_role_from_bunyipfloors every bunyip role to mokosh admin. Rewrote the provisioning steps to describe the bunyip-provisioned account (just e2e-bootstrap), the automatic JIT-admin + personal tenant, and re-capturingE2E_TENANT_IDafter a re-seed. The "everything admin-gated returns 403 -> elevate" troubleshooting entry is rewritten as no-longer-applicable.2. cli.rs drift
src/cli.rsclaimed themokosh-bootstrapbinary was "removed in PMS-493", butsrc/bin/mokosh-bootstrap.rsstill exists and drivesbootstrap-infisical. Corrected to say PMS-494 folded the subcommands into the main binary while the standalone binary remains (per the issue's YAGNI call: fix the comment, do not delete a working binary).3. CI readiness gate
After a wipe the suite hard-failed opaquely at login (the incident that prompted this).
e2e.ymlnow probes bunyip'sGET /e2e-bootstrapped(e2e/scripts/check-e2e-bootstrapped.mjs) before running; on an explicit{bootstrapped:false}it setsskip=trueso the suite is skipped with a notice pointing at the re-seed recipe and the job stays green, mirroring bunyip's own CI. Fail-open: a missing endpoint (production never enables it), a non-2xx, a parse error, or any network error all run the suite - the gate can only hide the known "staging not seeded" case, never a real failure.Testing
just pre-commitgreen (the only code change is thecli.rsdoc comment).node --checkon the new gate script;e2e.ymlparses and the gate is wired (Check staging is E2E-seeded->Run E2E suitegated onsteps.seeded.outputs.skip != 'true').#PMS-656
Three E2E-provisioning cleanups surfaced while re-provisioning the shared account after a staging wipe. Docs were stale: docs/e2e.md and e2e/README.md instructed the operator to elevate the E2E account with `UPDATE users SET role = 'admin'` because "first SSO login JIT-creates the row as technician". That has not been true since MAPPS-330: `place_bunyip_user` (src/modules/auth/middleware.rs) JIT-creates the shadow row as `admin` in an auto-provisioned personal tenant, and `effective_role_from_bunyip` floors every bunyip role to mokosh admin. Both docs now describe the bunyip-provisioned account (`just e2e-bootstrap`), the automatic JIT-admin + personal tenant, and re-capturing E2E_TENANT_ID after a re-seed; the "everything admin-gated returns 403 -> elevate" troubleshooting entry is rewritten as no-longer-applicable. src/cli.rs claimed the `mokosh-bootstrap` binary was "removed in PMS-493", but src/bin/mokosh-bootstrap.rs still exists and drives `bootstrap-infisical`. Corrected to say PMS-494 folded the subcommands into the main binary while the standalone binary remains. CI had no readiness gate: after a wipe the suite hard-failed opaquely at login (this incident). e2e.yml now probes bunyip's GET /e2e-bootstrapped (e2e/scripts/check-e2e-bootstrapped.mjs) before running; on an explicit {bootstrapped:false} it skips the suite with a notice pointing at the re-seed recipe and the job stays green, mirroring bunyip's own CI. Fail-open: a missing endpoint (production) or any probe error runs the suite, so the gate can only hide the known "staging not seeded" case, never a real failure. #PMS-656