Skip to content
auto Logo

changelog

Prepend release notes to CHANGELOG.md, create one if it doesn't exist, and commit the changes.

Options

FlagTypeDescription
--dry-run, -dBooleanReport what command will do but do not actually do anything
--no-version-prefixBooleanUse the version as the tag without the 'v' prefix. WARNING: some plugins might need extra config to use this option (ex: npm)
--nameStringGit name to commit with. Defaults to package definition for the platform
--emailStringGit email to commit with. Defaults to package definition for the platform
--fromStringTag to start changelog generation on. Defaults to latest tag.
--toStringTag to end changelog generation on. Defaults to HEAD.
--titleStringOverride the title used in the addition to the CHANGELOG.md.
--message, -mStringMessage to commit the changelog with. Defaults to 'Update CHANGELOG.md [skip ci]'
--base-branchStringBranch to treat as the base branch
--quiet, -qBooleanPrint only the result of the command

Examples

Generate a changelog from the last release to head

auto changelog
auto changelog

Generate a changelog across specific versions

auto changelog --from v0.20.1 --to v0.21.0
auto changelog --from v0.20.1 --to v0.21.0

Configurable Options

You can configure some of the options for the changelog command in the .autorc.

  • message

Example .autorc:

{
  "changelog": {
    "message": "string"
  }
}
{
  "changelog": {
    "message": "string"
  }
}

⚠️ This should be run before you version your project so the CHANGELOG.md changes are committed before the release gets tagged.

Changelog Titles

You can customize the changelog titles and even add custom ones. To see configuration go here.

Additional Release notes

Sometimes a PR title is just not enough to capture what a user should know about that PR. That's why we've included the ability to put extra release notes right in your PRs. All you have to do is add a Release Notes section in your PR.

Take the following PR body:

# What Changed

Change `shipit` behavior.

## Release Notes

`auto shipit` will only ship to `latest` on the base branch ([which is configurable]()). If ran locally or from a PR it will create a `canary` release that doesn't interfere with your `latest` release.
# What Changed

Change `shipit` behavior.

## Release Notes

`auto shipit` will only ship to `latest` on the base branch ([which is configurable]()). If ran locally or from a PR it will create a `canary` release that doesn't interfere with your `latest` release.

This will create a special section at the top of the changelog that collects all the additional release notes from merged PRs. Below is a sample of what it might look like.

v5.0.0 (Sat May 04 2019)

Release Notes

From #371

auto shipit will only ship to latest on the base branch (which is configurable). If ran locally or from a PR it will create a canary release that doesn't interfere with your latest release.

💥 Breaking Change

Authors: 1