fix: expose server deployment trigger
This commit is contained in:
+21
@@ -0,0 +1,21 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Deployable server details expose an explicit deployment trigger
|
||||
The management console SHALL expose an authorized Deploy action for a server in `draft` or `failed` state when a deployment definition is present. The control MUST remain unavailable for non-deployable states and while an installation action is pending.
|
||||
|
||||
#### Scenario: Retry a failed server after its dedicated Run registers
|
||||
- **WHEN** an operator opens a failed SCUM server whose dedicated Run endpoint is online
|
||||
- **THEN** the detail actions expose a Retry deploy control
|
||||
- **AND** the control is distinct from Start and does not expose protected deployment inputs
|
||||
|
||||
#### Scenario: Active installation does not offer a duplicate trigger
|
||||
- **WHEN** a server is in `installing` state or its deployment operation is pending
|
||||
- **THEN** the console does not allow another deployment submission
|
||||
|
||||
### Requirement: Deployment trigger uses the existing fenced lifecycle dispatch
|
||||
The management console SHALL submit deployment through the existing server deployment API with the instance's current config version and an idempotency key, then refresh the server detail after acceptance or failure.
|
||||
|
||||
#### Scenario: Deployment is accepted
|
||||
- **WHEN** the operator activates Deploy for an eligible server
|
||||
- **THEN** the console submits the current expected config version and a unique idempotency key to the existing deployment API
|
||||
- **AND** it reports the queued job through the standard operation feedback and refreshes the detail state
|
||||
Reference in New Issue
Block a user