chant for teams shipping from trunk

For a team that merges every change to one branch and ships from it: CI marks the commits that passed as git tags, a person cuts a release from one, and the release moves through each environment behind a gate bound to what changes there.

Works

• chant ci tick tags each trunk commit that passed the required CI phases ci/green/<sha>, and revokes the tag when a re-run fails
• chant release cut compiles one green commit for every environment once, and chant release publish ships it from CI with provenance
• chant components promote --release deploys the recorded templates and artifacts in promotion order, each environment behind a gate that binds the release, the environment and the change set
• Feature flags as reviewed workspace records, read by the build, so unfinished work merges switched off
• Rollback to an earlier release, revocation read from the tags, retention, and DORA metrics from the same records

Differs

By forge

GitHub

• --generate github writes the pull-request workflow under .github/workflows/, run on pull_request and on push to the target branch.
• Both jobs use the job's own github.token. On a pull request from a fork that token is read-only, so the plan note and the status are not posted.

GitLab

• --generate gitlab writes .gitlab-ci.yml, and apply runs one at a time per environment through resource_group.
• A CI job token cannot write merge request notes, so set a project access token with the api scope as the masked variable CHANT_FORGE_TOKEN.
• GitLab has no check-run reader, so set ci.green.source to runs: each phase is a chant Op run with a runner key, and the tick goes in the pipeline after them.

Forgejo

• --generate forgejo writes the GitHub workflow in the Forgejo dialect under .forgejo/workflows/: the runner label, action references by URL, and no permissions block.
• Forgejo workflows are GitHub-dialect, so chant audit applies its GitHub rules to them.
• Forgejo has no check-run reader, so set ci.green.source to runs: each phase is a chant Op run with a runner key, and the tick goes in the pipeline after them.

First step

Declare ci.green in chant.workspace.json first; the dry run then prints the tags the tick would make.

npx chant ci workflow
npx chant ci tick --dry-run
npx chant ci list --limit 10

Tag Green Commits

Or hand this step to your coding agentIt stops at a pull request or a report.

Read https://intentius.io/chant/for/releases/.
Following https://intentius.io/chant/guide/green-commits/, add a `ci.green` block to `chant.workspace.json` for the trunk branch and the CI phases I name, and generate the tick's workflow with `npx chant ci workflow`.
Run `npx chant ci tick --dry-run` and `npx chant ci list`, show me what they print, and open a pull request with the declaration and the workflow.
Never deploy to a real cloud account or shared environment (with `chant run`, `chant components` or a platform's own CLI), approve (a pull request review, `chant approve` or `chant run approve`), override a policy denial (`chant approve policy-override`), or merge; never cut or publish a release (`chant release cut --yes` or `chant release publish`), push or delete a `ci/*` tag (`chant ci tick` pushes them), or change the value of an existing flag; never touch `.chant/allowed_signers` or `chant/lifecycle`.

Show the whole prompt

Read https://intentius.io/chant/for/releases/.
Following https://intentius.io/chant/guide/green-commits/, add a `ci.green` block to `chant.workspace.json` for the trunk branch and the CI phases I name, and generate the tick's workflow with `npx chant ci workflow`.
Run `npx chant ci tick --dry-run` and `npx chant ci list`, show me what they print, and open a pull request with the declaration and the workflow.
Never deploy to a real cloud account or shared environment (with `chant run`, `chant components` or a platform's own CLI), approve (a pull request review, `chant approve` or `chant run approve`), override a policy denial (`chant approve policy-override`), or merge; never cut or publish a release (`chant release cut --yes` or `chant release publish`), push or delete a `ci/*` tag (`chant ci tick` pushes them), or change the value of an existing flag; never touch `.chant/allowed_signers` or `chant/lifecycle`.

Copy promptCopy link

Proof

Example projects in the chant repository for this room, each with a README that has the commands to run it.

Example	Where
components-aws-e2e	examples/components-aws-e2e

Then read

Tasks

Tag Green CommitsLink commits to work itemsRelease from Your WorkstationPromote a ReleaseFeature FlagsPrune chant/lifecycleRead Delivery Metrics

Background

Trunk and ReleasesBuild-Time ParametersState and Governance

Reference

chant cichant releasechant components promotechant change-setchant workspace statuschant workspace metricschant lifecycle gcWorkspace Declaration: CI