Module deploy 

gtc op deploy — the one-shot bundle deployment orchestrator.

The default, “just works” path: add the bundle deployment (when new), stage a revision from the local .gtbundle, warm it, and route 100 % of traffic to it. It reuses the four single-purpose verbs — bundles add, revisions stage, revisions warm, traffic set — so all of the audit / signing / revenue-policy logic stays single-sourced; this module only threads the minted ids between them and fills in sensible defaults.

A real local .gtbundle is required on every path — deploy refuses to publish an artifact-less revision (placeholder digests + an empty pack-list lock would be admissible by traffic yet broken at boot).

Re-deploying a bundle that is already deployed in the env stages a NEW revision and shifts 100 % traffic onto it (blue-green): because traffic set replaces the whole split, the previously-live revision leaves the routing table and drains at runtime. The superseded revision is retained (not archived) so gtc op traffic rollback still works.

Each invocation is its own rollout: without a caller-supplied --idempotency-key, the cut-over key is derived from the freshly-minted revision, so a re-run stages another revision rather than deduplicating. Supply a stable --idempotency-key to make retries idempotent — a repeat with a key that already routed returns the existing outcome without minting a new revision or disturbing the rollback target.

The deployer records desired state only; it carries no health-check producers (B9), so warm runs a no-op gate and the result reports routed, not a runtime liveness claim. greentic-start’s watcher reloads and begins serving once the split is written.

Prerequisites are required, never auto-created: the env must already exist (gtc op env init) and its trust root must carry the operator key (gtc op trust-root bootstrap). The deploy path never seeds signing keys — that would grant signing rights as a side effect of a deploy (C2).

The four verbs remain the advanced / fine-tune surface, untouched.

Structs

BundleDeployPayload

Input to deploy. Everything but bundle_id and bundle_path has a sensible default; the CLI requires --bundle and derives bundle_id from its filename stem.

DeploySummary

Combined summary of an orchestrated deploy.

RemoteBundlePins

Caller-pinned artifact pointers for a remote (--store-url) deploy.

Functions

deploy

Orchestrate add → stage → warm → traffic-set with defaults.

payload_from_deploy_args

Build a BundleDeployPayload from direct CLI args, or None when no args were supplied (deferring to --answers / --schema). Mirrors revisions::payload_from_stage_args: all clap fields are optional so the answers / schema paths keep working unchanged.