A test platform that lives in a browser tab gets used for a fortnight. A test platform wired into the pipeline gets used forever. Here is the shape of that integration, end to end.
One token, scoped correctly
Create an API token of kind runner or mcp depending on the caller, store it as a repository secret, and never reuse a personal session token in CI. Tokens are organisation-scoped, hashed at rest, and revocable independently, so rotating one pipeline's credential never disturbs another.
Trigger, poll, gate
The action posts to the run trigger endpoint with the project and an optional scenario selection, receives a run reference such as RUN-000123, then polls until the batch closes. Exit non-zero on failures and the pull request is blocked; exit zero and the job attaches the report URL as a check annotation.
Choose what to run per event
Pull requests usually run a fast subset: smoke journeys plus anything touching the changed area. Merges to main run the full set across browsers and viewports. Nightly jobs run the full set plus a regeneration pass so new coverage is proposed while nobody is waiting on it.
Concurrency without credential sprawl
The on-prem Runner executes scenarios in a worker pool with an isolated browser context per worker. Secrets are resolved inside each sandbox and never written to the shared filesystem, so raising concurrency raises throughput without widening the blast radius.
The audit trail is the deliverable
Each CI run produces an immutable attempt: sealed metrics, per-step telemetry, traces, video, and the agent version used. Months later you can answer 'what exactly did we verify before shipping that release?' with a link rather than a guess.