---
url: https://toolchain.deltabox.studio/guide/ci/changelog.md
---
# Changelog workflow

The `ci.changelog` workflow (`changelog.yml`) generates the changelog and applies
the version bump. It runs on every push to `ci.changelog.branches.dev` (or
`main` when `dev` is not set), then commits the updated `CHANGELOG.md` files and
`package.json` versions back to the branch.

```ts [dbx.config.ts]
toolchain: {
    ci: {
        changelog: {
            branches: { main: 'main', dev: 'dev' },
            pushBranches: ['dev'], // optional per-workflow override
        },
    },
}
```

`ci.changelog` is also the changelog **pipeline** config. Its options are
documented in the [Changelog](/guide/changelog/) guide:

* [Branches](/guide/changelog/branches)
* [commitlint](/guide/changelog/commitlint)
* [Versioning](/guide/changelog/versioning)
* [CLI](/guide/changelog/cli)

The workflow is opt-in (`ci.changelog: true` or an object). `ci.changelog:
false` leaves it unmanaged; `ci.changelog.commitlint: false` still generates the
workflow but skips commitlint, its config and the local hook.

`ci.changelog` inherits the manual `toolchain.changelog` pipeline options when
it does not set them itself (for example `ci.changelog: true` or an
object that only sets workflow options like `pushBranches`). Explicit
`ci.changelog` options win; `branches` only exists on `ci.changelog`.

The workflow itself can target another vendor with `{ provider, workflow }`
(GitLab/Azure); the versioning/commitlint pipeline still lives in
`toolchain.changelog` (or the `ci.changelog` object options), not in the vendor
workflow. See [Workflow settings](/guide/ci/settings#vendor-workflows).