Job triggers

Every job runs in your forge’s CI. It starts in one of two ways: on an event the forge already delivers to that CI (a push, a pull request, a comment on GitHub and Forgejo, a workflow_dispatch), or on a schedule in the same CI. There is nothing to host, no endpoint that takes requests from outside, and no inbound webhook secret, on GitHub, GitLab and Forgejo alike.

Jobs and what starts them

Job	Starts on	Default	Expect	Key
check	each push; a pull request’s only from a fork	on	at once
plan and the plan note	a pull request from the same repo; on GitLab, a merge request pipeline	on	at once
apply, wave by wave	a push to the default branch, or to a branch apply.branches names	on	at once	apply.when
/terragucci plan and /terragucci apply comments, GitHub and Forgejo	the comment, as an issue_comment event	on	at once	atlantis_comments adds the atlantis forms
/terragucci notes, GitLab	the comments schedule: each run reads the merge requests updated in the last 24 hours and answers each note it has not answered, keeping its place by a marker on its own reply, so it holds no state	off	one interval	comments: <cron>
a re-plan by dispatch	workflow_dispatch with a pr input, and optionally root, on GitHub and Forgejo	on	at once
the waiting wave, after terragucci approve	the command itself: it re-runs the waiting run on GitHub, retries the waiting job on GitLab, and comments /terragucci apply on the merged pull request on Forgejo	on, with a forge token where you approve	at once	--no-resume turns it off
the waiting wave, after any other approval: a chat click, a ledger line, a pull request review, a decision point’s answer	the resume job, on a schedule and by workflow_dispatch on GitHub and Forgejo, and on a pipeline schedule with TERRAGUCCI_SCHEDULE=resume on GitLab	off	one interval	apply.resume: <minutes>, 5 to 60
a rollout’s next wave	the rollout job, on a schedule and by workflow_dispatch on GitHub and Forgejo, and on a pipeline schedule with TERRAGUCCI_SCHEDULE=rollouts on GitLab; it opens the next wave once the last one merged and applied	off	one interval after the last wave applies	rollouts: <cron>
drift checks	the drift schedule, and a workflow_dispatch with no pr input on GitHub and Forgejo; on GitLab, a pipeline schedule with no TERRAGUCCI_SCHEDULE	off	the schedule	drift: <cron>
an ephemeral environment	a pull request opened, pushed to, reopened or closed; on GitLab, the merge request pipeline	off	at once	ephemeral.roots
the ephemeral sweep	a schedule on GitHub and Forgejo, and a pipeline schedule with TERRAGUCCI_SCHEDULE=ephemeral on GitLab, where it is also what destroys a closed merge request’s copy	30 minutes, with ephemeral	one interval	ephemeral.sweep, 5 to 60
the estate page	a scheduled job you add to the control repo, from See every project	none	your schedule

init writes each scheduled job when its key is set, and on GitHub and Forgejo removes the workflow it wrote once the key goes. On GitLab the jobs are in the pipeline, and each runs only in a pipeline schedule you create under CI/CD, Schedules, with the variable the table names; init prints the steps for each schedule the config turns on.

The schedules’ reasons

Job	Why
the resume job	an approval is a commit on chant/lifecycle, and a push there starts no workflow, since the forges run a push’s workflows from the pushed branch. A job that reads the ledger is the one path that works however the approval landed. It is safe to run often: it reads the ledger, starts what has an approval no apply used, and stops before any credential is used when nothing waits. A missed or repeated run can neither strand a wave nor apply one twice, since the wave’s gate decides again on the plans it makes
the chat relay	it holds an approve-only token: it refuses to start with one that administers the repo, may push to the default branch or, on GitLab, has the api scope. The relay records the approval and starts no job, so the resume job applies what it records (Relay checks)
GitLab comments	GitLab starts no pipeline for a merge request note. Reading the notes on a schedule needs no webhook, no public endpoint and no secret beyond the project token the pipeline already has
rollouts, drift and the sweep	each acts on time passing or on several runs’ results, not on one event

Faster paths

To	Do
apply a wave the moment you approve it	run terragucci approve with a forge token: GH_TOKEN, GITHUB_TOKEN or gh auth login, GITLAB_TOKEN, or FORGEJO_TOKEN. It says what it started; without a token it says so, and the approval still stands for the resume job or a re-run
apply soon after a chat approval	apply.resume: 5
run the resume, rollout or drift job now	its workflow_dispatch on GitHub and Forgejo, or run its pipeline schedule on GitLab
answer GitLab notes sooner	a shorter comments cron

Outbound messages

Outbound, an apply job posts a wave that waits, is refused or fails to Slack and Teams and as a signed chant.notify/v1 event to notify.webhook. The drift job posts drift to Slack and Teams, with a Re-plan button, and terragucci notify unrecorded, run in the estate job after terragucci audit, posts each state version written outside every wave and migration to Slack and Teams (State versions written outside a wave). None of these starts a job by itself: the chat buttons reach your relay, and the Re-plan button a dispatch.

Next

• Resume after an approval for the resume job in full.
• Re-plan from a comment for the comment forms and the GitLab schedule.
• Architecture for the path of one change.