1.9 KiB
Stage 2 Deploy And Observe
bin/railiance deploy --stage 2 and bin/railiance observe --stage 2 provide
the repeatable command path for production canaries declared in
railiance/app.toml.
Both commands default to non-mutating plan mode.
Deploy
bin/railiance deploy --stage 2 /path/to/overlay --pretty
bin/railiance deploy --stage 2 /path/to/overlay --server-dry-run --pretty
bin/railiance deploy --stage 2 /path/to/overlay --apply --approval-id <state-hub-id>
Plan mode validates the local Stage 2 chart and values paths and emits a
railiance.stage2-deploy-result.v1 JSON plan. It does not contact the cluster.
--server-dry-run runs helm upgrade --install --dry-run=server when Helm and
cluster access are available. --apply runs the Helm canary apply path with
--atomic --wait. If Stage 2 declares requires_approval = true, apply mode
fails closed unless --approval-id is provided.
The result records release identity, namespace, chart path, values path, expected checks/evidence, precheck status, and command byte counts. It does not embed Helm or kubectl logs.
Observe
bin/railiance observe --stage 2 /path/to/overlay --pretty
bin/railiance observe --stage 2 /path/to/overlay --live --pretty
Plan mode emits the rollout, pod selector, ingress selector, health URL, and metrics targets that live observation will query.
Live mode uses kubectl to check rollout status, deployment JSON, canary pods,
ingress/routing resources, and pod metrics when metrics-server is available.
Metrics unavailability is reported separately so a canary can fail for rollout
or readiness problems without hiding missing observability.
Safety
Stage 2 remains blocked when required local paths are missing, Helm is missing
for dry-run/apply, kubectl is missing for live observe, or approval evidence
is missing for an apply that requires approval. Use the emitted JSON as
non-secret evidence in State Hub progress notes.