[ManuelGerding]

Ticket: https://steadybitgmbh.kanbanize.com/ctrl_board/2/cards/11244
Platform: https://github.com/steadybit/platform/pull/2157

What

The platform can now run an experiment again while a run of it is in progress, as an explicit opt-in: allowRunningAgain together with an Idempotency-Key on every API run endpoint, and a schedule setting of the same name. This covers both in the CLI.

• experiment run --run-again starts another run of an experiment that is already running. Without it, nothing changes: the platform returns the run in progress and the CLI follows it, as before.
  • Works for -k, -f (with and without a key) and --template, the three run endpoints.
  • Each run started sends its own Idempotency-Key (a UUID), kept across the validation and busy retries of that run, so a retried request never starts a second run. A run started again by --expectation-retries gets a new key.
  • The key is only sent with --run-again, the one case the platform requires it.
• schedule create / schedule update take --run-again / --no-run-again (unset leaves an update alone, like --allow-parallel). schedule list shows a "Run again" column, and gitops treats a missing allowRunningAgain as false, as the platform does.

Spec

No spec change in this PR: the production platform (2.8.10) already ships steadybit/platform#2157 and steadybit/platform#2190, and the spec refreshed for v6.3.0 already has allowRunningAgain, Idempotency-Key and the schedule property. A fresh go run ./internal/tools/spec fetch from production matches the committed spec.

Changelog

The entries sit under Unreleased; the version is set when the release is cut.

Tests

• experiment: no flag and no key without --run-again; with it, the same key across the retries of one run, and a new key for a run started again by --expectation-retries.
• schedule: creating a schedule that runs again sends allowRunningAgain.
• go test ./..., go vet ./... and go run ./internal/tools/spec coverage pass.

🤖 Generated with Claude Code