Watch a choudoufu wave apply
Optional: hand this page to your coding agentThe steps work by hand too.Show the whole prompt
Read https://intentius.io/terragucci/guides/watch-a-choudoufu-wave/.
For the commit I name, read run.json under my reports prefix and tell me, for each wave applying, how many resources are done, in flight and waiting, and which ones.
Read only: write nothing to the bucket.
Never apply, approve (a pull request review or `terragucci approve`), override a policy denial (`terragucci override`), use `--mode apply`, or merge; never touch `.chant/allowed_signers` or `chant/lifecycle`.Result
Section titled “Result”While a wave applies, each resource its plans change shows as done, in flight or waiting. After it applies, each changed resource lists its record’s past versions.
Prerequisites
Section titled “Prerequisites”| You need | Why |
|---|---|
binary: choudoufu and roots under live resource markers with a record store |
progress is read from the estate’s records |
| Reports in a bucket | the run view and the estate page live there; without one, only the job’s log and progress.json show it |
The estate page, with its terragucci audit step |
the resource history and the counts across projects |
Progress
Section titled “Progress”The wave reads its estates’ records, not the apply’s output. A resource is done once its record is written or removed, which choudoufu does as each resource’s apply returns. It is in flight once every resource it depends on is done, and waiting before that.
2 of 4 resources done
random_password.dbdoneterraform_data.seeddonetime_sleep.warm_upin flightterraform_data.configwaiting
-
Push a change. When a wave’s gate lets it through and its roots start applying, the job’s log names what it follows, then prints a line each time the records move:
wave 1 of 2: following 4 resources in the records of appwave 1 of 2: progress 2 of 4 done, 1 in flight, 1 waiting -
Open the run view,
<prefix>/<project>/runs/<commit>/run.htmlin the bucket. The applying wave’s column lists each resource with its state, and the page reloads every 15 seconds while a wave applies.run.jsoncarries the same list inwaves[].progress. -
Or read
terragucci-report/progress.jsonin the job’s report, written each time the list changes. -
On the estate page, each project with a wave applying shows
wave <n> applyingwith its counts, linked to the run view, as of the estate job’s last run.
| Setting | Effect |
|---|---|
TG_PROGRESS_SECONDS |
seconds between reads of the records; 5 by default |
A store terragucci cannot read, such as a kubernetes record store, gives no records: the job logs it once, and that root’s resources show done when its apply returns. Once a root’s apply fails, what it did not finish shows as not applied.
Record history
Section titled “Record history”After it applies, a tf-apply wave runs choudoufu live-history in each choudoufu root for each resource the apply changed, under the identity it reads that root’s records with. It keeps each version’s id, its time, and whether it is current or deleted, never a value.
-
Read the wave’s log, one line per root:
app: record versions: aws_sqs_queue.jobs 3 versions; terraform_data.seed 1 version -
On the estate page, each resource of the estate shows its version count beside it, linked to its history.
-
The history page,
history.html, lists each apply that changed the resource with who approved it, and below it the record’s versions, newest first. Reading one version’s contents takesaws s3api get-object --version-idwith your own identity.
| The store | The history says |
|---|---|
s3 |
each version the bucket keeps; listing takes s3:ListBucketVersions on the record store bucket |
local or kubernetes |
no past versions kept: the store replaces a record in place |
| the identity cannot list them | versions not listed, with choudoufu’s error; the wave still applies |
roots[].applied_changes[].record_versions in the wave’s report holds the same (Report JSON schema).
- Waves and approvals has the run view’s other parts.
- Locking and staleness explains why choudoufu takes no state lock.
These docs count page views and clicks with PostHog. They set no cookies, store nothing in your browser, and send nothing when your browser asks not to be tracked.