A changelog generator for GitHub Issues, available as a release jar or for use as a GitHub Action.
The changelog generator requires Java 17 or later. To generate a markdown changelog using a release jar, follow these steps:
-
Download a release jar.
-
Run
java -jar github-changelog-generator.jar <milestone-title> <changelog-file> --changelog.repository=<org>/<name>
To increase GitHub’s rate limits, you can also use --github-token=<token> to provide an access token that is used for authentication.
For more advanced configuration options, see below.
-
changelog-file: Path of the file to which the changelog should be written. Defaults tochangelog.md -
config-file: Path to a changelog generator configuration file, relative toGITHUB_WORKSPACE. See below for details of the advanced options that can be configured using this file. -
repository: Repository for which a changelog should be generated. Defaults to the workflow’s repository. -
token: Token for authentication with GitHub. Authenticating increases GitHub rate limits.
A YAML configuration file can be used to provide more complex configuration, either when running as a release jar or as a GitHub action.
By default, the changelog will contain the following sections:
| Title | Label Text |
|---|---|
":star: New Features" |
"enhancement" |
":lady_beetle: Bug Fixes" |
"regression" or "bug" |
":notebook_with_decorative_cover: Documentation" |
"documentation" |
":hammer: Dependency Upgrades" |
"dependency-upgrade" |
The title is in Markdown format and emoji like ":star:" can be used.
If you want something different then you can add sections YAML:
changelog:
sections:
- title: "Enhancements"
labels: ["new"]
- title: "Bugs"
labels: ["fix"]By default, adding sections will replace the default sections. To add sections after the defaults, add the following configuration:
changelog:
add-sections: trueYou can also customize the contributors title using the following:
changelog:
contributors:
title: "Contributors"You can add external links such as release notes for quick access using the following:
changelog:
external_links:
- name: "Release Notes"
location: "https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.3-Release-Notes"Unless otherwise configured, issues will only appear in the first matching section.
For example, if you have an issue labeled with enhancement and documentation then it will only appear in the "New Features" section.
If you want an issue to appear in multiple sections, use the group property.
Groups allow you to create logical groupings of related sections.
An issue may only appear once in any given group.
For example, you might define the following:
changelog:
sections:
- title: "Highlights"
labels: ["noteworthy"]
group: "highlights"
- title: "Enhancements"
labels: ["new"]
- title: "Bugs"
labels: ["fix"]This will create two distinct groups, "highlights" and "default" (which is used if no group property is specified).
An issue labeled with new and noteworthy will appear in both the "Highlights" and "Enhancements" section.
By default, an issue’s entry in the changelog summarizes the issue using its title. Alternatively, summaries can be derived from a comment made by a member of the issue’s owning organization or by applying a regular expression to its body.
To be used as the summary, a comment must begin with a configured prefix. The prefix is not included in the summary. When no such comment is found on the issue, the chain of ported issues is checked and the first matching comment in the chain is used. If no matching comment is found, the issue’s title is used as a fallback.
For example, you might define the following:
changelog:
sections:
- title: "Noteworthy Changes"
labels:
- "status: noteworthy"
summary:
mode: "member-comment"
config:
prefix: "Noteworthy change:"This will create a section entitled "Noteworthy Changes" that will include one entry for each issue labelled with "status: noteworthy". Each entry will use the text from the first member’s comment that begins "Noteworthy change:" to summarize the issue. If no such comment is found, the issue’s title is used.
A summary can be extracted by applying a regex to the body of the issue. If the regex matches, the issue is summarized using its first group. If the regex does not match, the issue’s title is used.
For example, you might define the following:
changelog:
sections:
- title: "Dependency Upgrades"
sort: "title"
labels:
- "type: dependency-upgrade"
summary:
mode: "body-regex"
config:
expression: '(Upgrade to \[.*\]\(.*\)).*'This will create a section entitled "Dependency Upgrades" that will use the regex (Upgrade to \[.\]\(.\)).* to summarize the issue.
If the body does not match the regex, the issue’s title is used.
Issues and pull requests can be excluded from the changelog by configuring exclusions.
You can ignore all items that have certain labels using changelog.issues.exclude.labels.
For example:
changelog:
issues:
exclude:
labels: ["wontfix", "question", "duplicate", "invalid"]Contributors whose username ends with [bot], such as dependabot[bot] and github-actions[bot], are automatically excluded.
If you have other contributors that you want to be excluded (perhaps core team members), you can set the following:
changelog:
contributors:
exclude:
names: ["coremember"]You can also use * if you want to drop the contributors section entirely.
By default, issues are sorted by their "created" date.
If you want to order them by title instead you can set changelog.issues.sort to title.
It’s also set the property on section configuration if you want ordering per section:
changelog:
sections:
- title: "Bugs"
labels: ["bug"]
- title: "Dependency Upgrades"
labels: ["dependency"]
sort: "title"If an issue is forward-ported or backward-ported between milestones, you might have separate issues in each milestone that reference the original issue. To allow the changelog generator to find these linked issues, configure the labels that are used to identify ported issues. The body of a ported issue should contain a comment with a reference to the original issue. The reference is extracted using a regular expression with exactly one capture group for the original issue number.
changelog:
issues:
ports:
- label: "status: forward-port"
bodyExpression: 'Forward port of issue #(\d+).*'
- label: "status: backport"
bodyExpression: 'Back port of issue #(\d+).*'The changelog generator will use the links between ported issues to:
-
Credit a contributor in the changelog for every milestone that includes a forward or backward port of the issue that was resolved
-
Find member comments when looking for a custom issue summary
This project is Open Source software released under the Apache 2.0 license.