feat(ci): close PMS-141 - promote E2E to merge gate on PRs to main #111

Merged

nrupard merged 1 commit from feat/pms-141-e2e-merge-gate into main

2026-06-05 19:15:09 +02:00

nrupard commented

2026-06-05 19:12:04 +02:00

Owner

Closes PMS-141.

What

PMS-140 shipped the post-merge informational E2E run. PMS-141 promotes the suite to a merge gate: every PR targeting main (feature PRs and release/* PRs alike) now triggers the E2E run, in addition to the existing post-merge run and a new manual workflow_dispatch.

Triggers + pre-flight gates

Trigger	Purpose	Pre-flight
`push` to `main` (post-merge validation)	Verify the deployed commit is actually serving	`scripts/wait-for-deploy.mjs` polls `/api/v1/version` until the pushed SHA appears (10-min budget)
`pull_request` to `main` (merge gate)	Block merge on a red suite against staging	`scripts/health-check.mjs` one-shot `GET /api/v1/health` (30s timeout) - a PR SHA never deploys to staging, so a version gate would always time out
`workflow_dispatch`	Manual ad-hoc runs	Treated like `push`

Concurrency

Single e2e-staging group, cancel-in-progress: false. Every commit (post-merge + every PR) gets exercised once it reaches the queue. Trade-off: slower throughput, but the per-email login rate limit (5/min, src/modules/auth/routes.rs) is never contested by parallel runs, which would 429 the SPA login mid-suite.

Out of scope (operator step)

Flipping e2e to a required status check on the main branch protection settings in Forgejo is what actually makes the gate enforceable. PMS-141's spec calls for ~10 consecutive green post-merge runs before flipping that switch; revisit the threshold once observed flakiness data backs or revises the assumption.

Test plan

This PR's own run hits the new pull_request path: setup-node + Playwright + scripts/health-check.mjs + the suite. (The PR-mode pre-flight runs against whatever staging is currently serving, since this PR's SHA is not deployed.)
Confirm Wait for staging to serve this commit step is SKIPPED (post-merge-only).
After merge, the post-merge push run uses wait-for-deploy.mjs (deploy-sync gate) as before.
Operator: enable e2e as a required status check on main branch protection once stability bar is met.

Closes PMS-141. ## What PMS-140 shipped the post-merge informational E2E run. PMS-141 promotes the suite to a merge gate: every PR targeting `main` (feature PRs and `release/*` PRs alike) now triggers the E2E run, in addition to the existing post-merge run and a new manual `workflow_dispatch`. ## Triggers + pre-flight gates | Trigger | Purpose | Pre-flight | | --- | --- | --- | | `push` to `main` (post-merge validation) | Verify the deployed commit is actually serving | `scripts/wait-for-deploy.mjs` polls `/api/v1/version` until the pushed SHA appears (10-min budget) | | `pull_request` to `main` (merge gate) | Block merge on a red suite against staging | `scripts/health-check.mjs` one-shot `GET /api/v1/health` (30s timeout) - a PR SHA never deploys to staging, so a version gate would always time out | | `workflow_dispatch` | Manual ad-hoc runs | Treated like `push` | ## Concurrency Single `e2e-staging` group, `cancel-in-progress: false`. Every commit (post-merge + every PR) gets exercised once it reaches the queue. Trade-off: slower throughput, but the per-email login rate limit (5/min, `src/modules/auth/routes.rs`) is never contested by parallel runs, which would 429 the SPA login mid-suite. ## Out of scope (operator step) Flipping `e2e` to a required status check on the `main` branch protection settings in Forgejo is what actually makes the gate enforceable. PMS-141's spec calls for ~10 consecutive green post-merge runs before flipping that switch; revisit the threshold once observed flakiness data backs or revises the assumption. ## Test plan - [ ] This PR's own run hits the new `pull_request` path: setup-node + Playwright + `scripts/health-check.mjs` + the suite. (The PR-mode pre-flight runs against whatever staging is currently serving, since this PR's SHA is not deployed.) - [ ] Confirm `Wait for staging to serve this commit` step is SKIPPED (post-merge-only). - [ ] After merge, the post-merge `push` run uses `wait-for-deploy.mjs` (deploy-sync gate) as before. - [ ] Operator: enable `e2e` as a required status check on `main` branch protection once stability bar is met.

nrupard added 1 commit

2026-06-05 19:12:04 +02:00

feat(ci): close PMS-141 - promote E2E suite to merge gate on PRs to main

E2E (staging) / Playwright against staging (pull_request) Successful in 1m5s

Details

Check / fmt + clippy + compile + tests (pull_request) Successful in 2m16s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

ae3502899d

PMS-140 shipped the post-merge informational run. PMS-141 promotes the suite to a merge gate: every PR targeting main (feature PRs and release/* PRs alike) now triggers the E2E run, in addition to the existing post-merge run and a new manual workflow_dispatch.

The two trigger types serve different purposes and therefore use different pre-flight gates:

- push to main (post-merge validation): the existing wait-for-deploy.mjs polls /api/v1/version until staging reports the pushed commit. Verifies the deployed commit, not just "some commit".
- pull_request to main (merge gate): a PR's SHA never deploys to staging, so the version gate would always time out. Replace with a one-shot GET /api/v1/health reachability check (`scripts/health-check.mjs`, 30s timeout, reuses the same SPA-host -> API-host derivation as wait-for-deploy). The semantics is "staging is healthy and the suite passes against it", which is the right semantics for a staging-target suite.
- workflow_dispatch (manual): treated like push.

Concurrency stays a single `e2e-staging` group with cancel-in-progress: false. Every commit (post-merge or PR) gets exercised, and the per-email login rate limit (5/min, src/modules/auth/routes.rs) is never contested by parallel runs. Throughput trade-off accepted.

The branch-protection switch to actually enforce the gate is an operator step in Forgejo, not a workflow change. PMS-141's spec calls for ~10 consecutive green post-merge runs before flipping it; revisit that threshold once observed flakiness data backs or revises the assumption.

README CI section rewritten to spell out the trigger split + pre-flight gate per trigger.

#PMS-141