Execution
CI providers and experiments
Compare providers safely and promote a successful per-job route.Two composed layers
The CI-provider layer chooses and observes execution targets. It does not reserve a Mac or boot a VM. When provider ID mirage selects Local Mac, the job enters the same fleet scheduler used by an ordinary mirage-* workflow.
CI-provider controlAdapt · dispatch · compare · promote
Local Mac backendValidate · reserve · boot · replay
Provider catalog
| ID | Display name | Experiments | Promotable |
|---|---|---|---|
github | GitHub Actions | All supported profiles | Yes |
mirage | Local Mac | All supported profiles | Yes |
cloudflare | Cloudflare Runners | Linux x64 | No, adapter v1 |
Adapt a job
In Settings, inspect a private repository and select eligible build or test jobs.
- Mirage opens a dedicated onboarding pull request.
- The job is extracted into a guarded reusable workflow.
- The original job becomes a caller controlled by
MIRAGE_JOB_ROUTES. - You review, merge, and activate the exact adapter fingerprint.
Run an experiment
Open a completed adapted job and choose Experiment. Mirage dispatches a separate reusable workflow at the source job's immutable SHA for every selected provider.
- Experiments have their own GitHub workflow run and provider-owned output.
- Queue, startup, execution, conclusion, and infrastructure failure are normalized.
- The source run is never cancelled, replayed, or gated by an experiment.
Promote a successful route
After a supported provider completes successfully, promote it from the comparison. Mirage writes a versioned per-job route and keeps the previous default as fallback.