1.2.1 • Published 6 years ago

semantic-release-git-branches v1.2.1

Weekly downloads
407
License
MIT
Repository
github
Last release
6 years ago

Git Branches - Semantic Release

Latest Release Build Status Codecov coverage Code Climate grade

A fork of @semantic-release/git which uses the git flow approach for releases.

verifyConditions

Verify the access to the remote Git repository, the commit message format and the assets option configuration.

prepare

Create a release commit, including configurable files.

Configuration

Environment variables

VariableDescriptionDefault
GIT_AUTHOR_NAMEThe author name associated with the release commit. See Git environment variables.@semantic-release-bot.
GIT_AUTHOR_EMAILThe author email associated with the release commit. See Git environment variables.@semantic-release-bot email address.
GIT_COMMITTER_NAMEThe committer name associated with the release commit. See Git environment variables.@semantic-release-bot.
GIT_COMMITTER_EMAILThe committer email associated with the release commit. See Git environment variables.@semantic-release-bot email address.

Options

OptionsDescriptionDefault
messageThe message for the release commit. See message.chore: create new release ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}
assetsFiles to include in the release commit. See assets.['CHANGELOG.md', 'package.json', 'package-lock.json', 'npm-shrinkwrap.json']
branchNameThe name of the release branch.release/${nextRelease.version}
branchPushIf the release branch should be pushed to remote.false
branchMergesAll branches that will receive a release branch merge.[branch]

message

The message for the release commit is generated with Lodash template. The following variables are available:

ParameterDescription
branchThe branch from which the release is done.
lastReleaseObject with version, gitTag and gitHead of the last release.
nextReleaseObject with version, gitTag, gitHead and notes of the release being done.

It is recommended to include [skip ci] in the commit message to not trigger a new build. Note: Some CI service support the [skip ci] keyword only in the subject of the message.

message examples

The message Release ${nextRelease.version} - ${new Date().toLocaleDateString('en-US', {year: 'numeric', month: 'short', day: 'numeric', hour: 'numeric', minute: 'numeric' })} [skip ci]\n\n${nextRelease.notes} will generate the commit message:

Release v1.0.0 - Oct. 21, 2015 1:24 AM [skip ci]## 1.0.0### Features* Generate 1.21 gigawatts of electricity...

assets

Can be an Array or a single entry. Each entry can be either:

  • a glob
  • or an Object with a path property containing a glob.

Each entry in the assets Array is globbed individually. A glob can be a String ("dist/**/*.js" or "dist/mylib.js") or an Array of Strings that will be globbed together (["dist/**", "!**/*.css"]).

If a directory is configured, all the files under this directory and its children will be included.

If a file has a match in .gitignore it will always be excluded.

assets examples

'dist/*.js': include all js files in the dist directory, but not in its sub-directories.

'dist/**/*.js': include all js files in the dist directory and its sub-directories.

[['dist', '!**/*.css']]: include all files in the dist directory and its sub-directories excluding the css files.

[['dist', '!**/*.css'], 'package.json']: include package.json and all files in the dist directory and its sub-directories excluding the css files.

[['dist/**/*.{js,css}', '!**/*.min.*']]: include all js and css files in the dist directory and its sub-directories excluding the minified version.

Usage

Options can be set within the plugin definition in the Semantic-release configuration file:

{
  "release": {
    "prepare": [
      "@semantic-release/npm",
      {
        "path": "semantic-release-git-branches",
        "assets": ["package.json", "dist/**/*.{js|css}", "docs"],
        "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
      }
    ],
    "publish": ["@semantic-release/github"]
  }
}

When using with the changelog or npm plugins:

  • The changelog plugin must be called first in order to update the changelog file so the gitflow and npm plugin can include it in the release.
  • The npm plugin must be called second in order to update the package.json file so the gitflow plugin can include it in the release commit.

To use with the changelog and npm plugins:

{
  "release": {
    "verifyConditions": ["@semantic-release/changelog", "@semantic-release/npm", "semantic-release-git-branches"],
    "prepare": ["@semantic-release/changelog", "@semantic-release/npm", "semantic-release-git-branches"]
  }
}