From 53922e668a8e58a6233c071789dcb162ed1fee32 Mon Sep 17 00:00:00 2001 From: Cameron Reeves Date: Thu, 6 Aug 2026 01:34:18 +1000 Subject: [PATCH] ci(e2e): run the suite on the branches we deploy from MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Stage 2. `push` now covers develop, release/** and rc/** — the same set build.yml deploys from — alongside the existing e2e/** and the nightly. A regression is now caught where it lands, which is when bisecting is cheapest, and since this repo has no pull_request trigger (public repo, self-hosted runner) it is also the only way merges get covered at all. Still advisory, and still structurally unable to block: different runner pool, no cross-workflow needs, not a required status check, and the job name says so. Still not feature branches — one runner binding fixed host ports means runs serialise, and a busy trigger set would starve the nightly. --- .github/workflows/e2e-advisory.yml | 23 +++++++++++++---------- E2E_USER_STORIES.md | 11 +++++------ 2 files changed, 18 insertions(+), 16 deletions(-) diff --git a/.github/workflows/e2e-advisory.yml b/.github/workflows/e2e-advisory.yml index 954a865544..0dfe8aa584 100644 --- a/.github/workflows/e2e-advisory.yml +++ b/.github/workflows/e2e-advisory.yml @@ -31,21 +31,24 @@ on: workflow_dispatch: push: branches: + # The branches `build.yml` deploys from — a regression is caught where + # it lands, which is when bisecting is cheapest. + # + # This still cannot block anything: different runner pool, no + # cross-workflow `needs`, and it is not a required status check. The + # job name says "advisory" so a red X next to the build jobs cannot be + # misread. See E2E_USER_STORIES.md. + - develop + - 'release/**' + - 'rc/**' # For iterating on CI itself. Deliberately outside the `feat/*`, # `fix/*`, `custom/*`, `refactor/*` set PR Flow watches, so this never # triggers a build or a `build//` deploy. - 'e2e/**' # - # STAGE 2 — not yet. Add `develop` (and `release/**`, `rc/**`) once the - # nightly has a track record. Deliberately deferred: `develop` is the - # high-value trigger — it catches a regression where it lands, when - # bisecting is cheapest — but turning it on also puts a new check on - # everyone's commits, and that should be earned rather than assumed. - # Until then `workflow_dispatch` covers any one-off. - # - # It cannot block builds when it is enabled (different runner pool, no - # cross-workflow `needs`, no required status checks on develop) — see - # E2E_USER_STORIES.md. The reason to wait is noise and trust, not risk. + # Still NOT feature branches: there is one self-hosted runner binding + # fixed host ports, so runs serialise. A busy trigger set would build a + # queue that starves the nightly. Use "Run workflow" for a one-off. schedule: # 01:10 UTC daily. NB scheduled workflows only run from the DEFAULT branch, # so the nightly track record does not start accumulating until this file is diff --git a/E2E_USER_STORIES.md b/E2E_USER_STORIES.md index 39fdbf8b02..2d5fa45467 100644 --- a/E2E_USER_STORIES.md +++ b/E2E_USER_STORIES.md @@ -37,12 +37,11 @@ check on their commits, and the nightly starts accumulating the record — which do from the default branch, so this is what breaks the chicken-and-egg of "prove it before merging it". -**Stage 2 (once the record is good):** add `push: develop`, and `release/**` / `rc/**` to -match the branch set `build.yml` deploys from. `develop` is the high-value trigger — it -catches a regression at the moment it lands, when bisecting is cheapest — and with no -`pull_request` trigger it is also how merges get covered. Deferred because enabling it puts -a new check on everyone's commits, which should be earned rather than assumed. It is a -three-line change. +**Stage 2 (done 2026-08-06):** `push` now covers `develop`, `release/**` and `rc/**` — +the branch set `build.yml` deploys from. `develop` is the high-value trigger: it catches a +regression at the moment it lands, when bisecting is cheapest, and with no `pull_request` +trigger it is also how merges get covered. It still cannot block anything, and the suite had +run green on every invocation up to that point. **Never:** feature branches. There is one self-hosted runner and the stack binds fixed host ports, so runs serialise; a busy trigger set would build a queue that delays or starves the