---

date: 2026-06-10 tags: [ci, github-actions, self-hosted-runner, workflow-dispatch, web-env] status: active graduated_to:

workflow_dispatch must live on the default branch to run the gate on any branch without a PR

Symptom — browser tests (pest-plugin-browser) can't run in the web sandbox (composer plugins disabled — see [[2026-06-06-pest-browser-needs-composer-plugins]]), only on the self-hosted runner. Iterating them via a PR-per-change is a slow loop and (before the self-hosted runner) burned Actions minutes.

Root cause — GitHub only exposes the manual / API workflow_dispatch trigger for a workflow whose definition exists on the default branch. A workflow_dispatch: added only on a feature branch is not dispatchable.

Fix — add workflow_dispatch: to the gate workflows on main first (merged in #369). Then dispatch the gate against any ref — MCP actions_run_trigger { method: run_workflow, workflow_id: 'frontend.yml', ref: '<branch>' } (or the Actions UI "Run workflow") — and the self-hosted runner checks out that branch and runs it, no PR required. The changes path-filter is dispatch-safe: on a manual run github.event.before is empty, so it hits the "base commit unavailable → run the jobs" guard and the gated jobs execute. Read results with the MCP list_workflow_jobs / get_job_logs, or the $GH_TOKEN poll loop ([[2026-06-07-ci-success-gap-gh-token-poll]]).

Guard — the workflow_dispatch: triggers on the tests / frontend / lint workflows + this learning. The technique: validate a feature branch fully on the self-hosted runner before its PR exists, so the PR opens green.