Directory for change files, header file and unreleased files. Relative to project root. example: yaml changesDir: .changes

Directory for all unreleased change files. Relative to changesDir. example: yaml unreleasedDir: unreleased

Header content included at the top of the merged changelog. A default header file is created when initializing that follows "Keep a Changelog".

Filepath for your changelog header file. Relative to changesDir. example: yaml headerPath: header.tpl.md

Filepath for the generated changelog file. Relative to project root. ChangelogPath is not required if you are using projects. example: yaml changelogPath: CHANGELOG.md

File extension for generated version files. This should probably match your changelog path file. Must not include the period. example: yaml

for markdown changelogs

versionExt: md

Template used to generate change lines in version files and changelog. Custom values are created through custom choices and can be accessible through the Custom argument. example: yaml changeFormat: '* #{{.Custom.Issue}} {{.Body}}'

Filepath for your version header file relative to unreleasedDir. It is also possible to use the '--header-path' parameter when using the batch command.

Filepath for your version footer file relative to unreleasedDir. It is also possible to use the '--footer-path' parameter when using the batch command.

Customize the file name generated for new versions or release note files. The file is placed in the changesDir, so the full path is: {{.ChangesDir}}/{{.VersionFileFormat}}

Customize the file name generated for new fragments. The default uses the component and kind only if configured for your project. The file is placed in the unreleased directory, so the full path is:

{{.ChangesDir}}/{{.UnreleasedDir}}/{{.FragmentFileFormat}}.yaml example: yaml fragmentFileFormat: "{{.Kind}}-{{.Custom.Issue}}"

Template used to generate version headers.

Template used to generate component headers. If format is empty no header will be included. If components are disabled, the format is unused.

Template used to generate kind headers. If format is empty no header will be included. If kinds are disabled, the format is unused.

Template used to generate a version header.

Template used to generate a version footer. example: yaml

config yaml

custom:

• key: Author type: string minLength: 3 footerFormat: |

  Contributors

  {{- range (customs .Changes "Author" | uniq) }}
  • {{.}} {{- end}}

Body config allows you to customize the default body prompt

Components are an additional layer of organization suited for projects that want to split change fragments by an area or tag of the project. An example could be splitting your changelogs by packages for a monorepo. If no components are listed then the component prompt will be skipped and no component header included. By default no components are configured. example: yaml components:

• API
• CLI
• Frontend

Kinds are another optional layer of changelogs suited for specifying what type of change we are making. If configured, developers will be prompted to select a kind.

The default list comes from keep a changelog and includes; added, changed, removed, deprecated, fixed, and security. example: yaml kinds:

• label: Added
• label: Changed
• label: Deprecated
• label: Removed
• label: Fixed
• label: Security

Custom choices allow you to ask for additional information when creating a new change fragment. These custom choices are included in the change custom value. example: yaml

github issue and author name

custom:

• key: Issue type: int minInt: 1
• key: Author label: GitHub Name type: string minLength: 3

Replacements to run when merging a changelog. example: yaml

nodejs package.json replacement

replacements:

• path: package.json find: ' "version": ".*",' replace: ' "version": "{{.VersionNoPrefix}}",'

Configuration options for newlines before and after different elements.

Post process options when saving a new change fragment. example: yaml

build a GitHub link from author choice

post:

• key: AuthorLink value: "https://github.com/{{.Custom.Author}} changeFormat: "* {{.Body}} by {{.Custom.Author}}"

Prefix of environment variables to load for templates. The prefix is removed from resulting key map. example: yaml

if we have an environment variable like so:

export CHANGIE_PROJECT=changie

we can use that in our templates if we set the prefix

envPrefix: "CHANGIE_" versionFormat: "New release for {{.Env.PROJECT}}"

Projects allow you to specify child projects as part of a monorepo setup. example: yaml projects:

• label: UI key: ui changelog: ui/CHANGELOG.md
• label: Email Sender key: email_sender changelog: services/email/CHANGELOG.md

ProjectsVersionSeparator is used to determine the final version when using projects. The result is: project key + projectVersionSeparator + latest/next version. example: yaml projectsVersionSeparator: "_"