The job page in the web UI offers four rerun actions. Only two of them have a CLI equivalent:
| Web UI action |
CLI equivalent |
| Rerun workflow from start |
circleci workflow rerun <workflow-id> |
| Rerun workflow from failed |
circleci workflow rerun <workflow-id> --from-failed |
| Rerun failed tests |
none |
| Rerun job with SSH |
none |
This request is about the third one.
Why it matters
Today we do this in the web UI. What we'd like is for the whole triage loop to run through the MCP server that wraps this CLI: an agent can already read the failures (circleci testresult list <job-id> defaults to failures only) and can rerun jobs, but it has no way to act on that read with the narrowest rerun available. The natural next step after "one test failed, here's the error" is "rerun just that test", and it's the one step in the loop that has to happen by hand in a browser.
The nearest CLI option, --from-failed, is job-granular: it re-dispatches each failed job in full. On a suite where one test fails out of 12,546, that means re-running all 12,546 tests — around nine minutes of compute — to re-check a single failure.
Proposed shape
Either a flag on the existing command:
circleci workflow rerun <workflow-id> --failed-tests
or a job-scoped subcommand, which sits closer to where the action lives in the UI:
circleci job rerun <job-id> --failed-tests
Either works for us. The job-scoped form composes more naturally with circleci testresult list <job-id>, which is already addressed by job ID.
Notes
- Version:
1.0.45973-pre.
- I appreciate this isn't a pure control-plane operation the way
--from-failed is — it presumably requires the job to have run its tests through CircleCI's test orchestration. A clear error when a job isn't eligible would be as valuable as the happy path, since from the CLI there's currently no way to tell.
- If this is deliberately UI-only, a note to that effect in
circleci workflow rerun --help would save the next person the search. There's nothing in the help output or the command tree that distinguishes "not built yet" from "not possible here".
The job page in the web UI offers four rerun actions. Only two of them have a CLI equivalent:
circleci workflow rerun <workflow-id>circleci workflow rerun <workflow-id> --from-failedThis request is about the third one.
Why it matters
Today we do this in the web UI. What we'd like is for the whole triage loop to run through the MCP server that wraps this CLI: an agent can already read the failures (
circleci testresult list <job-id>defaults to failures only) and can rerun jobs, but it has no way to act on that read with the narrowest rerun available. The natural next step after "one test failed, here's the error" is "rerun just that test", and it's the one step in the loop that has to happen by hand in a browser.The nearest CLI option,
--from-failed, is job-granular: it re-dispatches each failed job in full. On a suite where one test fails out of 12,546, that means re-running all 12,546 tests — around nine minutes of compute — to re-check a single failure.Proposed shape
Either a flag on the existing command:
or a job-scoped subcommand, which sits closer to where the action lives in the UI:
Either works for us. The job-scoped form composes more naturally with
circleci testresult list <job-id>, which is already addressed by job ID.Notes
1.0.45973-pre.--from-failedis — it presumably requires the job to have run its tests through CircleCI's test orchestration. A clear error when a job isn't eligible would be as valuable as the happy path, since from the CLI there's currently no way to tell.circleci workflow rerun --helpwould save the next person the search. There's nothing in the help output or the command tree that distinguishes "not built yet" from "not possible here".