fix: expose server deployment trigger
This commit is contained in:
@@ -0,0 +1,24 @@
|
||||
## Why
|
||||
|
||||
The dedicated SCUM Run can register successfully, but a failed or draft server has no visible Platform action that submits its existing deployment definition. Operators therefore see an idle Run startup log and cannot advance the installation workflow.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Add an explicit Deploy / Retry deploy control to the server detail actions for draft and failed servers.
|
||||
- Submit the existing protected deployment definition through the existing authenticated deployment API, using the current config version and a fresh idempotency key.
|
||||
- Present the queued deployment result in the normal operation feedback and refresh the server/job view.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
- `server-deployment-trigger`: Operator-facing dispatch of an already-configured draft or failed server deployment after its dedicated Run registers.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- None.
|
||||
|
||||
## Impact
|
||||
|
||||
- Affects `platform_web/pages/ServerDetailPage.tsx` and its focused UI tests.
|
||||
- Reuses the existing `POST /api/v1/server-instances/{id}/deploy` contract; no new server API, remote access, credentials, or host data are introduced.
|
||||
Reference in New Issue
Block a user