Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

tazuna apply

Reflects the Manifests declared in tazuna.yaml into the cluster. The central command of Tazuna.

tazuna apply [-f tazuna.yaml] [--tags ...] [--no-cache | --offline]
             [--sync [--prune] [--atomic]]

Behavior

The execution order is as follows. Cluster access happens from step 5 onward.

  1. Load and validate tazuna.yaml.
  2. If spec.context_matches is set, match against the current-context. Abort immediately on mismatch.
  3. Filter by --tags.
  4. Split manifests[] into layers derived from dependsOn. If no dependsOn is used, the number of layers equals the number of manifests, giving behavior identical to the traditional sequential execution in declaration order.
  5. Hand the manifests within each layer to their corresponding Manager in parallel and apply them to the cluster.
  6. After each Manifest applies successfully, run its tests.
  7. For Manifests whose apply and tests succeeded, write the content hash back to the state ConfigMap (the starting point for subsequent state diff / state drift / plan).
  8. After all Manifests are applied, execute spec.tests (overall Tests).

For dependsOn behavior, see DAG Execution via dependsOn.

State integration (–sync / –prune / –atomic)

tazuna apply is designed to write the state ConfigMap even by default. The role of tazuna state sync, formerly a separate command, has been merged into apply with the --sync flag (see “Migration: replacing the old state sync” below).

FlagBehavior
NoneApply every Manifest unconditionally via the Manager’s Apply(), then save state.
--syncSwitches to diff mode. Compares each Manager’s Build() result against the saved state and CreateOrUpdates only resources classified as added / modified / always-sync.
--sync --pruneIn addition to the above, Deletes resources that are in state but absent from the Build result (removed). Requires --sync.
--sync --atomicDefers each Manifest’s state save to the end. If even one error occurs partway, it exits without updating state at all. Requires --sync.

Specifying --prune / --atomic without --sync is a validation error.

Flag

In addition to global flags, the following are accepted.

FlagAliasTypeDefaultDescription
--tags-t[]string[]Limits the processing target to Manifests with at least one of the specified tags (OR evaluation).
--no-cache-boolfalseFor type: oras Manifests, always refetch from the registry without using the cache.
--offline-boolfalseFor type: oras Manifests, forbid access to the registry. If the cache misses, it is an error.
--sync-boolfalseEnables diff mode. Applies only the diff between state and the Build result.
--prune-boolfalseDeletes resources present in state but absent from the Build result. Requires --sync.
--atomic-boolfalseSaves state in a batch after all Manifests succeed. State is not changed on a mid-run error. Requires --sync.

--no-cache and --offline cannot be specified together.

Examples

# Normal apply (state is saved automatically)
tazuna apply -f tazuna.yaml

# Filter by tags
tazuna apply -f tazuna.yaml --tags web,batch

# Diff mode: apply only resources that differ from state
tazuna apply -f tazuna.yaml --sync

# Diff mode + deletion of obsolete resources
tazuna apply -f tazuna.yaml --sync --prune

# Diff mode + atomic (roll state back on a mid-run error)
tazuna apply -f tazuna.yaml --sync --atomic

# Stream traces to an OTLP/gRPC endpoint
tazuna apply -f tazuna.yaml --otlp-endpoint=localhost:4317

Migration: replacing the old tazuna state sync

Earlier versions of Tazuna had a separate command, tazuna state sync, responsible for applying the diff between state and the Build result. In this refactor that command has been removed and merged into tazuna apply --sync. The correspondence is as follows.

Old commandNew command
tazuna state synctazuna apply --sync
TAZUNA_STATE_SYNC_DELETE=true tazuna state synctazuna apply --sync --prune
tazuna state sync --atomictazuna apply --sync --atomic

As a behavioral difference, the new apply saves state even without --sync (the old apply wrote no state at all). As a result, a single apply makes state list / state diff / state drift / plan / status always return meaningful results.