- Changelog generation has never been so easy
- Whatβs the point of a changelog?
- Why should I care?
- Installation
- Usage
- Output example
- Migrating from a manual changelog
- Features and advantages of this project
- Practical Use Cases
- Am I missing some essential feature?
- FAQ
- Contributing
- Contact us
- License
Fully automated changelog generation - This gem generates a changelog file based on tags, issues and merged pull requests (and splits them into separate lists according to labels) from 
GitHub.
Since you don't have to fill your CHANGELOG.md manually now: just run the script, relax and take a cup of β before your next release! π
To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.
Because software tools are for people. "Changelogs make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project."
β‘οΈ https://keepachangelog.com
GitHub Changelog Generator is a Ruby program, distributed as a RubyGem. The Ruby language homepage has an Installation page.
Install the gem like:
$ gem install github_changelog_generator
Depending on your system, you may need to run the shell as an Administrator (Windows),
or use sudo gem install github_changelog_generator (Linux).
github_changelog_generator -u github_project_namespace -p github_project
(where the project namespace is likely your username if it's a project you own, but it could also be the namespace of the project)
Using Docker is an alternative to installing Ruby and the gem.
Example invocation:
$ docker run -it --rm -v "$(pwd)":/usr/local/src/your-app githubchangeloggenerator/github-changelog-generator
-
For GitHub Enterprise repos, specify both
--github-siteand--github-apioptions:$ github_changelog_generator --github-site="https://github.yoursite.com" \ --github-api="https://github.yoursite.com/api/v3/"
This generates a CHANGELOG.md, with pretty Markdown formatting.
-
Look at CHANGELOG.md for this project
-
ActionSheetPicker-3.0/CHANGELOG.md was generated by command:
$ github_changelog_generator -u github-changelog-generator -p ActionSheetPicker-3.0 -
In general, it looks like this:
1.2.5 (2015-01-15)
Implemented enhancements:
- Use milestone to specify in which version bug was fixed #22
Fixed bugs:
- Error when trying to generate log for repo without tags #32
Merged pull requests:
PrettyPrint class is included using lowercase 'pp' #43 (schwing)
support enterprise github via command line options #42 (glenlovett)
Print help for all command-line options to learn more details:
$ github_changelog_generator --help
For more details about params, read the Wiki page: Advanced changelog generation examples
In your project root, you can put a params file named .github_changelog_generator to override default params:
Example:
unreleased=false
future-release=5.0.0
since-tag=1.0.0
GitHub only allows 50 unauthenticated requests per hour.
Therefore, it's recommended to run this script with authentication by using a token.
Here's how:
- Generate a token here - you only need "repo" scope for private repositories
- Either:
- Run the script with
--token <your-40-digit-token>; OR - Set the
CHANGELOG_GITHUB_TOKENenvironment variable to your 40 digit token
- Run the script with
You can set an environment variable by running the following command at the prompt, or by adding it to your shell profile (e.g., .env, ~/.bash_profile, ~/.zshrc, etc):
export CHANGELOG_GITHUB_TOKEN="Β«your-40-digit-github-tokenΒ»"
So, if you get a message like this:
API rate limit exceeded for github_username.
See: https://developer.github.com/v3/#rate-limitingIt's time to create this token! (Or, wait an hour for GitHub to reset your unauthenticated request limit.)
Knowing how dedicated you are to your project, you probably haven't been waiting for github-changelog-generator to keep a changelog.
But you probably don't want your project's open issues and PRs for all past features listed in your historic changelog, either.
That's where --base <your-manual-changelog.md> comes in handy!
This option lets append your old manual changelog to the end of the generated entries.
If you have a HISTORY.md file in your project, it will automatically be picked as the static historical changelog and appended.
You love rake? We do, too! So, we've made it even easier for you:
we've provided a rake task library for your changelog generation.
Configure the task in your Rakefile:
require 'github_changelog_generator/task'
GitHubChangelogGenerator::RakeTask.new :changelog do |config|
config.user = 'username'
config.project = 'project-name'
config.since_tag = '0.1.14'
config.future_release = '0.2.0'
endAll command-line options can be passed to the rake task as config
parameters. And since you're naming the rake task yourself, you can create
as many as you want.
You can look for params names from the parser source code (#setup_parser). For example, to translate the bugs label to Portuguese, instead of setting config.bugs_label, you have to set config.bug_prefix, and so on.
-
Generate canonical, neat changelog file, with default sections that follow basic changelog guidelines π
-
Optionally generate Unreleased changes (closed issues that have not released yet) π«
-
GitHub Enterprise support via command line options! π
-
Flexible format customization:
- Customize issues that should be added to changelog β³οΈ
- Custom date formats supported (but keep ISO 8601 in mind!) π
- Manually specify the version that fixed an issue (for cases when the issue's Closed date doesn't match) by giving the issue's
milestonethe same name as the tag of version π - Automatically exclude specific issues that are irrelevant to your changelog (by default, any issue labeled
question,duplicate,invalid, orwontfix) βοΈ
-
Distinguish issues by labels. π
- Merged pull requests (all merged pull-requests) π
- Bug fixes (issues labeled
bug) πͺ² - Enhancements (issues labeled
enhancement) π - Issues (closed issues with no labels) π±
- Plus any additional custom label-to-section mappings you want βοΈ
-
Manually include or exclude issues by labels π§
-
Customize lots more! Tweak the changelog to fit your preferences π© (See
github_changelog_generator --helpfor details)
For each version, you can add a release summary with text, images, gif animations, etc, and show new features and notes clearly to the user. This is done using GitHub metadata.
Example: adding the release summary for v1.0.0:
- Create a new GitHub Issue
- In the Issue's Description field, add your release summary content
Hello, World! :tada:
- Set the Issue Label
release-summaryand add it to the GitHub Milestonev1.0.0 - Close the Issue and execute
github-changelog-generator - The result looks like this:
v1.0.0 (2014-11-07)
Hello, World! π
Implemented enhancements:
- Add some features
Here is a wikipage list of alternatives that I found. But none satisfied my requirements.
If you know other projects, feel free to edit this Wiki page!
Here's a wikipage list of projects.
If you've used this project in a live app, please let me know! Nothing makes me happier than seeing someone else take my work and go wild with it.
If you are using github_changelog_generator to generate your project's changelog, or know of other projects using it, please add it to this list.
github_changelog_generator can be used in combination with the github cli to create release notes. Use the --since-tag and --output options of github_changelog_generator to create a changelog for the current release and store the results in a file. In the
example below, version 2.0.0 is the current release and version 1.0.0 is the previous release.
mkdir -p build
github_changelog_generator \
--since-tag 1.0.0 \
--output build/changelog.md
Then use the release create feature of the github cli to create a new github release
gh release create 2.0.0 \
--notes-file build/changelog.md \
--title 2.0.0
-
Nothing is impossible!
-
Open an issue and let's make the generator better together!
-
Bug reports, feature requests, patches, and well-wishes are always welcome. β
- I already use GitHub Releases. Why do I need this?
GitHub Releases is a very good thing. And it's very good practice to maintain it. (Not a lot of people are using it yet!) γοΈ
BTW: I would like to support GitHub Releases in next releases ;)
I'm not trying to compare the quality of handwritten and auto-generated logs. That said....
An auto-generated changelog really helps, even if you manually fill in the release notes!
- I want to define my own label-to-section mapping, how can I do it?
This is possible using either the add-sections or configure-sections
entry in .github_changelog_generator. For example, to add a single new
entry called "Maintenance" that will catch PRs tagged with your maintenance
label, you can add to .github_changelog_generator the line:
add-sections= {"maintenance":{"prefix":"**Project maintenance**","labels":["maintenance"]}}
A similar approach can be used via configure-sections to set all section
properties (including adding new ones!).
- My Ruby version is very old, can I use this?
When your Ruby is old, and you don't want to upgrade, and you want to control which libraries you use, you can use Bundler.
In a Gemfile, perhaps in a non-deployed :development group, add this
gem:
group :development do
gem 'github_changelog_generator', require: false
endThen you can keep back dependencies like rack, which currently is only compatible with Ruby >= 2.2.2. So, use an older version for your app by adding a line like this to the Gemfile:
gem 'rack', '~> 1.6'
This way, you can keep on using github_changelog_generator, even if you can't get the latest version of Ruby installed.
- Windows: 1.14.x wants to create a file on an invalid path. Why?
Workaround: Create a C:\tmp.
Would you like to contribute to this project? CONTRIBUTING.md has all the details on how to do that.
Join the chat at gitter : github-changelog-generator
GitHub Changelog Generator is released under the MIT License.
