Skip to documentation
MMirageDocs

Route jobs

Compare CI providers

Try an existing build or test job on another provider before changing where it normally runs.

Use provider comparisons to decide where a job should run. Keep its current GitHub-hosted default while you evaluate the same job on GitHub, local infrastructure, or Cloudflare. Compare the results and timings, then promote a supported provider through a reviewed pull request.

Each experiment runs an extra copy of a completed job on the same commit. The original run and its required checks remain unchanged. Routing and providers explains how comparisons, defaults, and fallback fit together.

Choose a job

Start with a standalone build or test job using a supported, static GitHub-hosted runner label. The repository must have local-infrastructure routing enabled in Mirage. Set up an available machine or Cloudflare account for the provider you want to try.

Job discovery checks whether Mirage can safely copy the job into an independent workflow. Current exclusions include matrix jobs, jobs with needs or outputs, jobs that already call reusable workflows, deployment and environment jobs, and workflows with a manual workflow_dispatch trigger. Event-dependent expressions can also make a job ineligible. Discovery explains the reason per job.

This is an optional setup path for existing GitHub-hosted jobs. A job already using the attempt expression from Configure workflows is not eligible for this onboarding flow. Use a separate eligible job or restore its static GitHub-hosted label before onboarding it.

Prepare the workflow

  1. Open Settings and find Per-job routes and experiments.
  2. Select Discover jobs for your repository.
  3. Select eligible build or test jobs and choose Onboard selected (the button shows the selected count).
  4. Open the generated pull request from the job’s settings row, review the workflow changes, and merge it in GitHub.
  5. Wait until Mirage shows the configuration as applied, then let the updated workflow complete a normal run.

The pull request moves the selected job’s steps into a reusable workflow and adds the comparison controls. The original GitHub-hosted runner remains the default until you choose and merge a provider change.

Compare providers

  1. In Runs, open a completed job that has finished onboarding.
  2. Select Experiment, choose the available providers, and launch the comparison.
  3. Compare each provider’s result and available capacity-wait, startup, and execution timings. Follow the GitHub links for full logs.

Experiments use the source job’s commit, so a newer push does not change what is being compared. They consume runner capacity and any applicable provider usage. An unavailable provider or a failed experiment does not cancel the source run or other providers in the comparison.

Only compare jobs whose steps are safe to run again. An experiment executes your code again even though its result does not gate the source pipeline.

Change the default

When a supported provider succeeds, select Promote in the comparison. Mirage opens a pull request to change the job’s runner selection. Review and merge that PR, then check Settings for the applied default and fallback before relying on the new route.

A comparison alone does not change future jobs. Cloudflare is currently available only for experiments in this flow, so it has no promotion action. To use it directly, configure an explicit Cloudflare workflow.