Preview the semantic release notes that would result from merging a Github PR.
This set of semantic-release
plugins will post a Github PR comment with a preview of the release that would result from merging.
npm install -D semantic-release@next semantic-release-github-pr
npx semantic-release-github-pr
It helps to think about semantic-release-github-pr
as a variation on semantic-release
's default behavior, using the latter's plugin system to modify some behaviors:
-
If a new release would result from running
semantic-release
, instead of publishing a new release of a package tonpm
, it posts a comment with the changelog to matching Github PRs. -
It posts a static message when there's no release (for clarity).
-
It cleans up any PR comments it previously made (to keep from flooding PRs or leaving outdated information).
A PR gets a comment if:
-
The PR's "from" branch matches the current branch (that this command is being run against).
To cover multiple CI scenarios (see below), either of:
- The PR's test merge commit matches the current branch's
git
HEAD. - The PR and the current branch have the same
git
HEAD.
- The PR's test merge commit matches the current branch's
-
The PR's base branch matches
master
(default) unless thegithubPr.branch
configuration option is set.
It is assumed the user is already fully familiar with semantic-release
and its workflow
.
Github authentication must be configured, exactly the same as for semantic-relase
's default @semantic-release/github
plugin.
It's possible to configure the expected base branch when matching a PR.
E.g., package.json
:
{
"release": {
"githubPr": {
"branch": "staging"
}
}
}
Due to limitations in how plugins may be composed, semantic-release-github-pr
must unfortunately hard-code the analyzeCommits
and generateNotes
plugins (see discussion here).
Users may still want to define a custom versions of these plugins, or want to pass options to the default implementations. To work around this problem, set the desired configuration in the release plugin config inside the githubPr
key instead.
E.g., package.json
:
{
"release": {
"githubPr": {
"analyzeCommits": "myCommitsAnalyzer",
"generateNotes": "myGenerateNotes"
}
}
}
This plugin is best used with a CI build process to fully automate the posting of comments in Github PRs. Ideally, it should run whenever a PR is opened/updated.
To only run when necessary, we use the $TRAVIS_PULL_REQUEST
environment variable to detect whether the build is a "pull request build".
after_success:
- "[[ $TRAVIS_PULL_REQUEST != 'false' ]] && npx semantic-release-github-pr || exit 0"
To run only when necessary, we use the $CI_PULL_REQUEST
environment variable to detect whether the build has a corresponding pull request.
Unfortunately, CircleCI only supports building on push, not when a PR is created. This limits the usefulness of the plugin somewhat, as a build will have to be triggered manually after a PR is opened for the changelog to post.
post:
- "[[ $CI_PULL_REQUEST != '' ]] && npx semantic-release-github-pr || exit 0"
Running semantic-release-github-pr
is equivalent to running semantic-release
with the following configuration (as encapsulated in the semantic-release-github-pr
command):
{
"release": {
"verifyConditions": "@semantic-release/github",
"analyzeCommits": "semantic-release-github-pr",
"generateNotes": "semantic-release-github-pr"
}
}
The @semantic-release/github
plugin is set as a default.
Used as a hook to clean up previous changelog PR comments made by the generateNotes
plugin, keeping it from flooding a PR with (eventually stale) changelog comments over time.
If semantic-release
determines that there's no new version, this plugin will also post a "no release" comment on a matching PR.
This plugin doesn't actually analyze commits to determine when to make a release, but defers to the plugin it decorates (@semantic-release/commit-analyzer
by default).
See the Release config
section for how to configure a custom analyzeCommits
plugin and/or set options.
Creates a comment on matching PRs with the changelog for the release that would result from merging.
This plugin doesn't actually generate the changelog that ends up in the PR comment, but defers to the plugin it decorates (@semantic-release/release-notes-generator
by default).
See the Release config
section for how to configure a custom generateNotes
plugin and/or set options.