---
url: https://toolchain.deltabox.studio/guide/changelog/cli.md
---
# CLI

```sh
dbx changelog                       # bump + write (uses ci.changelog.versioning)
dbx changelog --dry-run             # preview the root entry
dbx changelog --range v1.2.0..HEAD  # scan a specific range
dbx changelog --version 2.0.0       # force a version (retags the changelogs)
dbx changelog --format-only         # regroup existing changelogs, no bump
dbx changelog --release-notes 2.0.0 # print the release PR body for a version
```

The command reads `ci.changelog` and falls back to the manual
`toolchain.changelog` pipeline options (commitlint, versioning, vscode). This
lets a project keep manual/API changelog runs without enabling the CI workflow;
`ci.changelog` inherits the same options when it does not override them.

The generated `changelog` workflow runs `dbx changelog --range …` on every push
to the `dev` branches (or `main` when `dev` is unset), so versioning is applied
from CI as well as locally.

`dbx workflow [id…]` triggers the generated workflows with their vendor CLI
(`gh`, `glab` or `az`); with no ids it triggers every workflow you declared under
`toolchain.ci`. See [Workflows](/guide/cli#workflows).

## Formatting

`--format-only` regroups the existing entries without bumping versions. It keeps
list items, unwraps hard-wrapped lines, keeps multi-line `BREAKING CHANGE:`
footers together and preserves fenced code blocks. Numeric-only short hashes
(eg. `#4033009`) are resolved against git, so they stay commit links while real
issue numbers stay issue links. Existing subjects and descriptions are never
re-rendered from git: hand corrections (including backtick fixes) survive, and a
description is only filled in when the entry has none. See
[Writing commit messages](/guide/changelog/writing-commit-messages).