Move collection launch progress and history into Collections

Fixes #52
This commit is contained in:
2026-09-28 10:10:09 -04:00
parent 2fa3792482
commit 905d1aa3f6
12 changed files with 166 additions and 48 deletions
+11 -4
View File
@@ -1,6 +1,8 @@
# Deployment collections
Open **Operations → Collections** to manage reusable server lineups. A
Open **Operations → Collections** to manage reusable server lineups. Use
**Active launches** to follow progress and **Launch history** to review completed
launches and failures. Both views refresh automatically. A
collection describes a whole lineup: for example, two Kino lobbies, one Moon lobby,
and two Town lobbies. Counts are desired fleet totals: existing and queued
servers count toward each target, and only missing servers are created.
@@ -105,11 +107,13 @@ A lost startup response also keeps the slot because the container may already be
running. A confirmed creation failure is recorded for review, allowing later
queued servers to proceed on subsequent passes without undoing successful launches.
The collection page separates ready, launching, queued, and failed servers. It
The collection launch page at `/collections/launches/:id` separates ready,
launching, queued, and failed servers. Its breadcrumb returns to Collections. It
highlights the current startup, shows each waiting server's queue position, and
links to earlier launches when another collection occupies the available capacity.
Every server links to its operation timeline and recovery options, and each child
operation links back to its collection.
Every server links to its Provisioning operation timeline and recovery options,
and each child operation links back to its collection launch. Individual operations
remain visible in Provisioning activity and history.
## Create and review a launch
@@ -204,6 +208,9 @@ repeats container creation or deployment as part of this recovery.
Collections retain the existing `/api/blueprints` endpoints and `blueprintId` /
`blueprintName` fields for compatibility. Saved data needs no migration. Old
`/provisioning?view=blueprints` links redirect to `/collections`.
Collection launch details live at `/collections/launches/:id`; old
`/provisioning/collections/:id` and `/deployments/collections/:id` links redirect
there while preserving query parameters.
- `GET /api/blueprints`: list lineup summaries with game/map selections and counts.
- `POST /api/blueprints`: save `{ name, description?, previewId }` or
+9 -4
View File
@@ -1,7 +1,9 @@
# Provisioning
Open **Operations → Provisioning** for instance lifecycle work, blueprints, and
persistent activity. Provisioning owns the queues, safety checks, execution, and
Open **Operations → Provisioning** for instance lifecycle work and persistent
activity. **Operations → Collections** owns reusable lineups and collection launch
progress; their individual operations remain visible in Provisioning.
Provisioning owns the queues, safety checks, execution, and
recovery for all six actions. Create a server using **Create server**. For an existing
server, choose **Manage server** or open its **Server actions** menu.
@@ -75,9 +77,10 @@ requester closes. Upgrades adopt existing restart intent for observation only.
## Routes and compatibility
- `/provisioning`: active operations, blueprints, and history filtered by action.
- `/provisioning`: active operations and history filtered by action.
- `/provisioning/:id`: operation stages, errors, timestamps, and activity.
- `/provisioning/collections/:id`: collection progress.
- `/collections`: saved lineups, active launches, and launch history.
- `/collections/launches/:id`: collection progress, with links to each operation.
- `GET /api/provisioning`: lifecycle history (`deployments` response property).
- `POST /api/provisioning`: queue `{ "server": "t5_zombie_theater_1", "action": "start" }`.
Supported actions are `start`, `restart`, `rebuild`, and `stop`. Returns HTTP 202
@@ -88,6 +91,8 @@ requester closes. Upgrades adopt existing restart intent for observation only.
launch preview, and fleet destruction APIs.
Old `/deployments` pages redirect to their `/provisioning` equivalents, preserving
query parameters. Collection launch links at `/provisioning/collections/:id` or
`/deployments/collections/:id` redirect to `/collections/launches/:id` and preserve
query parameters. `/api/deployments` remains compatible, including old campaign
detail endpoints. No history or IDs are renamed or discarded.