Current CLI Rehearsal

Exercise the implemented signed-file workflow promotion milestone in isolated installations

The current CLI can rehearse a supported workflow moving between separate self-hosted installations through a signed file. This chapter describes implemented commands and their limits.

This is a restricted milestone, not organization-wide promotion. Build the CLI from the same reviewed checkout as the APIs; do not assume the public package contains these commands. Use disposable pilot workspaces. Enrollment is permanent through the current API, and disabling the feature flag does not remove managed-write guards.

Prerequisites

Complete Kubernetes Setup, including compatible promotion workers, the notification scheduler, target-local resources, and independently configured trust. The target workspace must contain no workflows or workflow folders, including archived ones. Current enrollment accepts workflow objects only and rejects unsupported tools and local-resource references.

Use the CLI README and operations runbook supplied with your exact build for revision-checked policy, signing-key, and trust request files. The CLI cannot manufacture the customer's independent trust authority. A bundle is not proof of its own authority.

Set STEELENGINE_URL and STEELENGINE_API_KEY for the installation being operated. Obtain the API key through your secret manager or approved shell environment. Switch both URL and key when moving between installations. HTTPS is required outside loopback unless an operator explicitly allows private HTTP.

Check Configuration

Start with the read-only configuration check on each installation, before enrollment or export:

steelengine promotion doctor --organization ORGANIZATION_ID \
  --mode authoring --expected-environment development

On Production, switch both URL and key, use --mode target, and replace the expected environment key with production (or its actual configured key). The mode selects checks; it does not configure an environment. Run both modes if an installation has both responsibilities.

Doctor checks installation/organization identity, server clock status, unchanged configuration revisions, and either the selected local signer or target trust freshness. It prints actionable failures. Add --json for automation. Exit code 0 means the configuration checks passed, 2 means blocked, 3 means incomplete, and 1 means invalid arguments or local client setup. A blocked check takes precedence over an incomplete one.

The report always identifies its configuration-only scope and what it did not check. A pass does not establish worker, scheduler, Helm, GitHub, complete organization, integration, source-specific trust, or release readiness. Continue with candidate preflight. Doctor uses read requests and does not enroll workspaces, create keys, install trust, or activate content.

Capture on Development

export STEELENGINE_URL=https://dev.steelengine.example.com
steelengine promotion environment get --organization SOURCE_ORGANIZATION_ID
steelengine promotion enroll SOURCE_WORKSPACE_ID --mode authoring
steelengine promotion enrollment SOURCE_WORKSPACE_ID
steelengine promotion export SOURCE_WORKSPACE_ID \
  --idempotency-key pilot-export-1 \
  --output pilot.steelrelease

Copy the returned binding.sourceIdentity into source-identity.json. It contains the source deployment, organization, and workspace IDs. Transfer that file and the bundle through the approved channel. Keep the original digest and operation result.

Import on the Target

export STEELENGINE_URL=https://steelengine.example.com
steelengine promotion trust status --organization TARGET_ORGANIZATION_ID
steelengine promotion enroll TARGET_WORKSPACE_ID \
  --mode target --source source-identity.json
steelengine promotion import TARGET_WORKSPACE_ID \
  --file pilot.steelrelease --idempotency-key pilot-import-1 --wait
steelengine promotion releases TARGET_WORKSPACE_ID

Use the target's returned release ID for subsequent commands. Import retains the candidate; it does not apply definitions or activate execution.

Apply and Bind

steelengine promotion preflight RELEASE_ID --output apply-plan.json
steelengine promotion apply RELEASE_ID \
  --plan apply-plan.json --idempotency-key pilot-apply-1 --wait
steelengine promotion assignments TARGET_WORKSPACE_ID --release RELEASE_ID
steelengine promotion assign TARGET_WORKSPACE_ID --file assignments.json

Review the preflight report before apply. Successful command execution means a report was produced, not that all its gates passed. If the report requires explicit change acceptance, use --accept-change DIGEST only for reviewed entries.

The assignment request contains releaseId, current expectedAssignmentRevision, and explicit changes and/or providerChanges following the API schema shipped with the build. Choose resources already provisioned on the target. Omitted roles stay unchanged; targetId: null removes an assignment. Skip assign when no assignments are required. Apply leaves the currently executable version unchanged.

Activate and Verify

steelengine promotion preflight RELEASE_ID \
  --purpose activate --apply-operation APPLY_OPERATION_ID \
  --output activation-plan.json
steelengine promotion activate RELEASE_ID \
  --plan activation-plan.json --idempotency-key pilot-activate-1 --wait
steelengine promotion release RELEASE_ID

Review the activation plan, exact applied operation, binding targets, current trust and worker readiness. Activation rechecks state and rejects stale plans. Verify the reported generation and execute the workflow using approved test data. This proves the tested workspace path only; looping these commands over workspaces does not create an atomic organization release.

Interrupted Operations and Rollback

steelengine promotion status OPERATION_ID --wait --wait-timeout 600
steelengine promotion rollback-preflight ORIGINAL_ACTIVATION_ID \
  --output rollback-plan.json
steelengine promotion rollback ORIGINAL_ACTIVATION_ID \
  --plan rollback-plan.json --idempotency-key pilot-rollback-1 --wait

Review rollback eligibility and any explicit acceptances before the mutation. Use an earlier retained normal activation when testing an actual return to a previous version. Rollback leaves newer drafts and external side effects intact.

For an organization-managed target, use the organization rollback review. Direct workspace rollback cannot bypass the organization boundary; the organization coordinator restores every workspace in one transaction.

If admission acknowledgement is lost, retry identical input with the original key against the same installation. Do not create a new key to work around an uncertain result. --wait reports product completion independently of notification delivery.

Limits to Record

The reviewed runtime rejects unimplemented resources and operations rather than falling back to local defaults. Apps, knowledge bases, table schemas, and docs are not established as a complete promotion path by this rehearsal. Git transport, organization activation, external-trigger cutover, authority replacement, and general historical retention cleanup remain outside this milestone.

Retain the tested build, safe command results, release digest, operation and activation IDs, validation inputs, and observed limitations. These records are the starting evidence for the broader organization feature, not a substitute for its acceptance tests.

On this page