Skip to content

State Management

Command flags, management subcommands, non-interactive defaults, and worked examples for the deploy state file.

Ignore the deploy state file and re-run all steps from scratch.

Terminal window
dwe deploy run --force

Useful when:

  • You want to guarantee a fresh deploy regardless of prior state
  • The state file is corrupted and you cannot repair it
  • You need to re-run steps that were skipped due to unchanged hashes

When --force is used, the state file is cleared before the pipeline runs (all steps are treated as absent for skip decisions).

Continue from the last failed or partially deployed step.

Terminal window
dwe deploy run --resume

Use this after a failed deploy to pick up where it left off, rather than re-running already-completed steps.

In non-interactive mode (no TTY, no -y/--non-interactive flag):

  • If the last run was failed/partial, you must use --resume or --force to proceed
  • Without a flag, the command exits with an error (fail-safe for CI)

In interactive mode (TTY without -y/--non-interactive):

  • If the last run was failed/partial, you are prompted to choose: resume, re-run all steps (state ignored — when: still applies), or cancel

Suppress all interactive prompts.

Terminal window
dwe deploy run -y
dwe deploy run --non-interactive

Use in CI/CD pipelines to ensure the deploy does not hang waiting for user input.

Behavior under -y:

  • If the project is already deployed and config hashes match: exits successfully (no-op)
  • If the project is already deployed but config changed: applies delta (re-run only changed scopes)
  • If the last run failed/partial: exits with error (use --force or --resume to override)

Display the contents of .dwe/deploy/state.yml in YAML format.

Terminal window
dwe deploy state show

Shows:

  • Project-level status, config hash, and last-run timing
  • Per-service status, config hash, and last-run timing
  • Per-phase and per-step outcomes, action hashes, and durations

Useful for debugging why a step was skipped, or to inspect the journal after a deploy.

Delete the deploy state file.

Terminal window
dwe deploy state clear

Equivalent to rm .dwe/deploy/state.yml. In interactive mode (TTY), prompts for confirmation. Use -y to skip confirmation in CI.

Terminal window
dwe deploy state clear -y # Non-interactive

After clearing, the next dwe deploy run treats all steps as absent and re-runs them.

Rebuild status aggregates from per-step records.

Terminal window
dwe deploy state repair

Recomputes:

  • Per-phase status (from step outcomes)
  • Per-service status (from phase outcomes)
  • Project status (from per-service outcomes)

Preserves all step-level data (action hashes, timestamps, durations). Use this to fix status inconsistencies that might arise from manual edits or unexpected crashes.

In non-interactive mode (no TTY, STDIN is piped or closed):

Project stateBehavior
not deployedruns pipeline
deployed, config hash matches, no check stepsexits 0, no-op
deployed, config hash matches, has check stepsruns pipeline; skips unchanged steps, re-runs check steps
deployed, config hash divergedruns pipeline; re-runs changed scopes, skips unchanged ones
last_run failed/partialexits 1, requires --resume or --force
Terminal window
$ dwe deploy run
Phase setup
create-dirs
install
Phase init
db-create
migrate
Phase finalize
render-ide
# State file recorded: all steps ok, hashes match
$ dwe deploy run
all steps already deployed, skipped
# (Or if there were check steps:)
$ dwe deploy run
Phase setup
· create-dirs (skipped by state)
· install (skipped by state)
Phase init
· db-create (skipped by state)
· migrate (skipped by state)
Phase finalize
render-ide (check re-validated)

Example: edit a step, re-run on next deploy

Section titled “Example: edit a step, re-run on next deploy”
workspace/services/main/deploy.yml
- name: install
type: command
cmd: app.install # was "app.install"
# (hash was abc123)

Edit the command:

- name: install
type: command
cmd: app.install-prod # changed
# (hash is now def456)
Terminal window
$ dwe deploy run
Phase setup
· create-dirs (skipped by state)
install (re-run: hash changed abc123 def456)
Phase init
db-create
migrate

The install step re-runs because its hash changed. Steps with unchanged hashes are skipped.

Example: edit a service config, invalidate service scope

Section titled “Example: edit a service config, invalidate service scope”
workspace/services/main/service.yml
enabled: true
type: app
dir: services/main
depends_on:
- db

Edit the main service:

workspace/services/main/service.yml
enabled: true
type: app
dir: services/main
depends_on:
- db
- cache # added dependency

The service’s config_hash changes, so all of main’s steps re-run:

Terminal window
$ dwe deploy run
Phase setup (main)
create-dirs (re-run: service config_hash changed)
install (re-run: service config_hash changed)
Phase init (main)
db-create (re-run: service config_hash changed)
migrate (re-run: service config_hash changed)
Terminal window
dwe deploy run --force

Clears the state file and re-runs all steps from scratch, even if they all succeeded previously.

Note: --force only ignores the deploy state. Phase- and step-level when: conditions are still evaluated on every run. For example, when: dir-empty services/main/src will still skip an install step once the directory has been populated by a previous successful run. To wipe service directories, Docker volumes, and other artifacts so the next deploy is truly clean, use dwe reset run && dwe deploy run.

Terminal window
$ dwe deploy run
Phase setup
Phase init
Phase finalize
render-ide (failed)
# Process crashed or was killed. State file recorded the failure.
$ dwe deploy run # (in interactive mode)
# Prompted: "Failed deploy detected: Resume / Re-run all steps / Cancel"
# Choose: Resume
Phase setup
· create-dirs (skipped)
· install (skipped)
Phase init
· db-create (skipped)
· migrate (skipped)
Phase finalize
render-ide (re-run from where it failed)

Or in non-interactive mode:

Terminal window
dwe deploy run --resume