feat(cli): deploy area --id <areaId> [--force] bulk-deploys an area subtree with deploy site's deadline and exit-code contract (Gitea #40)

This commit is contained in:
Joseph Doherty
2026-10-22 14:12:46 -04:00
parent f72c72c52f
commit 74d5fba2b0
5 changed files with 165 additions and 3 deletions
+20 -1
View File
@@ -1101,6 +1101,25 @@ Output is a per-instance result matrix (`instanceId`, `uniqueName`, `deploymentI
`success`, `errorMessage`) plus `successCount` / `failureCount`, and `skippedInstances`
(`instanceId`, `uniqueName`, `reason`).
#### `deploy area`
Deploy every deployable instance in one **area subtree** — the area itself plus every
area nested beneath it at any depth (Gitea #40). It is `deploy site` narrowed to that
subtree, with identical rules: Disabled instances are always skipped, up-to-date ones
are skipped unless `--force`, the batch is not all-or-nothing, and the output is the
same summary (`siteIdentifier` is the area's site). Instances with no area are only
reachable through `deploy site`. Same deadline policy as `deploy site`, and the same
exit-code rule: `1` when any instance failed (or the summary is invalid), else `0`.
```sh
scadabridge --url <url> deploy area --id <areaId> [--force]
```
| Option | Required | Description |
|--------|----------|-------------|
| `--id` | yes | Area ID. A site-scoped (non-Administrator) Deployer must name an area of an in-scope site; an unknown area is denied to them exactly like an out-of-scope one. |
| `--force` | no | Redeploy instances whose config is unchanged (default: skip them). Disabled instances are still skipped. |
#### `deploy artifacts`
Deploy compiled artifacts to one or all sites (same as `site deploy-artifacts`).
@@ -2665,7 +2684,7 @@ run's outbound API / DB / notification rows, which are always audited.
## Deployment deadlines
`deploy instance`, `instance deploy`, `deploy artifacts`, `site deploy-artifacts`,
and `deploy site` defer the overall deadline to the Management API. They keep the
`deploy site` and `deploy area` defer the overall deadline to the Management API. They keep the
bounded socket-connect timeout but do not impose the ordinary 30-second client
request deadline on a deployment that may still be applying. The API's configured
long-running timeout remains authoritative. Ordinary commands retain a 30-second