Re-run a job

Goal

A job that already ran, run again — as a new numbered run under the same name, with its earlier runs kept.

Before you start

• A job that exists and has finished. A run started while another is in flight is a different question, answered by the schedule’s concurrency policy.
• If you are re-running with a changed image, the same rules as a create apply: the request is a full re-specification of the job, not a patch.

Dashboard

Steps

1. Open Jobs and select the job.
2. Choose Run again.
3. Watch the new run appear in the history with the next run number.

REST API

Steps

1. GET /api/v1/jobs/{name}/runs to see the runs already recorded.
2. POST /api/v1/jobs/{name}/runs to start another. An empty body re-runs the job as stored.
3. GET /api/v1/jobs/{name} for the job’s current state.

CLI

Steps

1. There is no CLI re-run command; use the API or the dashboard.
2. odysseus status and odysseus logs show what a run did.

Verify

A new run number appears in the job’s history, and the earlier runs are still listed.

Evidence this worked

The runs list gains one entry rather than replacing the previous one, and the run number increments. A history that resets to run one means a new job was created rather than the existing one re-run.

When it fails

• A body without an image is refused. A run body is a full re-specification of the job, so it needs an image just like a create would — send no body at all to re-run it as stored.
• The run is refused while another is in flight. That is the concurrency policy doing its job; see scheduled work.
• Old runs are missing. The retention limit kept the most recent ones. It is a field you set.
• Every code: rejections and alterations.