Promotion and re-verification

A request to Kargo begins a release decision; it does not finish one. Kargo selects the candidate, renders its chart source with the immutable image digest, writes an environment branch, and asks Argo CD to reconcile that output. Verification then tests the selected environment. This guide preserves that controller path so an observed result can be attached to a real candidate.

Operate only in an explicitly approved owned Radius testnet lab, with the target context and budget reviewed. Staging verification starts paid traffic and bounded faults. Prod is a production-like testnet environment whose post-deploy smoke checks health. This website requires neither operation to build or publish.

Inspect the prerequisite layer

./platform_setup_scripts/07-verify.sh \
  --config platform_setup_scripts/config.env --scope all

Resolve failed prerequisites before requesting another run. Review the current Freight source and image digest, the environment’s rendered revision, its Argo CD state, the Stage contract, signer readiness, secret references, and the bounded traffic budget. Readiness of the verifier’s resource checks is necessary context, not an advance gate verdict.

Plan the intended path

./scripts/validate-live.sh --plan --scenario chaos-gate

The plan validates routing and prints the action without contacting Kubernetes, Kargo, cloud, or testnet:

Scenario	Stage / namespace	Verification
baseline	dev / url-shortener-dev	service-health
chaos-gate, regression-blocked, recovery	staging / url-shortener-staging	service-health and chaos-gate
prod-smoke	prod / url-shortener-prod	prod-post-deploy-health

The baseline scenario here requests Kargo’s current dev health verification. It is distinct from run-loadgen.sh --scenario baseline, which creates bounded unpaid traffic, and from score-baseline.py, which scores that traffic window. Choose the tool according to the observation needed.

With no named Freight, the action re-verifies the Stage’s current candidate. After owner review, the actual request is:

./scripts/validate-live.sh --execute \
  --acknowledge-owned-testnet-lab --scenario chaos-gate \
  --config platform_setup_scripts/config.env

The preferred command is kargo verify stage. If a compatible Kargo CLI is absent, the script resolves the last verification ID and annotates that exact Stage to request re-verification. This fallback is still a mutation that asks Kargo to run its contract; it is not read-only inspection.

Promote a named candidate

To review a different staging candidate, include its real Freight name in the plan:

./scripts/validate-live.sh --plan --scenario chaos-gate \
  --promotion-freight <actual-freight-name>

Execution additionally requires --acknowledge-staging-promotion. The runner verifies the target and templates, then requests kargo promote; it does not directly create an AnalysisRun, Workflow, load Job, or patched app. regression-blocked requires a named pipeline-produced Freight so a deliberately bad candidate remains attributable to the delivery path.

For a downstream prod-like promotion, the scenario is prod-smoke and the additional flag is --acknowledge-prod-promotion. The runner requires the named Freight’s verifiedIn.staging.verifiedAt before requesting it. Normal dev promotion can be automatic; staging and prod remain manual. A successful staging result grants normal downstream eligibility. It does not automatically promote prod.

Kargo supports a separate manual Freight approval override. That approval is an operator decision, not proof that upstream verification passed. Do not describe it as a replacement successful gate, and do not use it to erase a failed candidate’s history.

Wait for the verdict and cleanup

A zero request exit status means Kargo accepted the request. Follow the associated Promotion, rendered revision, Argo CD reconciliation, AnalysisRun, and, for staging, enclosing gate Job and per-experiment scorecards. Each handoff needs its own observation. A passing scorecard does not supersede a cleanup failure or failed Job.

Record the newly observed identity chain and window using evidence collection. Give every execution a new run ID. A re-verification must not overwrite a failed record, even when source and application digest are unchanged. Stop on absent/stale telemetry, missing paid traffic, failed score, or unverifiable cleanup; use troubleshooting before another request.

The contracts are validate-live.sh, Project policy, staging Stage, prod Stage, and promotion tests. Follow one release explains the handoffs; the October 3 case supplies the recorded example.