Home

reenact

Drop into a shell at the exact step where your CI run failed.

reenact https://github.com/owner/repo/actions/runs/123/job/456

That URL is the one in your browser when you look at a failed job. reenact reads the run from the GitHub API, works out the exact commit, matrix leg, runner image and event payload, generates a temporary workflow that stops right before the failing step, hands it to act, and drops you into the container.

  Job         Ensure 'cargo clippy' has no warnings
  Failing     step 3/3 — "Run cargo clippy --all-targets --all-features -- -Dwarnings"
  Plan        2 step(s) will run, then a shell opens before:
              Run cargo clippy --all-targets --all-features -- -Dwarnings
  Fidelity    ✓ 3 check(s), nothing that should change behaviour

  cloning ca51233 from github.com/sharkdp/fd
  1/2  dtolnay/rust-toolchain@stable
  2/2  actions/checkout@v7.0.1
  breakpoint reached in 13s

root@runner:/…/repo$ bash /tmp/reenact-failing-step.sh
error: could not compile `fd-find` (test "tests") due to 14 previous errors

The point is the loop: instead of push → wait ten minutes → guess → push again, you try a fix in the container in two seconds and push once.

Pages

• Installation — gh extension, single binary, or from source
• How it works — the five stages and why the resolver runs nothing
• The fidelity report — what each finding means and how worried to be
• Scope and limits — what it refuses to do, and why that is the point
• Troubleshooting — the errors you are most likely to hit
• Measuring instead of guessing — the probes, and how to re-run them

Is this for you?

Yes, if you push to GitHub Actions, your Linux jobs fail regularly, and you spend real time waiting for CI to tell you what you already suspect.

No, if your jobs are macOS or Windows — those cannot be reproduced in a Linux container and reenact says so instead of pretending. Measured on 243 real failed jobs, that is 23% of them.