# Introduction
đŠđ semantic-release
Fully automated version management and package publishing
[](https://github.com/semantic-release/semantic-release/discussions) [](https://github.com/semantic-release/semantic-release/actions?query=workflow%3ATest+branch%3Amaster) [](#badge)
[](https://www.npmjs.com/package/semantic-release) [](https://www.npmjs.com/package/semantic-release) [](https://www.npmjs.com/package/semantic-release)
**semantic-release** automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org) specification.
> Trust us, this will change your workflow for the better. â [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release)
## Highlights
* Fully automated release
* Enforce [Semantic Versioning](https://semver.org) specification
* New features and fixes are immediately available to users
* Notify maintainers and users of new releases
* Use formalized commit message convention to document changes in the codebase
* Publish on different distribution channels (such as [npm dist-tags](https://docs.npmjs.com/cli/dist-tag)) based on git merges
* Integrate with your [continuous integration workflow](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations)
* Avoid potential errors associated with manual releases
* Support any [package managers and languages](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#package-managers-and-languages) via [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins)
* Simple and reusable configuration via [shareable configurations](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations)
## How does it work?
### Commit message format
**semantic-release** uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publishes the release.
By default **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format). The commit message format can be changed with the [`preset` or `config` options](https://semantic-release.gitbook.io/semantic-release/usage/configuration#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins.
Tools such as [commitizen](https://github.com/commitizen/cz-cli) or [commitlint](https://github.com/conventional-changelog/commitlint) can be used to help contributors and enforce valid commit messages.
The table below shows which commit message gets you which release type when `semantic-release` runs (using the default configuration):
| Commit message | Release type |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |
| `fix(pencil): stop graphite breaking when too much pressure applied` | Patch Release |
| `feat(pencil): add 'graphiteWidth' option` | ~~Minor~~ Feature Release |
| perf(pencil): remove graphiteWidth optionBREAKING CHANGE: The graphiteWidth option has been removed.The default graphite width of 10mm is always used for performance reasons.
| ~~Major~~ Breaking Release |
### Automation with CI
**semantic-release** is meant to be executed on the CI environment after every successful build on the release branch. This way no human is directly involved in the release process and the releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org).
### Triggering a release
For each new commits added to one of the release branches (for example `master`, `next`, `beta`), with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities.
**semantic-release** offers various ways to control the timing, the content and the audience of published releases. See example workflows in the following recipes:
* [Using distribution channels](https://github.com/semantic-release/semantic-release/tree/f01edb8308effce41aadc451c9ebbde4fd2355d4/docs/recipes/distribution-channels.md#publishing-on-distribution-channels)
* [Maintenance releases](https://github.com/semantic-release/semantic-release/tree/f01edb8308effce41aadc451c9ebbde4fd2355d4/docs/recipes/maintenance-releases.md#publishing-maintenance-releases)
* [Pre-releases](https://github.com/semantic-release/semantic-release/tree/f01edb8308effce41aadc451c9ebbde4fd2355d4/docs/recipes/pre-releases.md#publishing-pre-releases)
### Release steps
After running the tests, the command `semantic-release` will execute the following steps:
| Step | Description |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Verify Conditions | Verify all the conditions to proceed with the release. |
| Get last release | Obtain the commit corresponding to the last release by analyzing [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). |
| Analyze commits | Determine the type of release based on the commits added since the last release. |
| Verify release | Verify the release conformity. |
| Generate notes | Generate release notes for the commits added since the last release. |
| Create Git tag | Create a Git tag corresponding to the new release version. |
| Prepare | Prepare the release. |
| Publish | Publish the release. |
| Notify | Notify of new releases or errors. |
## Requirements
In order to use **semantic-release** you need:
* To host your code in a [Git repository](https://git-scm.com)
* Use a Continuous Integration service that allows you to [securely set up credentials](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication)
* Git CLI version [2.7.1 or higher](https://semantic-release.gitbook.io/semantic-release/support/faq#why-does-semantic-release-require-git-version--271) installed in your Continuous Integration environment
* [Node.js](https://nodejs.org) version [14.17 or higher](https://semantic-release.gitbook.io/semantic-release/support/faq#why-does-semantic-release-require-node-version--1417) installed in your Continuous Integration environment
## Documentation
* Usage
* [Getting started](https://semantic-release.gitbook.io/semantic-release/usage/getting-started#getting-started)
* [Installation](https://semantic-release.gitbook.io/semantic-release/usage/installation#installation)
* [CI Configuration](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#ci-configuration)
* [Configuration](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration)
* [Plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins)
* [Workflow configuration](https://semantic-release.gitbook.io/semantic-release/usage/workflow-configuration)
* [Shareable configurations](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations)
* Extending
* [Plugins](https://semantic-release.gitbook.io/semantic-release/extending/plugins-list)
* [Shareable configuration](https://semantic-release.gitbook.io/semantic-release/extending/shareable-configurations-list)
* Recipes
* [CI configurations](https://semantic-release.gitbook.io/semantic-release/recipes/recipes)
* [Git hosted services](https://semantic-release.gitbook.io/semantic-release/recipes/recipes)
* [Release workflow](https://semantic-release.gitbook.io/semantic-release/recipes/recipes)
* [Package managers and languages](https://semantic-release.gitbook.io/semantic-release/recipes/recipes)
* Developer guide
* [JavaScript API](https://semantic-release.gitbook.io/semantic-release/developer-guide/js-api)
* [Plugins development](https://semantic-release.gitbook.io/semantic-release/developer-guide/plugin)
* [Shareable configuration development](https://semantic-release.gitbook.io/semantic-release/developer-guide/shareable-configuration)
* Support
* [Resources](https://semantic-release.gitbook.io/semantic-release/support/resources)
* [Frequently Asked Questions](https://semantic-release.gitbook.io/semantic-release/support/faq)
* [Troubleshooting](https://semantic-release.gitbook.io/semantic-release/support/troubleshooting)
* [Node version requirement](https://semantic-release.gitbook.io/semantic-release/support/node-version)
* [Node Support Policy](https://semantic-release.gitbook.io/semantic-release/support/node-support-policy)
## Get help
* [Stack Overflow](https://stackoverflow.com/questions/tagged/semantic-release)
* [GitHub Discussions](https://github.com/semantic-release/semantic-release/discussions)
* [Twitter](https://twitter.com/SemanticRelease)
## Badge
Let people know that your package is published using **semantic-release** by including this badge in your readme.
[](https://github.com/semantic-release/semantic-release)
```
[](https://github.com/semantic-release/semantic-release)
```
## Team
| [](https://github.com/gr2m) | [](https://github.com/pvdlg) | [](https://github.com/travi) |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- |
| [Gregor Martynus](https://github.com/gr2m) | [Pierre Vanduynslager](https://github.com/pvdlg) | [Matt Travi](https://github.com/travi) |
## Alumni
| [](https://github.com/boennemann) | [](https://github.com/relekang) | [](https://github.com/jo) | [](https://github.com/finnp) | [](https://github.com/christophwitzko) |
| ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| [Stephan Bönnemann](https://github.com/boennemann) | [Rolf Erik Lekang](https://github.com/relekang) | [Johannes Jörg Schmidt](https://github.com/jo) | [Finn Pauls](https://github.com/finnp) | [Christoph Witzko](https://github.com/christophwitzko) |
# Getting started
In order to use **semantic-release** you must follow these steps:
1. [Install](https://semantic-release.gitbook.io/semantic-release/installation#installation) **semantic-release** in your project
2. Configure your Continuous Integration service to [run **semantic-release**](https://semantic-release.gitbook.io/semantic-release/ci-configuration#run-semantic-release-only-after-all-tests-succeeded)
3. Configure your Git repository and package manager repository [authentication](https://semantic-release.gitbook.io/semantic-release/ci-configuration#authentication) in your Continuous Integration service
4. Configure **semantic-release** [options and plugins](https://semantic-release.gitbook.io/semantic-release/configuration#configuration)
Alternatively those steps can be easily done with the [**semantic-release** interactive CLI](https://github.com/semantic-release/cli):
```bash
cd your-module
npx semantic-release-cli setup
```
See the [semantic-release-cli](https://github.com/semantic-release/cli#what-it-does) documentation for more details.
**Note**: only a limited number of options, CI services and plugins are currently supported by `semantic-release-cli`.
# Installation
## Local installation
For [Node modules projects](https://docs.npmjs.com/getting-started/creating-node-modules) we recommend installing **semantic-release** locally and running the `semantic-release` command with [npx](https://www.npmjs.com/package/npx):
```bash
$ npm install --save-dev semantic-release
```
Then in the CI environment:
```bash
$ npx semantic-release
```
**Note:** `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently find the semantic-release binary and to execute it. See [What is npx](https://semantic-release.gitbook.io/semantic-release/support/faq#what-is-npx) for more details.
## Global installation
For other type of projects we recommend installing **semantic-release** directly in the CI environment, also with [npx](https://www.npmjs.com/package/npx):
```bash
$ npx semantic-release
```
**Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@18`). This way your build will not automatically use the next major **semantic-release** release that could possibly break your build. You will have to upgrade manually when a new major version is released.
**Note**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it. See [What is npx](https://semantic-release.gitbook.io/semantic-release/support/faq#what-is-npx) for more details.
# CI Configuration
## Run `semantic-release` only after all tests succeeded
The `semantic-release` command must be executed only after all the tests in the CI build pass. If the build runs multiple jobs (for example to test on multiple Operating Systems or Node versions) the CI has to be configured to guarantee that the `semantic-release` command is executed only after all jobs are successful. Here is a few example of the CI services that can be used to achieve this:
* [Travis Build Stages](https://docs.travis-ci.com/user/build-stages)
* [CircleCI Workflows](https://circleci.com/docs/2.0/workflows)
* [GitHub Actions](https://github.com/features/actions)
* [Codeship Deployment Pipelines](https://documentation.codeship.com/basic/builds-and-configuration/deployment-pipelines)
* [GitLab Pipelines](https://docs.gitlab.com/ce/ci/introduction/)
* [Codefresh Pipelines](https://codefresh.io/docs/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines)
* [Wercker Workflows](http://devcenter.wercker.com/docs/workflows)
* [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline).
See [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details.
## Authentication
### Push access to the remote repository
**semantic-release** requires push access to the project Git repository in order to create [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). The Git authentication can be set with one of the following environment variables:
| Variable | Description |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `GH_TOKEN` or `GITHUB_TOKEN` | A GitHub [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line). |
| `GL_TOKEN` or `GITLAB_TOKEN` | A GitLab [personal access token](https://docs.gitlab.com/ce/user/profile/personal_access_tokens.html). |
| `BB_TOKEN` or `BITBUCKET_TOKEN` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html). |
| `BB_TOKEN_BASIC_AUTH` or `BITBUCKET_TOKEN_BASIC_AUTH` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) with basic auth support. For clearification `user:token` has to be the value of this env. |
| `GIT_CREDENTIALS` | [URL encoded](https://en.wikipedia.org/wiki/Percent-encoding) Git username and password in the format `:`. The username and password must each be individually URL encoded, not the `:` separating them. |
Alternatively the Git authentication can be set up via [SSH keys](https://semantic-release.gitbook.io/semantic-release/recipes/git-hosted-services/git-auth-ssh-keys).
### Authentication for plugins
Most **semantic-release** [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins) require setting up authentication in order to publish to a package manager registry. The default [@semantic-release/npm](https://github.com/semantic-release/npm#environment-variables) and [@semantic-release/github](https://github.com/semantic-release/github#environment-variables) plugins require the following environment variables:
| Variable | Description |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `NPM_TOKEN` | npm token created via npm token create .Note : Only the auth-only level of npm two-factor authentication is supported.
|
| `GH_TOKEN` | GitHub authentication token.Note : Only the personal token authentication is supported.
|
See each plugin's documentation for the environment variables required.
The authentication token/credentials have to be made available in the CI service via environment variables.
See [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details on how to configure environment variables in your CI service.
**Note**: The environment variables `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN` and `GITLAB_TOKEN` can be used for both the Git authentication and the API authentication required by [@semantic-release/github](https://github.com/semantic-release/github) and [@semantic-release/gitlab](https://github.com/semantic-release/gitlab).
# Configuration
**semantic-release** configuration consists of:
* Git repository ([URL](#repositoryurl) and options [release branches](#branches) and [tag format](#tagformat))
* Plugins [declaration](#plugins) and options
* Run mode ([debug](#debug), [dry run](#dryrun) and [local (no CI)](#ci))
All of these options can be configured through config file, CLI arguments or by extending a [shareable configuration](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations).
Additionally, metadata of Git tags generated by **semantic-release** can be customized via standard [Git environment variables](#git-environment-variables).
## Configuration file
**semantic-release**âs [options](#options), mode and [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins) can be set via either:
* A `.releaserc` file, written in YAML or JSON, with optional extensions: .`yaml`/`.yml`/`.json`/`.js`
* A `release.config.js` file that exports an object
* A `release` key in the project's `package.json` file
Alternatively, some options can be set via CLI arguments.
The following three examples are the same.
* Via `release` key in the project's `package.json` file:
```javascript
{
"release": {
"branches": ["master", "next"]
}
}
```
* Via `.releaserc` file:
```javascript
{
"branches": ["master", "next"]
}
```
* Via CLI argument:
```bash
$ semantic-release --branches next
```
**Note**: CLI arguments take precedence over options configured in the configuration file.
**Note**: Plugin options cannot be defined via CLI arguments and must be defined in the configuration file.
**Note**: When configuring via `package.json`, the configuration must be under the `release` property. However, when using a `.releaserc` or a `release.config.js` file, the configuration must be set without a `release` property.
## Options
### extends
Type: `Array`, `String`\
CLI arguments: `-e`, `--extends`
List of modules or file paths containing a [shareable configuration](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations). If multiple shareable configurations are set, they will be imported in the order defined with each configuration option taking precedence over the options defined in a previous shareable configuration.
**Note**: Options defined via CLI arguments or in the configuration file will take precedence over the ones defined in any shareable configuration.
### branches
Type: `Array`, `String`, `Object`\
Default: `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`\
CLI arguments: `--branches`
The branches on which releases should happen. By default **semantic-release** will release:
* regular releases to the default distribution channel from the branch `master`
* regular releases to a distribution channel matching the branch name from any existing branch with a name matching a maintenance release range (`N.N.x` or `N.x.x` or `N.x` with `N` being a number)
* regular releases to the `next` distribution channel from the branch `next` if it exists
* regular releases to the `next-major` distribution channel from the branch `next-major` if it exists
* prereleases to the `beta` distribution channel from the branch `beta` if it exists
* prereleases to the `alpha` distribution channel from the branch `alpha` if it exists
**Note**: If your repository does not have a release branch, then **semantic-release** will fail with an `ERELEASEBRANCHES` error message. If you are using the default configuration, you can fix this error by pushing a `master` branch.
**Note**: Once **semantic-release** is configured, any user with the permission to push commits on one of those branches will be able to publish a release. It is recommended to protect those branches, for example with [GitHub protected branches](https://docs.github.com/github/administering-a-repository/about-protected-branches).
See [Workflow configuration](https://semantic-release.gitbook.io/semantic-release/workflow-configuration#workflow-configuration) for more details.
### repositoryUrl
Type: `String`\
Default: `repository` property in `package.json` or [git origin url](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes)\
CLI arguments: `-r`, `--repository-url`
The git repository URL.
Any valid git url format is supported (See [Git protocols](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols)).
### tagFormat
Type: `String`\
Default: `v${version}`\
CLI arguments: `-t`, `--tag-format`
The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) format used by **semantic-release** to identify releases. The tag name is generated with [Lodash template](https://lodash.com/docs#template) and will be compiled with the `version` variable.
**Note**: The `tagFormat` must contain the `version` variable exactly once and compile to a [valid Git reference](https://git-scm.com/docs/git-check-ref-format#_description).
### plugins
Type: `Array`\
Default: `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`\
CLI arguments: `-p`, `--plugins`
Define the list of plugins to use. Plugins will run in series, in the order defined, for each [steps](https://semantic-release.gitbook.io/semantic-release/undefined#release-steps) if they implement it.
Plugins configuration can defined by wrapping the name and an options object in an array.
See [Plugins configuration](https://semantic-release.gitbook.io/semantic-release/plugins#plugins) for more details.
### dryRun
Type: `Boolean`\
Default: `false` if running in a CI environment, `true` otherwise\
CLI arguments: `-d`, `--dry-run`
The objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, success and fail. In addition to this it prints the next version and release notes to the console.
**Note**: The Dry-run mode verifies the repository push permission, even though nothing will be pushed. The verification is done to help user to figure out potential configuration issues.
### ci
Type: `Boolean`\
Default: `true`\
CLI arguments: `--ci` / `--no-ci`
Set to `false` to skip Continuous Integration environment verifications. This allows for making releases from a local machine.
**Note**: The CLI arguments `--no-ci` is equivalent to `--ci false`.
### debug
Type: `Boolean`\
Default: `false`\
CLI argument: `--debug`
Output debugging information. This can also be enabled by setting the `DEBUG` environment variable to `semantic-release:*`.
**Note**: The `debug` is used only supported via CLI argument. To enable debug mode from the [JS API](https://semantic-release.gitbook.io/semantic-release/developer-guide/js-api#javascript-api) use `require('debug').enable('semantic-release:*')`.
## Git environment variables
| Variable | Description | Default |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------ |
| `GIT_AUTHOR_NAME` | The author name associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot. |
| `GIT_AUTHOR_EMAIL` | The author email associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot email address. |
| `GIT_COMMITTER_NAME` | The committer name associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot. |
| `GIT_COMMITTER_EMAIL` | The committer email associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot email address. |
## Existing version tags
**semantic-release** uses [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) to determine the commits added since the last release. If a release has been published before setting up **semantic-release** you must make sure the most recent commit included in the last published release is in the [release branches](#branches) history and is tagged with the version released, formatted according to the [tag format](#tagformat) configured (defaults to `vx.y.z`).
If the previous releases were published with [`npm publish`](https://docs.npmjs.com/cli/publish) this should already be the case.
For example, if your release branch is `master`, the last release published on your project is `1.1.0` and the last commit included has the sha `1234567`, you must make sure this commit is in `master` history and is tagged with `v1.1.0`.
```bash
# Make sure the commit 1234567 is in the release branch history
$ git branch --contains 1234567
# If the commit is not in the branch history it means that either:
# - you use a different branch than the one your release from before
# - or the commit sha has been rewritten (with git rebase)
# In both cases you need to configure your repository to have the last release commit in the history of the release branch
# List the tags for the commit 1234567
$ git tag --contains 1234567
# If v1.1.0 is not in the list you add it with
$ git tag v1.1.0 1234567
$ git push origin v1.1.0
```
# Plugins
Each [release step](https://semantic-release.gitbook.io/semantic-release/undefined#release-steps) is implemented by configurable plugins. This allows for support of different [commit message formats](https://semantic-release.gitbook.io/semantic-release/undefined#commit-message-format), release note generators and publishing platforms.
A plugin is a npm module that can implement one or more of the following steps:
| Step | Required | Description |
| ------------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `verifyConditions` | No | Responsible for verifying conditions necessary to proceed with the release: configuration is correct, authentication token are valid, etc... |
| `analyzeCommits` | Yes | Responsible for determining the type of the next release (`major`, `minor` or `patch`). If multiple plugins with a `analyzeCommits` step are defined, the release type will be the highest one among plugins output. |
| `verifyRelease` | No | Responsible for verifying the parameters (version, type, dist-tag etc...) of the release that is about to be published. |
| `generateNotes` | No | Responsible for generating the content of the release note. If multiple plugins with a `generateNotes` step are defined, the release notes will be the result of the concatenation of each plugin output. |
| `prepare` | No | Responsible for preparing the release, for example creating or updating files such as `package.json`, `CHANGELOG.md`, documentation or compiled assets and pushing a commit. |
| `publish` | No | Responsible for publishing the release. |
| `addChannel` | No | Responsible for adding a release channel (e.g. adding an npm dist-tag to a release). |
| `success` | No | Responsible for notifying of a new release. |
| `fail` | No | Responsible for notifying of a failed release. |
Release steps will run in that order. At each step, **semantic-release** will run every plugin in the [`plugins` array](#plugins-declaration-and-execution-order), as long as the plugin implements the step.
**Note:** If no plugin with a `analyzeCommits` step is defined `@semantic-release/commit-analyzer` will be used.
## Plugins installation
### Default plugins
These four plugins are already part of **semantic-release** and are listed in order of execution. They do not have to be installed separately:
```
"@semantic-release/commit-analyzer"
"@semantic-release/release-notes-generator"
"@semantic-release/npm"
"@semantic-release/github"
```
### Additional plugins
[Additional plugins](https://semantic-release.gitbook.io/semantic-release/extending/plugins-list) have to be installed via npm:
```bash
$ npm install @semantic-release/git @semantic-release/changelog -D
```
## Plugins declaration and execution order
Each plugin must be configured with the [`plugins` options](https://semantic-release.gitbook.io/semantic-release/configuration#plugins) by specifying the list of plugins by npm module name.
```javascript
{
"plugins": ["@semantic-release/commit-analyzer", "@semantic-release/release-notes-generator", "@semantic-release/npm"]
}
```
**Note:** If the `plugins` option is defined, it overrides the default plugin list, rather than merging with it.
For each [release step](https://semantic-release.gitbook.io/semantic-release/undefined#release-steps) the plugins that implement that step will be executed in the order in which they are defined.
```javascript
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/npm",
"@semantic-release/git"
]
}
```
With this configuration **semantic-release** will:
* execute the `verifyConditions` implementation of `@semantic-release/npm` then `@semantic-release/git`
* execute the `analyzeCommits` implementation of `@semantic-release/commit-analyzer`
* execute the `generateNotes` implementation of `@semantic-release/release-notes-generator`
* execute the `prepare` implementation of `@semantic-release/npm` then `@semantic-release/git`
* execute the `publish` implementation of `@semantic-release/npm`
Order is first determined by release steps (such as `verifyConditions` â `anayzeCommits`). At each release step, plugins are executed in the order in which they are defined.
## Plugin options configuration
A plugin configuration can be specified by wrapping the name and an options object in an array. Options configured this way will be passed only to that specific plugin.
Global plugin configuration can be defined at the root of the **semantic-release** configuration object. Options configured this way will be passed to all plugins.
```javascript
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
["@semantic-release/github", {
"assets": ["dist/**"]
}],
"@semantic-release/git"
],
"preset": "angular"
}
```
With this configuration:
* All plugins will receive the `preset` option, which will be used by both `@semantic-release/commit-analyzer` and `@semantic-release/release-notes-generator` (and ignored by `@semantic-release/github` and `@semantic-release/git`)
* The `@semantic-release/github` plugin will receive the `assets` options (`@semantic-release/git` will not receive it and therefore will use it's default value for that option)
# Workflow configuration
**semantic-release** allow to manage and automate complex release workflow, based on multiple Git branches and distribution channels. This allow to:
* Distributes certain releases to a particular group of users via distribution channels
* Manage the availability of releases on distribution channels via branches merge
* Maintain multiple lines of releases in parallel
* Work on large future releases outside the normal flow of one version increment per Git push
See [Release workflow recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#release-workflow) for detailed examples.
The release workflow is configured via the [branches option](https://semantic-release.gitbook.io/semantic-release/configuration#branches) which accepts a single or an array of branch definitions. Each branch can be defined either as a string, a [glob](https://github.com/micromatch/micromatch#matching-features) or an object. For string and glob definitions each [property](#branches-properties) will be defaulted.
A branch can defined as one of three types:
* [release](#release-branches): to make releases on top of the last version released
* [maintenance](#maintenance-branches): to make releases on top of an old release
* [pre-release](#pre-release-branches): to make pre-releases
The type of the branch is automatically determined based on naming convention and/or [properties](#branches-properties).
## Branches properties
| Property | Branch type | Description | Default |
| ------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| `name` | All | **Required.** The Git branch holding the commits to analyze and the code to release. See [name](#name). | - The value itself if defined as a `String` or the matching branches name if defined as a glob. |
| `channel` | All | The distribution channel on which to publish releases from this branch. Set to `false` to force the default distribution channel instead of using the default. See [channel](#channel). | `undefined` for the first release branch, the value of `name` for subsequent ones. |
| `range` | [maintenance](#maintenance-branches) only | **Required unless `name` is formatted like `N.N.x` or `N.x` (`N` is a number).** The range of [semantic versions](https://semver.org) to support on this branch. See [range](#range). | The value of `name`. |
| `prerelease` | [pre-release](#pre-release-branches) only | **Required.** The pre-release denotation to append to [semantic versions](https://semver.org) released from this branch. See [prerelease](#prerelease). | - |
### name
A `name` is required for any type of branch. It can be defined as a [glob](https://github.com/micromatch/micromatch#matching-features) in which case the definition will be expanded to one per matching branch existing in the repository.
If `name` doesn't match to any branch existing in the repository, the definition will be ignored. For example the default configuration includes the definition `next` and `next-major` which will become active only when the branches `next` and/or `next-major` are created in the repository. This allow to define your workflow once with all potential branches you might use and have the effective configuration evolving as you create new branches.
For example the configuration `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next']` will be expanded as:
```javascript
{
branches: [
{name: '1.x', range: '1.x', channel: '1.x'}, // Only after the `1.x` is created in the repo
{name: '2.x', range: '2.x', channel: '2.x'}, // Only after the `2.x` is created in the repo
{name: 'master'},
{name: 'next', channel: 'next'}, // Only after the `next` is created in the repo
]
}
```
### channel
The `channel` can be defined for any branch type. By default releases will be done on the default distribution channel (for example the `@latest` [dist-tag](https://docs.npmjs.com/cli/dist-tag) for npm) for the first [release branch](#release-branches) and on a distribution channel named based on the branch `name` for any other branch. If the `channel` property is set to `false` the default channel will be used.
The value of `channel`, if defined as a string, is generated with [Lodash template](https://lodash.com/docs#template) with the variable `name` available.
For example the configuration `['master', {name: 'next', channel: 'channel-${name}'}]` will be expanded as:
```javascript
{
branches: [
{name: 'master'}, // `channel` is undefined so the default distribution channel will be used
{name: 'next', channel: 'channel-next'}, // `channel` is built with the template `channel-${name}`
]
}
```
### range
A `range` only applies to maintenance branches, is required and must be formatted like `N.N.x` or `N.x` (`N` is a number). In case the `name` is formatted as a range (for example `1.x` or `1.5.x`) the branch will be considered a maintenance branch and the `name` value will be used for the `range`.
For example the configuration `['1.1.x', '1.2.x', 'master']` will be expanded as:
```javascript
{
branches: [
{name: '1.1.x', range: '1.1.x', channel: '1.1.x'},
{name: '1.2.x', range: '1.2.x', channel: '1.2.x'},
{name: 'master'},
]
}
```
### prerelease
A `prerelease` property applies only to pre-release branches and the `prerelease` value must be valid per the [Semantic Versioning Specification](https://semver.org/#spec-item-9). It will determine the name of versions (for example if `prerelease` is set to `beta` the version be formatted like `2.0.0-beta.1`, `2.0.0-beta.2` etc...). If the `prerelease` property is set to `true` the `name` value will be used.
The value of `prerelease`, if defined as a string, is generated with [Lodash template](https://lodash.com/docs#template) with the variable `name` available.
For example the configuration `['master', {name: 'pre/rc', prerelease: '${name.replace(/^pre\\//g, "")}'}, {name: 'beta', prerelease: true}]` will be expanded as:
```javascript
{
branches: [
{name: 'master'},
{name: 'pre/rc', channel: 'pre/rc', prerelease: 'rc'}, // `prerelease` is built with the template `${name.replace(/^pre\\//g, "")}`
{name: 'beta', channel: 'beta', prerelease: 'beta'}, // `prerelease` is set to `beta` as it is the value of `name`
]
}
```
## Branch types
### Release branches
A release branch is the base type of branch used by **semantic-release** that allows to publish releases with a [semantic version](https://semver.org), optionally on a specific distribution channel. Distribution channels (for example [npm dist-tags](https://docs.npmjs.com/cli/dist-tag) or [Chrome release channels](https://www.chromium.org/getting-involved/dev-channel)) are a way to distribute new releases only to a subset of users in order to get early feedback. Later on, those releases can be added to the general distribution channel to be made available to all users.
**semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release branch to another](#merging-into-a-release-branch).
A project must define a minimum of 1 release branch and can have a maximum of 3. The order of the release branch definitions is significant, as versions released on a given branch must always be higher than the last release made on the previous branch. This allow to avoid situation that would lead to an attempt to publish releases with the same version number but different codebase. When multiple release branches are configured and a commit that would create a version conflict is pushed, **semantic-release** will not perform the release and will throw an `EINVALIDNEXTVERSION` error, listing the problematic commits and the valid branches on which to move them.
**Note:** With **semantic-release** as with most package managers, a release version must be unique, independently of the distribution channel on which it is available.
See [publishing on distribution channels recipe](https://github.com/semantic-release/semantic-release/tree/88e423b8286cfe852d8348d174e621c1e39e42d8/docs/recipes/distribution-channels.md) for a detailed example.
#### Pushing to a release branch
With the configuration `"branches": ["master", "next"]`, if the last release published from `master` is `1.0.0` and the last one from `next` is `2.0.0` then:
* Only versions in range `1.x.x` can be published from `master`, so only `fix` and `feat` commits can be pushed to `master`
* Once `next` get merged into `master` the release `2.0.0` will be made available on the channel associated with `master` and both `master` and `next` will accept any commit type
This verification prevent scenario such as: 1. Create a `feat` commit on `next` which triggers the release of version `1.0.0` on the `next` channel 2. Merge `next` into `master` which adds `1.0.0` on the default channel 3. Create a `feat` commit on `next` which triggers the release of version `1.1.0` on the `next` channel 4. Create a `feat` commit on `master` which would attempt to release the version `1.1.0` on the default channel
In step 4 **semantic-release** will throw an `EINVALIDNEXTVERSION` error to prevent the attempt at releasing version `1.1.0` which was already released on step 3 with a different codebase. The error will indicate that the commit should be created on `next` instead. Alternatively if the `next` branch is merged into `master`, the version `1.1.0` will be made available on the default channel and the `feat` commit would be allowed on `master` to release `1.2.0`.
#### Merging into a release branch
When merging commits associated with a release from one release branch to another, **semantic-release** will make the corresponding version available on the channel associated with the target branch.
When merging commits not associated with a release, commits from a [maintenance branch](#maintenance-branches) or commits from a [pre-release branch](#pre-release-branches) **semantic-release** will treat them as [pushed commits](#pushing-to-a-release-branch) and publish a new release if necessary.
### Maintenance branches
A maintenance branch is a type of branch used by **semantic-release** that allows to publish releases with a [semantic version](https://semver.org) on top of the codebase of an old release. This is useful when you need to provide fixes or features to users who cannot upgrade to the last version of your package.
A maintenance branch is characterized by a range which defines the versions that can be published from it. The [`range`](#range) value of each maintenance branch must be unique across the project.
**semantic-release** will always publish releases to a distribution channel specific to the range, so only the users who choose to use that particular line of versions will receive new releases.
Maintenance branches are always considered lower than [release branches](#release-branches) and similarly to them, when a commit that would create a version conflict is pushed, **semantic-release** will not perform the release and will throw an `EINVALIDNEXTVERSION` error, listing the problematic commits and the valid branches on which to move them.
**semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release or maintenance branch to another maintenance branch](#merging-into-a-maintenance-branch), however only versions within the branch `range` can be merged. If a merged version is outside the maintenance branch `range`, **semantic-release** will not add to the corresponding channel and will throw an `EINVALIDMAINTENANCEMERGE` error.
See [publishing maintenance releases recipe](https://github.com/semantic-release/semantic-release/tree/88e423b8286cfe852d8348d174e621c1e39e42d8/docs/recipes/maintenance-releases.md) for a detailed example.
#### Pushing to a maintenance branch
With the configuration `"branches": ["1.0.x", "1.x", "master"]`, if the last release published from `master` is `1.5.0` then:
* Only versions in range `>=1.0.0 <1.1.0` can be published from `1.0.x`, so only `fix` commits can be pushed to `1.0.x`
* Only versions in range `>=1.1.0 <1.5.0` can be published from `1.x`, so only `fix` and `feat` commits can be pushed to `1.x` as long the resulting release is lower than `1.5.0`
* Once `2.0.0` is released from `master`, versions in range `>=1.1.0 <2.0.0` can be published from `1.x`, so any number of `fix` and `feat` commits can be pushed to `1.x`
#### Merging into a maintenance branch
With the configuration `"branches": ["1.0.x", "1.x", "master"]`, if the last release published from `master` is `1.0.0` then:
* Creating the branch `1.0.x` from `master` will make the `1.0.0` release available on the `1.0.x` distribution channel
* Pushing a `fix` commit on the `1.0.x` branch will release the version `1.0.1` on the `1.0.x` distribution channel
* Creating the branch `1.x` from `master` will make the `1.0.0` release available on the `1.x` distribution channel
* Merging the branch `1.0.x` into `1.x` will make the version `1.0.1` available on the `1.x` distribution channel
### Pre-release branches
A pre-release branch is a type of branch used by **semantic-release** that allows to publish releases with a [pre-release version](https://semver.org/#spec-item-9). Using a pre-release version allow to publish multiple releases with the same version. Those release will be differentiated via their identifiers (in `1.0.0-alpha.1` the identifier is `alpha.1`). This is useful when you need to work on a future major release that will include many breaking changes but you do not want to increment the version number for each breaking change commit.
A pre-release branch is characterized by the `prerelease` property that defines the static part of the version released (in `1.0.0-alpha.1` the static part fo the identifier is `alpha`). The [`prerelease`](#prerelease) value of each pre-release branch must be unique across the project.
**semantic-release** will always publish pre-releases to a specific distribution channel, so only the users who choose to use that particular line of versions will receive new releases.
When merging commits associated with an existing release, **semantic-release** will treat them as [pushed commits](#pushing-to-a-pre-release-branch) and publish a new release if necessary, but it will never add those releases to the distribution channel corresponding to the pre-release branch.
See [publishing pre-releases recipe](https://github.com/semantic-release/semantic-release/tree/88e423b8286cfe852d8348d174e621c1e39e42d8/docs/recipes/pre-releases.md) for a detailed example.
#### Pushing to a pre-release branch
With the configuration `"branches": ["master", {"name": "beta", "prerelease": true}]`, if the last release published from `master` is `1.0.0` then:
* Pushing a `BREAKING CHANGE` commit on the `beta` branch will release the version `2.0.0-beta.1` on the `beta` distribution channel
* Pushing either a `fix`, `feat` or a `BREAKING CHANGE` commit on the `beta` branch will release the version `2.0.0-beta.2` (then `2.0.0-beta.3`, `2.0.0-beta.4`, etc...) on the `beta` distribution channel
#### Merging into a pre-release branch
With the configuration `"branches": ["master", {"name": "beta", "prerelease": true}]`, if the last release published from `master` is `1.0.0` and the last one published from `beta` is `2.0.0-beta.1` then:
* Pushing a `fix` commit on the `master` branch will release the version `1.0.1` on the default distribution channel
* Merging the branch `master` into `beta` will release the version `2.0.0-beta.2` on the `beta` distribution channel
# Shareable configurations
A shareable configuration is an [npm](https://www.npmjs.com/) package that exports a **semantic-release** configuration object. It allows for use of the same configuration across several projects.
The shareable configurations to use can be set with the [extends](https://semantic-release.gitbook.io/semantic-release/configuration#extends) option.
See [shareable configurations list](https://semantic-release.gitbook.io/semantic-release/extending/shareable-configurations-list).
# Plugins
## Official plugins
* [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `analyzeCommits`: Determine the type of release by analyzing commits with [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog)
* [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `generateNotes`: Generate release notes for the commits added since the last release with [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog)
* [@semantic-release/github](https://github.com/semantic-release/github)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `verifyConditions`: Verify the presence and the validity of the GitHub authentication and release configuration
* `publish`: Publish a [GitHub release](https://help.github.com/articles/about-releases)
* `success`: Add a comment to GitHub issues and pull requests resolved in the release
* `fail`: Open a GitHub issue when a release fails
* [@semantic-release/npm](https://github.com/semantic-release/npm)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `verifyConditions`: Verify the presence and the validity of the npm authentication and release configuration
* `prepare`: Update the package.json version and create the npm package tarball
* `publish`: Publish the package on the npm registry
* [@semantic-release/gitlab](https://github.com/semantic-release/gitlab)
* `verifyConditions`: Verify the presence and the validity of the GitLab authentication and release configuration
* `publish`: Publish a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/)
* [@semantic-release/git](https://github.com/semantic-release/git)
* `verifyConditions`: Verify the presence and the validity of the Git authentication and release configuration
* `prepare`: Push a release commit and tag, including configurable files
* [@semantic-release/changelog](https://github.com/semantic-release/changelog)
* `verifyConditions`: Verify the presence and the validity of the configuration
* `prepare`: Create or update the changelog file in the local project repository
* [@semantic-release/exec](https://github.com/semantic-release/exec)
* `verifyConditions`: Execute a shell command to verify if the release should happen
* `analyzeCommits`: Execute a shell command to determine the type of release
* `verifyRelease`: Execute a shell command to verifying a release that was determined before and is about to be published
* `generateNotes`: Execute a shell command to generate the release note
* `prepare`: Execute a shell command to prepare the release
* `publish`: Execute a shell command to publish the release
* `success`: Execute a shell command to notify of a new release
* `fail`: Execute a shell command to notify of a failed release
* [@semantic-release/apm](https://github.com/semantic-release/apm)
* `verifyConditions`: Verify the presence of the `ATOM_ACCESS_TOKEN` environment variable and the [`apm`](https://github.com/atom/apm) CLI
* `prepare`: Update the `package.json` version with [`npm version`](https://docs.npmjs.com/cli/version)
* `publish`: Publish the [Atom package](https://flight-manual.atom.io/hacking-atom/sections/publishing)
## Community plugins
[Open a Pull Request](https://github.com/semantic-release/semantic-release/blob/master/CONTRIBUTING.md#submitting-a-pull-request) to add your plugin to the list.
* [semantic-release-slack-bot](https://github.com/juliuscc/semantic-release-slack-bot)
* `verifyConditions`: Verify that the environment variable `SLACK_WEBHOOK` has been defined.
* `success`: Publish a message about the success to a slack channel.
* `fail`: Optionally publish a message about failure to a slack channel.
* [semantic-release-docker](https://github.com/felixfbecker/semantic-release-docker)
* `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry.
* `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
* [@semantic-release-plus/docker](https://github.com/semantic-release-plus/semantic-release-plus/tree/master/packages/plugins/docker)
* `verifyConditions`: Verify that all needed configuration is present and login to the configured docker registry.
* `publish`: Tag the image specified by `name` with the new version, push it to the configured docker registry and update the `latest`, `major`, `minor` tags based on the configuration settings.
* [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr)
* `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry
* `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
* [semantic-release-vsce](https://github.com/raix/semantic-release-vsce)
* `verifyConditions`: Verify the presence and the validity of the vsce authentication and release configuration
* `prepare`: Create a `.vsix` for distribution
* `publish`: Publish the package to the Visual Studio Code marketplace
* [semantic-release-verify-deps](https://github.com/piercus/semantic-release-verify-deps)
* `verifyConditions`: Check the dependencies format against a regexp before a release
* [semantic-release-chrome](https://github.com/GabrielDuarteM/semantic-release-chrome)
* `verifyConditions`: Verify the presence of the authentication (set via environment variables)
* `prepare`: Write the correct version to the `manifest.json` and creates a zip file of the whole dist folder
* `publish`: Uploads the generated zip file to the webstore, and publish the item
* [semantic-release-firefox-add-on](https://github.com/tophat/semantic-release-firefox-add-on)
* `verifyConditions`: Verify that all required options are present and authentication is set via environment variables
* `prepare`: Write the correct version to the `manifest.json`
* `publish`: Creates an unsigned `.xpi` file, and submits it to the Mozilla Add On store for signing. Once the package is signed, downloads the signed `.xpi` to a local directory
* [semantic-release-gerrit](https://github.com/pascalMN/semantic-release-gerrit)
* `generateNotes`: Generate release notes with Gerrit reviews URL
* [semantic-release-expo](https://github.com/bycedric/semantic-release-expo)
* `verifyConditions`: Verify Expo manifest(s) are readable and valid.
* `prepare`: Update version, ios build number and android version code in the Expo manifest(s).
* [maven-semantic-release](https://github.com/conveyal/maven-semantic-release)
* `verifyConditions`: Verifies that the `pom.xml` file and other files exist and are setup to allow releases
* `verifyRelease`: Checks and warns (does not error by default) if the version numbers found on maven central and within the Git project differ by quite a bit
* `prepare`: Changes the version number in the `pom.xml` (or all `pom.xml` files in maven projects with multiple `pom.xml` files) and optionally creates a commit with this version number and pushes it to `master`
* `publish`: Runs `mvn deploy` to deploy to maven central and optionally will update to next snapshot version and merge changes to development branch
* [semantic-release-ado](https://github.com/lluchmk/semantic-release-ado)
* `prepare`: Stores the version number as an Azure DevOps pipeline variable availabe to downstream steps on the job
* [gradle-semantic-release](https://github.com/KengoTODA/gradle-semantic-release-plugin)
* `verifyConditions`: Verify that project has a Gradle wrapper script, and `build.gradle` contains a task to publish artifacts.
* `prepare`: Changes the version number in the `gradle.properties`
* `publish`: Triggers Gradle to publish artifacts.
* [semantic-release-circleci-orb](https://github.com/matt-oakes/semantic-release-circleci-orb)
* `verifyConditions`: Verify the presence of the `CIRCLECI_API_TOKEN` environment variable, `orbName` option, and the `circleci` CLI.
* `publish`: Publish the CircleCI orb.
* [semantic-release-github-pages](https://github.com/qiwi/semantic-release-gh-pages-plugin)
* `verifyConditions`: Verify the presence of the auth token set via environment variables.
* `publish`: Pushes commit to the documentation branch.
* [semantic-release-github-pullrequest](https://github.com/asbiin/semantic-release-github-pullrequest)
* `verifyConditions`: Verify the presence and the validity of the GitHub authentication and other configuration.
* `publish`: Create a branch to upload all assets and create the pull request on the base branch on GitHub.
* [leiningen-semantic-release](https://github.com/NoxHarmonium/leiningen-semantic-release)
* `verifyConditions`: Checks the project.clj is syntactically valid.
* `prepare`: Update the project.clj version and package the output jar file.
* `publish`: Publish the jar (and generated Maven metadata) to a maven repository (or clojars).
* [@saithodev/semantic-release-gitea](https://github.com/saitho/semantic-release-gitea)
* `verifyConditions`: Verify the presence and the validity of the authentication and the assets option configuration.
* `publish`: Publish a Gitea release, optionally uploading file assets.
* `addChannel`: Update a Gitea release's pre-release field.
* [@google/semantic-release-replace-plugin](https://github.com/google/semantic-release-replace-plugin)
* `prepare`: Replace version strings in files using regex and glob.
* [semantic-release-rubygem](https://github.com/Gusto/semantic-release-rubygem)
* `verifyConditions`: Locate and validate a `.gemspec` file, locate and validate a `lib/**/version.rb` file, verify the presence of the `GEM_HOST_API_KEY` environment variable, and create a credentials file with the API key.
* `prepare`: Update the version in the `lib/**/version.rb` version file and [build](https://guides.rubygems.org/command-reference/#gem-build) the gem.
* `publish`: [Push the Ruby gem](https://guides.rubygems.org/command-reference/#gem-push) to the gem server.
* [semantic-release-npm-deprecate-old-versions](https://github.com/ghusse/semantic-release-npm-deprecate-old-versions)
* `verifyConditions`: Validates configuration.
* `publish`: Deprecates old versions, based on the declaration of supported versions in the config.
* [amanda-mitchell/semantic-release-npm-multiple](https://github.com/amanda-mitchell/semantic-release-npm-multiple)
* **Note**: this is a thin wrapper around the built-in npm plugin that can target multiple registries
* `verifyConditions`: Verify the presence and the validity of the npm authentication and release configuration for multiple registries
* `prepare`: Update the package.json version and create the npm package tarball
* `publish`: Publish the package on the npm registry for multiple registries
* [semantic-release-license](https://github.com/cbhq/semantic-release-license) Automatically update dates and more in your license file for new releases.
* `verifyConditions`: Verify the presence of a license file
* `prepare`: Update the license file based on its type
* [semantic-release-pypi](https://github.com/abichinger/semantic-release-pypi)
* `verifyConditions`: Verify the environment variable `PYPI_TOKEN` and installation of build tools
* `prepare`: Update the version in `setup.cfg` and create the distribution packages
* `publish`: Publish the python package to a repository (default: pypi)
* [semantic-release-helm](https://github.com/m1pl/semantic-release-helm)
* `verifyConditions`: Validate configuration and (if present) credentials
* `prepare`: Update version and appVersion in `Chart.yaml`
* `publish`: Publish the chart to a registry (if configured)
* [semantic-release-codeartifact](https://github.com/ryansonshine/semantic-release-codeartifact)
* `verifyConditions`: Validate configuration, get AWS CodeArtifact authentication and repository, validate `publishConfig` or `.npmrc` (if they exist), then pass the configuration to the associated plugins.
* [semantic-release-telegram](https://github.com/pustovitDmytro/semantic-release-telegram)
* `verifyConditions`: Validate configuration and verify `TELEGRAM_BOT_ID` and `TELEGRAM_BOT_TOKEN`
* `success`: Publish a message about the successful release to a telegram chat
* `fail`: publish a message about failure to a telegram chat
* [semantic-release-heroku](https://github.com/pustovitDmytro/semantic-release-heroku)
* `verifyConditions`: Validate configuration and verify `HEROKU_API_KEY`
* `prepare`: Update the package.json version and create release tarball
* `publish`: Publish version to heroku
# Shareable configuration
## Official configurations
* [@semantic-release/apm-config](https://github.com/semantic-release/apm-config) - semantic-release shareable configuration for releasing atom packages
* [@semantic-release/gitlab-config](https://github.com/semantic-release/gitlab-config) - semantic-release shareable configuration for GitLab
## Community configurations
* [@jedmao/semantic-release-npm-github-config](https://github.com/jedmao/semantic-release-npm-github-config)
* Provides an informative [git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., "chore(release): 1.2.3 \[skip ci]\n\nnotes").
* Creates a tarball that gets uploaded with each [GitHub release](https://github.com/semantic-release/github).
* Publishes the same tarball to [npm](https://github.com/semantic-release/npm).
* Commits the version change in `package.json`.
* Creates or updates a [changelog](https://github.com/semantic-release/changelog) file.
* [semantic-release-npm-github-publish](https://github.com/oleg-koval/semantic-release-npm-github-publish)
* Based on [angular preset](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular).
* Adds more keywords for the `chore` **PATCH** release.
* Generates or updates a [changelog](https://github.com/semantic-release/changelog) file including all **PATCH** keywords (not included in default angular package).
* Updates GitHub release with release-notes.
* Bumps a version in package.json.
* Publishes the new version to [NPM](https://npmjs.org).
# CI configurations
## CI configurations
* [CircleCI 2.0 workflows](https://semantic-release.gitbook.io/semantic-release/recipes/recipes/circleci-workflows)
* [Travis CI](https://semantic-release.gitbook.io/semantic-release/recipes/recipes/travis)
* [GitLab CI](https://semantic-release.gitbook.io/semantic-release/recipes/recipes/gitlab-ci)
* [GitHub Actions](https://github.com/semantic-release/semantic-release/tree/88e423b8286cfe852d8348d174e621c1e39e42d8/docs/recipes/github-actions.md)
* [Jenkins CI](https://github.com/semantic-release/semantic-release/tree/88e423b8286cfe852d8348d174e621c1e39e42d8/docs/recipes/jenkins-ci.md)
## Git hosted services
* [Git authentication with SSH keys](https://semantic-release.gitbook.io/semantic-release/recipes/git-hosted-services/git-auth-ssh-keys)
## Release workflow
* [Publishing on distribution channels](https://github.com/semantic-release/semantic-release/tree/88e423b8286cfe852d8348d174e621c1e39e42d8/docs/recipes/distribution-channels.md)
* [Publishing maintenance releases](https://github.com/semantic-release/semantic-release/tree/88e423b8286cfe852d8348d174e621c1e39e42d8/docs/recipes/maintenance-releases.md)
* [Publishing pre-releases](https://github.com/semantic-release/semantic-release/tree/88e423b8286cfe852d8348d174e621c1e39e42d8/docs/recipes/pre-releases.md)
## Package managers and languages
# CircleCI 2.0
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured in [CircleCi Project Settings](https://circleci.com/docs/2.0/env-vars/#adding-environment-variables-in-the-app)..
Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](https://semantic-release.gitbook.io/semantic-release/usage/getting-started#getting-started).
## Multiple Node jobs configuration
### `.circleci/config.yml` configuration for multiple Node jobs
This example is a minimal configuration for **semantic-release** with tests running against Node 16 and 14. See [CircleCI documentation](https://circleci.com/docs/2.0) for additional configuration options.
In this example, the [`circleci/node`](https://circleci.com/developer/orbs/orb/circleci/node) orb is imported (Which makes some node operations easier), then a `release` job is defined which will run `semantic-release`.
To run our `release` job, we have created a workflow named `test_and_release` which will run two jobs, `node/test`, which comes from the node orb and will test our application, and our release job. Here, we are actually making use of [matrix jobs](https://circleci.com/blog/circleci-matrix-jobs/) so that our single `node/test` job will actually be executed twice, once for Node version 16, and once for version 14. Finally, we call our release job with a `requires` parameter so that `release` will only run after `node/test` has successfully tested against v14 and v16.
```yaml
version: 2.1
orbs:
node: circleci/node@4.5
jobs:
release:
executor: node/default
steps:
- checkout
- node/install-packages # Install and automatically cache packages
# Run optional required steps before releasing
# - run: npm run build-script
- run: npx semantic-release
workflows:
test_and_release:
# Run the test jobs first, then the release only when all the test jobs are successful
jobs:
- node/test:
matrix:
parameters:
version:
- 16.1.0
- 14.17.0
- release:
requires:
- node/test
```
### `package.json` configuration for multiple Node jobs
A `package.json` is required only for [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation.
```javascript
{
"devDependencies": {
"semantic-release": "^18.0.0"
}
}
```
# Travis CI
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured in [Travis Repository Settings](https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-Settings) or with the [travis env set CLI](https://github.com/travis-ci/travis.rb#env).
Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](https://semantic-release.gitbook.io/semantic-release/usage/getting-started#getting-started).
## Node.js projects configuration
### `.travis.yml` configuration for multiple Node.js jobs
This example is a minimal configuration for **semantic-release** with a build running Node 14 and 16. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification.
**Note**: It's not recommended to run the `semantic-release` command in the Travis `script` step as each script in this step will be executed regardless of the outcome of the previous one. See [travis-ci/travis-ci#1066](https://github.com/travis-ci/travis-ci/issues/1066).
**Advanced configuration**: Running the tests in the `script` step of the `release` stage is not necessary as the previous stage(s) already ran them. To increase speed, the `script` step of the `release` stage can be overwritten to skip the tests. Note that other commands such as build or compilation might still be required.
```yaml
language: node_js
node_js:
- 14
- 16
jobs:
include:
# Define the release stage that runs semantic-release
- stage: release
node_js: lts/*
# Advanced: optionally overwrite your default `script` step to skip the tests
# script: skip
deploy:
provider: script
skip_cleanup: true
script:
- npx semantic-release
```
### `package.json` configuration for multiple Node jobs
A `package.json` is required only for [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation.
```javascript
{
"devDependencies": {
"semantic-release": "^18.0.0"
}
}
```
## Non-Node.js projects configuration
For projects that require to be tested with one or multiple version of a Non-JavaScript [language](https://docs.travis-ci.com/user/languages), optionally on multiple [Operating Systems](https://docs.travis-ci.com/user/multi-os).
This recipe cover the Travis specifics only. See [Non JavaScript projects recipe](https://semantic-release.gitbook.io/semantic-release/support/faq#can-i-use-semantic-release-to-publish-non-javascript-packages) for more information on the **semantic-release** configuration.
### `.travis.yml` configuration for non-JavaScript projects
This example is a minimal configuration for **semantic-release** with a build running [Go 1.6 and 1.7](https://docs.travis-ci.com/user/languages/go). See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification.
**Note**: It's not recommended to run the `semantic-release` command in the Travis `script` step as each script in this step will be executed regardless of the outcome of the previous one. See [travis-ci/travis-ci#1066](https://github.com/travis-ci/travis-ci/issues/1066).
**Advanced configuration**: Running the tests in the `script` step of the `release` stage is not necessary as the previous stage(s) already ran them. To increase speed, the `script` step of the `release` stage can be overwritten to skip the tests. Note that other commands such as build or compilation might still be required.
```yaml
language: go
go:
- 1.6
- 1.7
jobs:
include:
# Define the release stage that runs semantic-release
- stage: release
# Advanced: optionally overwrite your default `script` step to skip the tests
# script:
# - make
deploy:
provider: script
skip_cleanup: true
script:
# Use nvm to install and use the Node LTS version (nvm is installed on all Travis images)
- nvm install lts/*
- npx semantic-release
on:
all_branches: true
```
# GitLab CI
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured with [Protected variables](https://docs.gitlab.com/ce/ci/variables/README.html#protected-environment-variables).
**Note**: Make sure to configure your release branch as [protected](https://docs.gitlab.com/ce/user/project/protected_branches.html) in order for the CI/CD build to access the protected variables.
## Node project configuration
GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) allowing to test on multiple Node versions and publishing a release only when all test pass.
**Note**: The publish pipeline must run a [Node >= 14.17 version](https://semantic-release.gitbook.io/semantic-release/support/faq#why-does-semantic-release-require-node-version--1417).
### `.gitlab-ci.yml` configuration for Node projects
This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
**Note**: The`semantic-release` execution command varies depending if you are using a [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) or [global](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) **semantic-release** installation.
```yaml
# The release pipeline will run only if all jobs in the test pipeline are successful
stages:
- test
- release
before_script:
- npm install
node:10:
image: node:10
stage: test
script:
- npm test
node:12:
image: node:12
stage: test
script:
- npm test
publish:
image: node:12
stage: release
script:
- npx semantic-release
```
### `.gitlab-ci.yml` configuration for all projects
This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
**Note**: The`semantic-release` execution command varies depending if you are using a [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) or [global](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) **semantic-release** installation.
```yaml
# The release pipeline will run only on the master branch a commit is triggered
stages:
- release
release:
image: node:10-buster-slim
stage: release
before_script:
- apt-get update && apt-get install -y --no-install-recommends git-core ca-certificates
- npm install -g semantic-release @semantic-release/gitlab
script:
- semantic-release
only:
- master
release:
image: node:12-buster-slim
stage: release
before_script:
- apt-get update && apt-get install -y --no-install-recommends git-core ca-certificates
- npm install -g semantic-release @semantic-release/gitlab
script:
- semantic-release
only:
- master
```
### `package.json` configuration
A `package.json` is required only for [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation.
```javascript
{
"devDependencies": {
"semantic-release": "^15.0.0"
}
}
```
# Git hosted services
# Git authentication with SSH keys
When using [environment variables](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) to set up the Git authentication, the remote Git repository will automatically be accessed via [https](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_http_protocols), independently of the [`repositoryUrl`](https://semantic-release.gitbook.io/semantic-release/usage/configuration#repositoryurl) format configured in the **semantic-release** [Configuration](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration) (the format will be automatically converted as needed).
Alternatively the Git repository can be accessed via [SSH](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_ssh_protocol) by creating SSH keys, adding the public one to your Git hosted account and making the private one available on the CI environment.
**Note:** SSH keys allow to push the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) associated to the released version. Some plugins might also require an API token. See each plugin documentation for additional information.
## Generating the SSH keys
In your local repository root:
```bash
$ ssh-keygen -t rsa -b 4096 -C "" -f git_deploy_key -N ""
```
`your_email` must be the email associated with your Git hosted account. `ssh_passphrase` must be a long and hard to guess string. It will be used later.
This will generate a public key in `git_deploy_key.pub` and a private key in `git_deploy_key`.
## Adding the SSH public key to the Git hosted account
Step by step instructions are provided for the following Git hosted services:
* [GitHub](#adding-the-ssh-public-key-to-github)
### Adding the SSH public key to GitHub
Open the `git_deploy_key.pub` file (public key) and copy the entire content.
In GitHub **Settings**, click on **SSH and GPG keys** in the sidebar, then on the **New SSH Key** button.
Paste the entire content of `git_deploy_key.pub` file (public key) and click the **Add SSH Key** button.
Delete the `git_deploy_key.pub` file:
```bash
$ rm git_deploy_key.pub
```
See [Adding a new SSH key to your GitHub account](https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account/) for more details.
## Adding the SSH private key to the CI environment
In order to be available on the CI environment, the SSH private key must be encrypted, committed to the Git repository and decrypted by the CI service.
Step by step instructions are provided for the following environments:
* [Travis CI](#adding-the-ssh-private-key-to-travis-ci)
* [Circle CI](#adding-the-ssh-private-key-to-circle-ci)
### Adding the SSH private key to Travis CI
Install the [Travis CLI](https://github.com/travis-ci/travis.rb#installation):
```bash
$ gem install travis
```
[Login](https://github.com/travis-ci/travis.rb#login) to Travis with the CLI:
```bash
$ travis login
```
Add the [environment](https://github.com/travis-ci/travis.rb#env) variable `SSH_PASSPHRASE` to Travis with the value set during the [SSH keys generation](#generating-the-ssh-keys) step:
```bash
$ travis env set SSH_PASSPHRASE
```
[Encrypt](https://github.com/travis-ci/travis.rb#encrypt) the `git_deploy_key` (private key) using a symmetric encryption (AES-256), and store the secret in a secure environment variable in the Travis environment:
```bash
$ travis encrypt-file git_deploy_key
```
The `travis encrypt-file` will encrypt the private key into the `git_deploy_key.enc` file and output in the console the command to add to your `.travis.yml` file. It should look like `openssl aes-256-cbc -K $encrypted_KKKKKKKKKKKK_key -iv $encrypted_VVVVVVVVVVVV_iv -in git_deploy_key.enc -out git_deploy_key -d`.
Copy this command to your `.travis.yml` file in the `before_install` step. Change the output path to write the unencrypted key in `/tmp`: `-out git_deploy_key` => `/tmp/git_deploy_key`. This will avoid to commit / modify / delete the unencrypted key by mistake on the CI. Then add the commands to decrypt the ssh private key and make it available to `git`:
```yaml
before_install:
# Decrypt the git_deploy_key.enc key into /tmp/git_deploy_key
- openssl aes-256-cbc -K $encrypted_KKKKKKKKKKKK_key -iv $encrypted_VVVVVVVVVVVV_iv -in git_deploy_key.enc -out /tmp/git_deploy_key -d
# Make sure only the current user can read the private key
- chmod 600 /tmp/git_deploy_key
# Create a script to return the passphrase environment variable to ssh-add
- echo 'echo ${SSH_PASSPHRASE}' > /tmp/askpass && chmod +x /tmp/askpass
# Start the authentication agent
- eval "$(ssh-agent -s)"
# Add the key to the authentication agent
- DISPLAY=":0.0" SSH_ASKPASS="/tmp/askpass" setsid ssh-add /tmp/git_deploy_key /tmp/askpass && chmod +x /tmp/askpass
# Start the authentication agent
- eval "$(ssh-agent -s)"
# Add the key to the authentication agent
- DISPLAY=":0.0" SSH_ASKPASS="/tmp/askpass" setsid ssh-add /tmp/git_deploy_key Promise
Run **semantic-release** and returns a `Promise` that resolves to a [Result](#result) object.
#### options
Type: `Object`
**semantic-release** options.
Can be used to set any [core option](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration) or [plugin options](https://semantic-release.gitbook.io/semantic-release/usage/plugins#configuration).
Each option, will take precedence over options configured in the [configuration file](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration) and [shareable configurations](https://semantic-release.gitbook.io/semantic-release/usage/configuration#extends).
#### config
Type: `Object`
**semantic-release** configuration specific for API usage.
**cwd**
Type: `String`\
Default: `process.cwd()`
The current working directory to use. It should be configured to the root of the Git repository to release from.
It allows to run **semantic-release** from a specific path without having to change the local process `cwd` with `process.chdir()`.
**env**
Type: `Object`\
Default: `process.env`
The environment variables to use.
It allows to run **semantic-release** with specific environment variables without having to modify the local `process.env`.
**stdout**
Type: [`stream.Writable`](https://nodejs.org/api/stream.html#stream_writable_streams)\
Default: `process.stdout`
The [writable stream](https://nodejs.org/api/stream.html#stream_writable_streams) used to log information.
It allows to configure **semantic-release** to write logs to a specific stream rather than the local `process.stdout`.
**stderr**
Type: [`stream.Writable`](https://nodejs.org/api/stream.html#stream_writable_streams)\
Default: `process.stderr`
The [writable stream](https://nodejs.org/api/stream.html#stream_writable_streams) used to log errors.
It allows to configure **semantic-release** to write errors to a specific stream rather than the local `process.stderr`.
### Result
Type: `Object` `Boolean``
The list of commit included in the new release.\
Each commit object has the following properties:
| Name | Type | Description |
| --------------- | -------- | ----------------------------------------------- |
| commit | `Object` | The commit abbreviated and full hash. |
| commit.long | `String` | The commit hash. |
| commit.short | `String` | The commit abbreviated hash. |
| tree | `Object` | The commit abbreviated and full tree hash. |
| tree.long | `String` | The commit tree hash. |
| tree.short | `String` | The commit abbreviated tree hash. |
| author | `Object` | The commit author information. |
| author.name | `String` | The commit author name. |
| author.email | `String` | The commit author email. |
| author.short | `String` | The commit author date. |
| committer | `Object` | The committer information. |
| committer.name | `String` | The committer name. |
| committer.email | `String` | The committer email. |
| committer.short | `String` | The committer date. |
| subject | `String` | The commit subject. |
| body | `String` | The commit body. |
| message | `String` | The commit full message (`subject` and `body`). |
| hash | `String` | The commit hash. |
| committerDate | `String` | The committer date. |
Example:
```javascript
[
{
commit: {
long: '68eb2c4d778050b0701136ca129f837d7ed494d2',
short: '68eb2c4'
},
tree: {
long: '7ab515d12bd2cf431745511ac4ee13fed15ab578',
short: '7ab515d'
},
author: {
name: 'Me',
email: 'me@email.com',
date: 2018-07-22T20:52:44.000Z
},
committer: {
name: 'Me',
email: 'me@email.com',
date: 2018-07-22T20:52:44.000Z
},
subject: 'feat: a new feature',
body: 'Description of the new feature',
hash: '68eb2c4d778050b0701136ca129f837d7ed494d2',
message: 'feat: a new feature\n\nDescription of the new feature',
committerDate: 2018-07-22T20:52:44.000Z
}
]
```
#### nextRelease
Type: `Object`
Information related to the newly published release:
| Name | Type | Description |
| ------- | -------- | ----------------------------------------------------------------------------------------------------------------------------- |
| type | `String` | The [semver](https://semver.org) type of the release (`patch`, `minor` or `major`). |
| version | `String` | The version of the new release. |
| gitHead | `String` | The sha of the last commit being part of the new release. |
| gitTag | `String` | The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) associated with the new release. |
| notes | `String` | The release notes for the new release. |
| channel | `String` | The distribution channel on which the next release will be made available (`undefined` for the default distribution channel). |
Example:
```javascript
{
type: 'minor',
gitHead: '68eb2c4d778050b0701136ca129f837d7ed494d2',
version: '1.1.0',
gitTag: 'v1.1.0',
notes: 'Release notes for version 1.1.0...',
channel : 'next'
}
```
#### releases
Type: `Array`
The list of releases published or made available to a distribution channel.\
Each release object has the following properties:
| Name | Type | Description |
| ---------- | -------- | -------------------------------------------------------------------------------------------------------------- |
| name | `String` | **Optional.** The release name, only if set by the corresponding `publish` plugin. |
| url | `String` | **Optional.** The release URL, only if set by the corresponding `publish` plugin. |
| type | `String` | The [semver](https://semver.org) type of the release (`patch`, `minor` or `major`). |
| version | `String` | The version of the release. |
| gitHead | `String` | The sha of the last commit being part of the release. |
| gitTag | `String` | The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) associated with the release. |
| notes | `String` | The release notes for the release. |
| pluginName | `String` | The name of the plugin that published the release. |
| channel | `String` | The distribution channel on which the release is available (`undefined` for the default distribution channel). |
Example:
```javascript
[
{
name: 'GitHub release',
url: 'https://github.com/me/my-package/releases/tag/v1.1.0',
type: 'minor',
gitHead: '68eb2c4d778050b0701136ca129f837d7ed494d2',
version: '1.1.0',
gitTag: 'v1.1.0',
notes: 'Release notes for version 1.1.0...',
pluginName: '@semantic-release/github'
channel: 'next'
},
{
name: 'npm package (@latest dist-tag)',
url: 'https://www.npmjs.com/package/my-package',
type: 'minor',
gitHead: '68eb2c4d778050b0701136ca129f837d7ed494d2',
version: '1.1.0',
gitTag: 'v1.1.0',
notes: 'Release notes for version 1.1.0...',
pluginName: '@semantic-release/npm'
channel: 'next'
}
]
```
# Plugin development
To create a plugin for `semantic-release`, you need to decide which parts of the release lifecycle are important to that plugin. For example, it is best to always have a `verifyConditions` step because you may be receiving inputs from a user and want to make sure they exist. A plugin can abide by any of the following lifecycles:
* `verifyConditions`
* `analyzeCommits`
* `verifyRelease`
* `generateNotes`
* `addChannel`
* `prepare`
* `publish`
* `success`
* `fail`
`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecyles stated above. For example, if your plugin only had a `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions.
In addition to the lifecycle methods, each lifecyle is passed two objects:
1. `pluginConfig` - an object containing the options that a user may pass in via their `release.config.js` file (or similar)
2. `context` - provided by `semantic-release` for access to things like `env` variables set on the running process.
For each lifecycle you create, you will want to ensure it can accept `pluginConfig` and `context` as parameters.
## Creating a Plugin Project
It is recommended that you generate a new project with `yarn init`. This will provide you with a basic node project to get started with. From there, create an `index.js` file, and make sure it is specified as the `main` in the `package.json`. We will use this file to orchestrate the lifecycle methods later on.
Next, create a `src` or `lib` folder in the root of the project. This is where we will store our logic and code for how our lifecycle methods work. Finally, create a `test` folder so you can write tests related to your logic.
We recommend you setup a linting system to ensure good javascript practices are enforced. ESLint is usually the system of choice, and the configuration can be whatever you or your team fancies.
## Exposing Lifecycle Methods
In your `index.js` file, you can start by writing the following code
```javascript
const verifyConditions = require('./src/verify');
let verified;
/**
* Called by semantic-release during the verification step
* @param {*} pluginConfig The semantic-release plugin config
* @param {*} context The context provided by semantic-release
*/
async function verify(pluginConfig, context) {
await verifyConditions(pluginConfig, context);
verified = true;
}
module.exports = { verify };
```
Then, in your `src` folder, create a file called `verify.js` and add the following
```javascript
const AggregateError = require('aggregate-error');
/**
* A method to verify that the user has given us a slack webhook url to post to
*/
module.exports = async (pluginConfig, context) => {
const { logger } = context;
const errors = [];
// Throw any errors we accumulated during the validation
if (errors.length > 0) {
throw new AggregateError(errors);
}
};
```
As of right now, this code won't do anything. However, if you were to run this plugin via `semantic-release`, it would run when the `verify` step occurred.
Following this structure, you can create different steps and checks to run through out the release process.
## Supporting Options
Let's say we want to verify that an `option` is passed. An `option` is a configuration object that is specific to your plugin. For example, the user may set an `option` in their release config like:
```javascript
{
prepare: {
path: "@semantic-release/my-special-plugin"
message: "My cool release message"
}
}
```
This `message` option will be passed to the `pluginConfig` object mentioned earlier. We can use the validation method we created to verify this option exists so we can perform logic based on that knowledge. In our `verify` file, we can add the following:
```javascript
const { message } = pluginConfig;
if (message.length) {
//...
}
```
## Context
### Common context keys
* `stdout`
* `stderr`
* `logger`
### Context object keys by lifecycle
#### verifyConditions
Initially the context object contains the following keys (`verifyConditions` lifecycle):
* `cwd`
* Current working directory
* `env`
* Environment variables
* `envCi`
* Information about CI environment
* Contains (at least) the following keys:
* `isCi`
* Boolean, true if the environment is a CI environment
* `commit`
* Commit hash
* `branch`
* Current branch
* `options`
* Options passed to `semantic-release` via CLI, configuration files etc.
* `branch`
* Information on the current branch
* Object keys:
* `channel`
* `tags`
* `type`
* `name`
* `range`
* `accept`
* `main`
* `branches`
* Information on branches
* List of branch objects (see above)
#### analyzeCommits
Compared to the verifyConditions, `analyzeCommits` lifecycle context has keys
* `commits` (List)
* List of commits taken into account when determining the new version.
* Keys:
* `commit` (Object)
* Keys:
* `long` (String, Commit hash)
* `short` (String, Commit hash)
* `tree` (Object)
* Keys:
* `long` (String, Commit hash)
* `short` (String, Commit hash)
* `author` (Object)
* Keys:
* `name` (String)
* `email` (String)
* `date` (String, ISO 8601 timestamp)
* `committer` (Object)
* Keys:
* `name` (String)
* `email` (String)
* `date` (String, ISO 8601 timestamp)
* `subject` (String, Commit message subject)
* `body` (String, Commit message body)
* `hash` (String, Commit hash)
* `committerDate` (String, ISO 8601 timestamp)
* `message` (String)
* `gitTags` (String, List of git tags)
* `releases` (List)
* `lastRelease` (Object)
* Keys
* `version` (String)
* `gitTag` (String)
* `channels` (List)
* `gitHead` (String, Commit hash)
* `name` (String)
#### verifyRelease
Additional keys:
* `nextRelease` (Object)
* `type` (String)
* `channel` (String)
* `gitHead` (String, Git hash)
* `version` (String, version without `v`)
* `gitTag` (String, version with `v`)
* `name` (String)
#### generateNotes
No new content in the context.
#### addChannel
*This is run only if there are releases that have been merged from a higher branch but not added on the channel of the current branch.*
Context content is similar to lifecycle `verifyRelease`.
#### prepare
Only change is that `generateNotes` has populated `nextRelease.notes`.
#### publish
No new content in the context.
#### success
Lifecycles `success` and `fail` are mutually exclusive, only one of them will be run.
Additional keys:
* `releases`
* Populated by `publish` lifecycle
#### fail
Lifecycles `success` and `fail` are mutually exclusive, only one of them will be run.
Additional keys:
* `errors`
### Supporting Environment Variables
Similar to `options`, environment variables exist to allow users to pass tokens and set special URLs. These are set on the `context` object instead of the `pluginConfig` object. Let's say we wanted to check for `GITHUB_TOKEN` in the environment because we want to post to GitHub on the user's behalf. To do this, we can add the following to our `verify` command:
```javascript
const { env } = context;
if (env.GITHUB_TOKEN) {
//...
}
```
## Execution order
For the lifecycles, the list at the top of the readme contains the order. If there are multiple plugins for the same lifecycle, then the order of the plugins determines the order in which they are executed.
## Handling errors
In order to be able to detect and handle errors properly, the errors thrown from the must be of type [SemanticReleaseError](https://github.com/semantic-release/error) or extend it as described in the package readme. This way the errors are handled properly and plugins using the `fail` lifecycle receive the errors correctly. For any other types of errors the internal error handling does nothing, lets them through up until the final catch and does not call any `fail` plugins.
## Advanced
Knowledge that might be useful for plugin developers.
### Multiple analyzeCommits plugins
While it may be trivial that multiple analyzeCommits (or any lifecycle plugins) can be defined, it is not that self-evident that the plugins executed AFTER the first one (for example, the default one: `commit-analyzer`) can change the result. This way it is possible to create more advanced rules or situations, e.g. if none of the commits would result in new release, then a default can be defined.
The commit must be a known release type, for example the commit-analyzer has the following default types:
* major
* premajor
* minor
* preminor
* patch
* prepatch
* prerelease
If the analyzeCommits-lifecycle plugin does not return anything, then the earlier result is used, but if it returns a supported string value, then that overrides the previous result.
# Shareable configuration development
# Resources
## Videos
* ["Introducing Reliable Dependency and Release Management for npm Packages" - Gregor Martynus](https://www.youtube.com/watch?v=R2RJWLcfzwc)
* ["Kill all humans" - Jan Lehnardt](https://www.youtube.com/watch?v=ZXyx_1kN1L8\&t=2s)
* ["Publishing JavaScript Packages" - JavaScript Air](https://javascriptair.com/episodes/2016-07-20)
* ["Managing Dependencies like a boss đ" - JavaScript Air](https://javascriptair.com/episodes/2016-08-17)
* ["Dependency Hell Just Froze Over" - Stephan Bönnemann](https://www.youtube.com/watch?v=PA139CERNbc)
* ["semantic-release Q\&A with Kent C. Dodds"](https://www.youtube.com/watch?v=g6y3DnhkjrI)
* ["We fail to follow SemVer â and why it neednât matter" - Stephan Bönnemann](https://www.youtube.com/watch?v=tc2UgG5L7WM)
## Articles
* ["Introduction to SemVer" - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2)
* ["Introduction to Semantic Release" - liv](https://blog.greenkeeper.io/introduction-to-semantic-release-33f73b117c8)
* ["Series - Semantic Release Automation" - Abdelrahman Wahdan](https://dev.to/abdelrahmanahmed/semantic-release-and-how-to-automate-it-part-1-4pa2)
* ["Explain semantic release and how to use it on GitLab pipeline"](https://regoo707.medium.com/auto-bump-apps-versions-and-releases-using-gitlab-pipeline-e32f1d7fa3ee)
## Tutorials
* ["How to Write a JavaScript Library - Automating Releases with semantic-release" â egghead.io](https://egghead.io/lessons/javascript-automating-releases-with-semantic-release)
# Frequently Asked Questions
## Why is the `package.json`âs version not updated in my repository?
[`@semantic-release/npm`](https://github.com/semantic-release/npm) takes care of updating the `package.json`âs version before publishing to [npm](https://www.npmjs.com).
By default, only the published package will contain the version, which is the only place where it is *really* required, but the updated `package.json` will not be pushed to the Git repository
However, the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin can be used to push the updated `package.json` as well as other files to the Git repository.
If you wish to only update the `package.json` and push via Git you can set the project to `"private": true,` within your `package.json` to prevent publishing to [the npm registry](https://www.npmjs.com).
## How can I use a npm build script that requires the `package.json`âs version ?
The `package.json`âs version will be updated by the `semantic-release` command just before publishing to [npm](https://www.npmjs.com), therefore it won't be available for scripts ran before the `semantic-release` command.
As the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin uses the [npm CLI](https://docs.npmjs.com/cli/npm) to update the `package.json` version and publish the package, all [npm hook scripts](https://docs.npmjs.com/misc/scripts#description) will be executed.
You can run your build script in:
* the `prepublishOnly` or `prepack` hook so it will be executed during the `publish` step of `@semantic-release/npm`
* the `postversion` hook so it will be executed during the `prepare` step of `@semantic-release/npm`, which allow for example to update files before committing them with the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin
If using npm hook scripts is not possible, and alternative solution is to [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to run your script in the `prepare` step:
```javascript
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/npm",
["@semantic-release/exec", {
"prepareCmd": "./my-build-script.sh ${nextRelease.version}",
}],
]
}
```
## Is there a way to preview which version would currently get published?
Yes with the [dry-run options](https://semantic-release.gitbook.io/semantic-release/usage/configuration#dryrun) which prints to the console the next version to be published and the release notes.
## Can I use semantic-release to publish non-JavaScript packages?
Yes, **semantic-release** is a Node CLI application, but it can be used to publish any type of packages.
To publish a non-Node package (without a `package.json`) you would need to:
* Use a [global](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) **semantic-release** installation
* Set **semantic-release** [options](https://semantic-release.gitbook.io/semantic-release/usage/configuration#options) via [CLI arguments or rc file](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration)
* Make sure your CI job executing the `semantic-release` command has access to [Node >= 14.17](#why-does-semantic-release-require-node-version--1417) to execute the `semantic-release` command
See the [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details on specific CI environments.
In addition you will need to configure the **semantic-release** [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins#plugins) to disable the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin which is used by default and use a plugin for your project type.
If there is no specific plugin for your project type you can use the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to publish the release with a shell command.
Here is a basic example to create [GitHub releases](https://help.github.com/articles/about-releases) and use a shell command to publish:
```javascript
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/github",
["@semantic-release/exec", {
"prepareCmd" : "set-version ${nextRelease.version}",
"publishCmd" : "publish-package"
}]
]
}
```
**Note**: This is a theoretical example where the command `set-version` update the project version with the value passed as its first argument and `publish-package` publishes the package to a registry.
See the [package managers and languages recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#package-managers-and-languages) for more details on specific project types.
## Can I use semantic-release with any CI service?
Yes, **semantic-release** can be used with any CI service, as long as it provides:
* A way to set [authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) via environment variables
* A way to guarantee that the `semantic-release` command is [executed only after all the tests of all the jobs in the CI build pass](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded)
See the [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details on specific CI environments.
## Can I run semantic-release on my local machine rather than on a CI server?
Yes, you can by explicitly setting the [`--no-ci` CLI option](https://semantic-release.gitbook.io/semantic-release/usage/configuration#ci) option. You will also have to set the required [authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) via environment variables on your local machine, for example:
```bash
$ NPM_TOKEN= GH_TOKEN= npx semantic-release --no-ci
```
However this is not the recommended approach, as running unit and integration tests on an independent machine before publishing software is a crucial part of the release workflow.
## Can I use semantic-release with GitLab?
Yes, with the [`@semantic-release/gitlab-config`](https://github.com/semantic-release/gitlab-config) shareable configuration.
See the [GitLab CI recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes/gitlab-ci#using-semantic-release-with-gitlab-ci) for the CI configuration.
## Can I use semantic-release with any Git hosted environment?
By default **semantic-release** uses the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin to publish a [GitHub release](https://help.github.com/articles/about-releases). For other Git hosted environment the [`@semantic-release/git`](https://github.com/semantic-release/git) and [`@semantic-release/changelog`](https://github.com/semantic-release/changelog) plugins can be used via [plugins configuration](https://semantic-release.gitbook.io/semantic-release/usage/plugins).
See the [`@semantic-release/git`](https://github.com/semantic-release/git#semantic-releasegit) [`@semantic-release/changelog`](https://github.com/semantic-release/changelog#semantic-releasechangelog) plugins documentation for more details.
## Can I skip the release to the npm registry?
Yes, the publishing to the npm registry can be disabled with the [`npmPublish`](https://github.com/semantic-release/npm#options) option of the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. In addition the [`tarballDir`](https://github.com/semantic-release/npm#options) option allow to generate the package tarball in order to publish it to your repository with the [`@semantic-release/git`](https://github.com/semantic-release/git) or to a [GitHub release](https://help.github.com/articles/about-releases) with the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin.
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#semantic-releasenpm) plugin documentation for more details.
## How can I revert a release?
If you have introduced a breaking bug in a release you have 2 options:
* If you have a fix immediately ready, commit and push it (or merge it via a pull request) to the release branch
* Otherwise, [revert the commit](https://git-scm.com/docs/git-revert) that introduced the bug and push the revert commit (or merge it via a pull request) to the release branch
In both cases **semantic-release** will publish a new release, so your package users will get the fixed/reverted version.
Depending on the package manager you are using, you might be able to un-publish or deprecate a release, in order to prevent users from downloading it by accident. For example, npm allows you to [un-publish](https://docs.npmjs.com/cli/unpublish) [within 72 hours](https://www.npmjs.com/policies/unpublish) after release. You may also [deprecate](https://docs.npmjs.com/cli/deprecate) a release if you would rather avoid un-publishing.
In any case **do not remove the Git tag associated with the buggy version**, otherwise **semantic-release** will later try to republish that version. Publishing a version after un-publishing is not supported by most package managers.
**Note**: If you are using the default [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) be aware that it uses a different revert commit format than the standard one created by [git revert](https://git-scm.com/docs/git-revert), contrary to what is [claimed in the convention](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#revert). Therefore, if you revert a commit with [`git revert`](https://git-scm.com/docs/git-revert), use the [`--edit` option](https://git-scm.com/docs/git-revert#git-revert---edit) to format the message according to the [Angular revert commit message format](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#revert). See [conventional-changelog/conventional-changelog#348](https://github.com/conventional-changelog/conventional-changelog/issues/348) for more details.
## Can I use `.npmrc` options?
Yes, all the [npm configuration options](https://docs.npmjs.com/misc/config) are supported via the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository.
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
## How can I set the access level of the published npm package?
The [npm `access` option](https://docs.npmjs.com/misc/config#access) can be set in the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository:
```
access=public
```
Or with the `publishConfig.access` key in your project's `package.json`:
```javascript
{
"publishConfig": {
"access": "public"
}
}
```
## Can I use semantic-release to publish a package on Artifactory?
Any npm compatible registry is supported with the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. For Artifactory versions prior to 5.4, the legacy authentication has to be used (with `NPM_USERNAME`, `NPM_PASSWORD` and `NPM_EMAIL` [environment variables](https://github.com/semantic-release/npm#environment-variables)).
See [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) for more details.
See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactiry configuration.
## Can I manually trigger the release of a specific version?
You can trigger a release by pushing to your Git repository. You deliberately cannot trigger a *specific* version release, because this is the whole point of semantic-release.
## Can I exclude commits from the analysis?
Yes, every commits that contains `[skip release]` or `[release skip]` in their message will be excluded from the commit analysis and won't participate in the release type determination.
## How can I change the type of commits that trigger a release?
By default **semantic-release** uses the [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) and triggers releases based on the following rules:
| Commit | Release type |
| --------------------------- | -------------------------- |
| Commit with breaking change | ~~Major~~ Breaking release |
| Commit with type `feat` | ~~Minor~~ Feature release |
| Commit with type `fix` | Patch release |
| Commit with type `perf` | Patch release |
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
This is fully customizable with the [`@semantic-release/commit-analyzer`](https://github.com/semantic-release/commit-analyzer) plugin's [`release-rules` option](https://github.com/semantic-release/commit-analyzer#release-rules).
## Is it *really* a good idea to release on every push?
It is indeed a great idea because it *forces* you to follow best practices. If you donât feel comfortable releasing every feature or fix on your `master` you might not treat your `master` branch as intended.
From [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/index.html):
> Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable.
If you need more control over the timing of releases, see [Triggering a release](https://semantic-release.gitbook.io/semantic-release/undefined#triggering-a-release) for different options.
**Note**: Only the codebase changes altering the published package will trigger a release (for example new features, bug fixes or performance improvements would trigger a release while refactoring or changing code style would not). See [How can I change the type of commits that trigger a release?](#how-can-i-change-the-type-of-commits-that-trigger-a-release) for more details.
## Can I set the initial release version of my package to `0.0.1`?
This is not supported by **semantic-release** as it's not considered a good practice, mostly because [Semantic Versioning](https://semver.org) rules applies differently to major version zero.
If your project is under heavy development, with frequent breaking changes, and is not production ready yet we recommend [publishing pre-releases](https://github.com/semantic-release/semantic-release/tree/f01edb8308effce41aadc451c9ebbde4fd2355d4/docs/recipes/pre-releases.md#publishing-pre-releases).
See [âIntroduction to SemVerâ - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) for more details on [Semantic Versioning](https://semver.org) and the recommendation to start at version `1.0.0`.
## Can I trust semantic-release with my releases?
**semantic-release** has a full unit and integration test suite that tests `npm` publishes against the [npm-registry-couchapp](https://github.com/npm/npm-registry-couchapp).
In addition the [verify conditions step](https://semantic-release.gitbook.io/semantic-release/undefined#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
## Why does semantic-release require Node version >= 14.17?
**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 14.17 or higher**.
See [Node version requirement](https://semantic-release.gitbook.io/semantic-release/node-version#node-version-requirement) for more details and solutions.
## Why does semantic-release require Git version >= 2.7.1?
**semantic-release** uses Git CLI commands to read information about the repository such as branches, commit history and tags. Certain commands and options (such as [the `--merged` option of the `git tag` command](https://git-scm.com/docs/git-tag/2.7.0#git-tag---no-mergedltcommitgt) or bug fixes related to `git ls-files`) used by **semantic-release** are only available in Git version 2.7.1 and higher.
## What is npx?
[`npx`](https://www.npmjs.com/package/npx) â short for "npm exec" â is a CLI to find and execute npm binaries within the local `node_modules` folder or in the $PATH. If a binary can't be located npx will download the required package and execute it from its cache location. The tool is bundled with [npm](https://www.npmjs.com/package/npm) >= 5.2, or can be installed via `npm install -g npx`. For more details and motivation read the [introductory blog post](https://medium.com/@maybekatz/introducing-npx-an-npm-package-runner-55f7d4bd282b) by [@zkat](https://github.com/zkat).
# Troubleshooting
## You do not have permission to publish 'package-name'
When running semantic-release you might encounter the following error:
```bash
npm ERR! publish Failed PUT 403
npm ERR! code E403
npm ERR! You do not have permission to publish "". Are you logged in as the correct user? :
```
This is most likely related to a misconfiguration of the [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) or to your user [missing permission](https://docs.npmjs.com/cli/team) for publishing.
It might also happen if the package name you are trying to publish already exists (in the case of npm, you may be trying to publish a new version of a package that is not yours, hence the permission error).
To verify if your package name is available you can use [npm-name-cli](https://github.com/sindresorhus/npm-name-cli):
```bash
$ npm install --global npm-name-cli
$ npm-name
```
If the package name is not available, change it in your `package.json` or consider using an [npm scope](https://docs.npmjs.com/misc/scope).
## Squashed commits are ignored by **semantic-release**
**semantic-release** parses commits according to a [commit message convention](https://github.com/semantic-release/semantic-release#commit-message-format) to figure out how they affect the codebase. Commits that doesn't follow the project's commit message convention are simply ignored.
When [squashing commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) most Git tools will by default generate a new commit message with a summary of the squashed commits. This commit message will most likely not be compliant with the project's commit message convention and therefore will be ignored by **semantic-release**.
When squashing commits make sure to rewrite the resulting commit message to be compliant with the project's commit message convention.
**Note**: if the resulting squashed commit would encompasses multiple changes (for example multiple unrelated features or fixes) then it's probably not a good idea to squash those commits together. A commit should contain exactly one self-contained functional change and a functional change should be contained in exactly one commit. See [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit).
## `reference already exists` error when pushing tag
**semantic-release** read [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) that are present in the history of your release branch in order to determine the last release published. Then it determines the next version to release based on the commits pushed since then and create the corresponding tag. If a tag with the name already in your repository, Git will throw and error as tags must be unique across the repository. This situation happens when you have a version tag identical to the new one **semantic-release** is trying to create that is not in the history of the current branch.
If an actual release with that version number was published you need to merge all the commits up to that release into your release branch.
If there is no published release with that version number, the tag must be deleted.
```bash
# Verify if the commit exists in the repository
$ git rev-list -1
# If a commit sha is returned, then the tag exists
# Verify the branches having the tagged commit in their history
$ git branch --contains
# Delete the tag
$ git tag -d
$ git push origin :refs/tags/
```
## release not found release branch after `git push --force`
**semantic-release** is using both [git tags](https://git-scm.com/docs/git-tag) and [git notes](https://git-scm.com/docs/git-notes) to store information about which releases happened in which branch.
After a git history rewrite due to a `git push --force`, the git tags and notes referencing the commits that were rewritten are lost.
To recover from that situation, do the following:
1. Delete the tag(s) for the release(s) that have been lost from the git history. You can delete each tag from remote using `git push origin :[TAG NAME]`, e.g. `git push origin :v2.0.0-beta.1`. You can delete tags locally using `git tag -d [TAG NAME]`, e.g. `git tag -d v2.0.0-beta.1`.
2. Re-create the tags locally: `git tag [TAG NAME] [COMMIT HASH]`, where `[COMMIT HASH]` is the new commit that created the release for the lost tag. E.g. `git tag v2.0.0-beta.1 abcdef0`
3. Re-create the git notes for each release tag, e.g. `git notes --ref semantic-release add -f -m '{"channels":["beta"]}' v2.0.0-beta.1`. If the release was also published in the default channel (usually `master`), then set the first channel to `null`, e.g. \`git notes --ref semantic-release add -f -m '{"channels":\[null, "beta"]}'
4. Push the local notes: `git push --force origin refs/notes/semantic-release`. The `--force` is needed after the rebase. Be careful.
# Node version requirement
**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which requires **requires Node version 14.17 or higher**.
**semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency. Therefore, the only constraint is to run the `semantic-release` in a CI environment providing Node 14.17 or higher.
See our [Node Support Policy](https://semantic-release.gitbook.io/semantic-release/support/node-support-policy) for our long-term promise regarding Node version support.
## Recommended solution
### Run at least one CI job with Node >= 14.17
The recommended approach is to run the `semantic-release` command from a CI job running on Node 14.17 or higher. This can either be a job used by your project to test on Node >= 14.17 or a dedicated job for the release steps.
See [CI configuration](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration) and [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details.
## Alternative solutions
### Use `npx`
`npx` is included with npm >= 5.2 and can be used to download the latest [Node 14 package published on npm](https://www.npmjs.com/package/node). Use it to execute the `semantic-release` command.
```bash
$ npx -p node@14 -c "npx semantic-release"
```
**Note:**: See [What is npx](https://semantic-release.gitbook.io/semantic-release/faq#what-is-npx) for more details.
### Use `nvm`
If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to Node 14.17 before running the `semantic-release` command.
```bash
$ nvm install 14.17 && npx semantic-release
```
# Node Support Policy
We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 14.17.0 (LTS)](https://nodejs.org/en/blog/release/v14.17.0).
We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment.
It's possible this package will work correctly on newer versions of Node. It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support.
As each Node LTS version reaches its end-of-life we will remove that version from the node engines property of our package's package.json file. Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package. We will not accept any requests to support an end-of-life version of Node. Any merge requests or issues supporting an end-of-life version of Node will be closed.
We will accept code that allows this package to run on newer, non-LTS, versions of Node. Furthermore, we will attempt to ensure our own changes work on the latest version of Node. To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current.
JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property. If you encounter issues installing this package, please report the issue to your package manager.
# README
Fully automated version management and package publishing
**semantic-release** automates the whole package release workflow including: determining the next version number, generating the release notes, and publishing the package.
This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org) specification and communicating the **impact** of changes to consumers.
> Trust us, this will change your workflow for the better. â [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release)
## Highlights
* Fully automated release
* Enforce [Semantic Versioning](https://semver.org) specification
* New features and fixes are immediately available to users
* Notify maintainers and users of new releases
* Use formalized commit message convention to document changes in the codebase
* Publish on different distribution channels (such as [npm dist-tags](https://docs.npmjs.com/cli/dist-tag)) based on git merges
* Integrate with your [continuous integration workflow](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow#ci-configurations)
* Avoid potential errors associated with manual releases
* Support any [package managers and languages](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow#package-managers-and-languages) via [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins)
* Simple and reusable configuration via [shareable configurations](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations)
* Support for [npm package provenance](https://github.com/semantic-release/npm#npm-provenance) that promotes increased supply-chain security via signed attestations on GitHub Actions
## How does it work?
### Commit message format
**semantic-release** uses the commit messages to determine the consumer impact of changes in the codebase. Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publishes the release.
By default, **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md). The commit message format can be changed with the [`preset` or `config` options](https://semantic-release.gitbook.io/semantic-release/usage/configuration#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins.
Tools such as [commitizen](https://github.com/commitizen/cz-cli) or [commitlint](https://github.com/conventional-changelog/commitlint) can be used to help contributors and enforce valid commit messages.
The table below shows which commit message gets you which release type when `semantic-release` runs (using the default configuration):
| Commit message | Release type |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `fix(pencil): stop graphite breaking when too much pressure applied` | ~~Patch~~ Fix Release |
| `feat(pencil): add 'graphiteWidth' option` | ~~Minor~~ Feature Release |
| perf(pencil): remove graphiteWidth optionBREAKING CHANGE: The graphiteWidth option has been removed.The default graphite width of 10mm is always used for performance reasons.
| Major Breaking ReleaseBREAKING CHANGE: token must be in the footer of the commit)
|
### Automation with CI
**semantic-release** is meant to be executed on the CI environment after every successful build on the release branch. This way no human is directly involved in the release process and the releases are guaranteed to be [unromantic and unsentimental](https://github.com/dominictarr/sentimental-versioning#readme).
### Triggering a release
For each new commit added to one of the release branches (for example: `master`, `main`, `next`, `beta`), with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities.
**semantic-release** offers various ways to control the timing, the content and the audience of published releases. See example workflows in the following recipes:
* [Using distribution channels](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/distribution-channels#publishing-on-distribution-channels)
* [Maintenance releases](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/maintenance-releases#publishing-maintenance-releases)
* [Pre-releases](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/pre-releases#publishing-pre-releases)
### Release steps
After running the tests, the command `semantic-release` will execute the following steps:
| Step | Description |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Verify Conditions | Verify all the conditions to proceed with the release. |
| Get last release | Obtain the commit corresponding to the last release by analyzing [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). |
| Analyze commits | Determine the type of release based on the commits added since the last release. |
| Verify release | Verify the release conformity. |
| Generate notes | Generate release notes for the commits added since the last release. |
| Create Git tag | Create a Git tag corresponding to the new release version. |
| Prepare | Prepare the release. |
| Publish | Publish the release. |
| Notify | Notify of new releases or errors. |
## Requirements
In order to use **semantic-release** you need:
* To host your code in a [Git repository](https://git-scm.com)
* Use a Continuous Integration service that allows you to [securely set up credentials](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication)
* A Git CLI version that meets [our version requirement](https://semantic-release.gitbook.io/semantic-release/support/git-version) installed in your Continuous Integration environment
* A [Node.js](https://nodejs.org) version that meets [our version requirement](https://semantic-release.gitbook.io/semantic-release/support/node-version) installed in your Continuous Integration environment
## Documentation
* Usage
* [Getting started](https://semantic-release.gitbook.io/semantic-release/usage/getting-started)
* [Installation](https://semantic-release.gitbook.io/semantic-release/usage/installation)
* [CI Configuration](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration)
* [Configuration](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration)
* [Plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins)
* [Workflow configuration](https://semantic-release.gitbook.io/semantic-release/usage/workflow-configuration)
* [Shareable configurations](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations)
* Extending
* [Plugins](https://semantic-release.gitbook.io/semantic-release/extending/plugins-list)
* [Shareable configuration](https://semantic-release.gitbook.io/semantic-release/extending/shareable-configurations-list)
* Recipes
* [CI configurations](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations)
* [Git hosted services](https://semantic-release.gitbook.io/semantic-release/recipes/git-hosted-services)
* [Release workflow](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow)
* Developer guide
* [JavaScript API](https://semantic-release.gitbook.io/semantic-release/developer-guide/js-api)
* [Plugins development](https://semantic-release.gitbook.io/semantic-release/developer-guide/plugin)
* [Shareable configuration development](https://semantic-release.gitbook.io/semantic-release/developer-guide/shareable-configuration)
* Support
* [Resources](https://semantic-release.gitbook.io/semantic-release/support/resources)
* [Frequently Asked Questions](https://semantic-release.gitbook.io/semantic-release/support/faq)
* [Troubleshooting](https://semantic-release.gitbook.io/semantic-release/support/troubleshooting)
* [Node version requirement](https://semantic-release.gitbook.io/semantic-release/support/node-version)
* [Node Support Policy](https://semantic-release.gitbook.io/semantic-release/support/node-support-policy)
## Get help
* [GitHub Discussions](https://github.com/semantic-release/semantic-release/discussions)
* [Stack Overflow](https://stackoverflow.com/questions/tagged/semantic-release)
## Badge
Let people know that your package is published using **semantic-release** and which [commit-convention](#commit-message-format) is followed by including this badge in your readme.
[](https://github.com/semantic-release/semantic-release)
```md
[](https://github.com/semantic-release/semantic-release)
```
## Team
| [](https://github.com/gr2m) | [](https://github.com/pvdlg) | [](https://github.com/travi) |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- |
| [Gregor Martynus](https://github.com/gr2m) | [Pierre Vanduynslager](https://github.com/pvdlg) | [Matt Travi](https://github.com/travi) |
## Alumni
| [](https://github.com/boennemann) | [](https://github.com/relekang) | [](https://github.com/jo) | [](https://github.com/finnp) | [](https://github.com/christophwitzko) |
| ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| [Stephan Bönnemann](https://github.com/boennemann) | [Rolf Erik Lekang](https://github.com/relekang) | [Johannes Jörg Schmidt](https://github.com/jo) | [Finn Pauls](https://github.com/finnp) | [Christoph Witzko](https://github.com/christophwitzko) |
.*?)\\s"],
"datasourceTemplate": "npm",
"depNameTemplate": "semantic-release"
}
]
}
```
4. `npx` is a tool bundled with `npm@>=5.2.0`. You can use it to install (and run) the **semantic-release** binary. See [What is npx](https://semantic-release.gitbook.io/semantic-release/support/faq#what-is-npx) for more details.
## Local installation
Since **semantic-release** isn't truly a development dependency, but rather a release dependency, we recommend avoiding installation as a local dependency of your project. Instead, we recommend installing it globally in your CI environment as part of executing with [npx](https://semantic-release.gitbook.io/semantic-release/support/faq#what-is-npx) as described [above](#global-insallation). Installing only during the release process avoids:
* installing unnecessary dependencies during development and testing, including the fairly sizable dependency on **npm**
* installing a different version of **npm** into `node_modules/` than the one used to run the release, which can lead to conflicts and unexpected behavior
* installing dependencies that could conflict with other development dependencies, like **commitlint**
# CI Configuration
## Run `semantic-release` only after all tests succeeded
The `semantic-release` command must be executed only after all the tests in the CI build pass. If the build runs multiple jobs (for example to test on multiple Operating Systems or Node versions) the CI has to be configured to guarantee that the `semantic-release` command is executed only after all jobs are successful. Here are a few examples of the CI services that can be used to achieve this:
* [Travis Build Stages](https://docs.travis-ci.com/user/build-stages)
* [CircleCI Workflows](https://circleci.com/docs/2.0/workflows)
* [GitHub Actions](https://github.com/features/actions)
* [Codeship Deployment Pipelines](https://documentation.codeship.com/basic/builds-and-configuration/deployment-pipelines)
* [GitLab Pipelines](https://docs.gitlab.com/ee/ci/pipelines/)
* [Codefresh Pipelines](https://codefresh.io/docs/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines)
* [Wercker Workflows](http://devcenter.wercker.com/docs/workflows)
* [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline).
See [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations) for more details.
## Authentication
### Push access to the remote repository
**semantic-release** requires push access to the project Git repository in order to create [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). The Git authentication can be set with one of the following environment variables:
| Variable | Description |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `GH_TOKEN` or `GITHUB_TOKEN` | A GitHub [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line). |
| `GL_TOKEN` or `GITLAB_TOKEN` | A GitLab [personal access token](https://docs.gitlab.com/ce/user/profile/personal_access_tokens.html). |
| `BB_TOKEN` or `BITBUCKET_TOKEN` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html). |
| `BB_TOKEN_BASIC_AUTH` or `BITBUCKET_TOKEN_BASIC_AUTH` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) with basic auth support. For clarification `user:token` has to be the value of this env. |
| `GIT_CREDENTIALS` | [URL encoded](https://en.wikipedia.org/wiki/Percent-encoding) Git username and password in the format `:`. The username and password must each be individually URL encoded, not the `:` separating them. |
Alternatively the Git authentication can be set up via [SSH keys](https://semantic-release.gitbook.io/semantic-release/recipes/git-hosted-services/git-auth-ssh-keys).
### Authentication for plugins
Most **semantic-release** [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins) require setting up authentication in order to publish to a package manager registry. The default [@semantic-release/npm](https://github.com/semantic-release/npm#environment-variables) and [@semantic-release/github](https://github.com/semantic-release/github#environment-variables) plugins require the following environment variables:
| Variable | Description |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `NPM_TOKEN` | npm token created via npm token create .Note : Only the auth-only level of npm two-factor authentication is supported.
|
| `GH_TOKEN` | GitHub authentication token.Note : Only the personal token authentication is supported.
|
See each plugin's documentation for the environment variables required.
The authentication token/credentials have to be made available in the CI service via environment variables.
See [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations) for more details on how to configure environment variables in your CI service.
**Note**: The environment variables `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN` and `GITLAB_TOKEN` can be used for both the Git authentication and the API authentication required by [@semantic-release/github](https://github.com/semantic-release/github) and [@semantic-release/gitlab](https://github.com/semantic-release/gitlab).
# Configuration
**semantic-release** configuration consists of:
* Git repository ([URL](#repositoryurl) and options [release branches](#branches) and [tag format](#tagformat))
* Plugins [declaration](#plugins) and options
* Run mode ([debug](#debug), [dry run](#dryrun) and [local (no CI)](#ci))
All of these options can be configured through config file, CLI arguments or by extending a [shareable configuration](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations).
Additionally, metadata of Git tags generated by **semantic-release** can be customized via standard [Git environment variables](#git-environment-variables).
## Configuration file
**semantic-release**âs [options](#options), mode and [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins) can be set via either:
* A `.releaserc` file, written in YAML or JSON, with optional extensions: `.yaml`/`.yml`/`.json`/`.js`/`.cjs`/`.mjs`
* A `release.config.(js|cjs|.mjs)` file that exports an object
* A `release` key in the project's `package.json` file
Alternatively, some options can be set via CLI arguments.
The following three examples are the same. Use main instead of master if your default branch is main.
* Via `release` key in the project's `package.json` file:
```json
{
"release": {
"branches": ["master", "next"]
}
}
```
* Via `.releaserc` file:
```json
{
"branches": ["master", "next"]
}
```
* Via `release.config.cjs` file:
```js
/**
* @type {import('semantic-release').GlobalConfig}
*/
module.exports = {
branches: ["master", "next"],
};
```
* Via `release.config.mjs` file:
```js
/**
* @type {import('semantic-release').GlobalConfig}
*/
export default {
branches: ["master", "next"],
};
```
* Via CLI argument:
```bash
$ semantic-release --branches next
```
**Note**: CLI arguments take precedence over options configured in the configuration file.
**Note**: Plugin options cannot be defined via CLI arguments and must be defined in the configuration file.
**Note**: When configuring via `package.json`, the configuration must be under the `release` property. However, when using a `.releaserc` or a `release.config` file, the configuration must be set without a `release` property.
## Options
### extends
Type: `Array`, `String`\
CLI arguments: `-e`, `--extends`
List of modules or file paths containing a [shareable configuration](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations). If multiple shareable configurations are set, they will be imported in the order defined with each configuration option taking precedence over the options defined in a previous shareable configuration.
**Note**: Options defined via CLI arguments or in the configuration file will take precedence over the ones defined in any shareable configuration.
### branches
Type: `Array`, `String`, `Object`\
Default: `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'main', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`\
CLI arguments: `--branches`
The branches on which releases should happen. By default **semantic-release** will release:
* regular releases to the default distribution channel from the branch `master` or `main`
* regular releases to a distribution channel matching the branch name from any existing branch with a name matching a maintenance release range (`N.N.x` or `N.x.x` or `N.x` with `N` being a number)
* regular releases to the `next` distribution channel from the branch `next` if it exists
* regular releases to the `next-major` distribution channel from the branch `next-major` if it exists
* pre-releases to the `beta` distribution channel from the branch `beta` if it exists
* pre-releases to the `alpha` distribution channel from the branch `alpha` if it exists
**Note**: Branches configuration key accepts [**micromatch**](https://github.com/micromatch/micromatch?tab=readme-ov-file#matching-features) globs.
**Note**: If your repository does not have a release branch, then **semantic-release** will fail with an `ERELEASEBRANCHES` error message. If you are using the default configuration, you can fix this error by pushing a `master` or `main` branch.
**Note**: Once **semantic-release** is configured, any user with the permission to push commits on one of those branches will be able to publish a release. It is recommended to protect those branches, for example with [GitHub protected branches](https://docs.github.com/github/administering-a-repository/about-protected-branches).
See [Workflow configuration](https://semantic-release.gitbook.io/semantic-release/workflow-configuration#workflow-configuration) for more details.
### repositoryUrl
Type: `String`\
Default: `repository` property in `package.json` or [git origin url](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes)\
CLI arguments: `-r`, `--repository-url`
The git repository URL.
Any valid git url format is supported (See [Git protocols](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols)).
### tagFormat
Type: `String`\
Default: `v${version}`\
CLI arguments: `-t`, `--tag-format`
The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) format used by **semantic-release** to identify releases. The tag name is generated with [Lodash template](https://lodash.com/docs#template) and will be compiled with the `version` variable.
**Note**: The `tagFormat` must contain the `version` variable exactly once and compile to a [valid Git reference](https://git-scm.com/docs/git-check-ref-format#_description).
### plugins
Type: `Array`\
Default: `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`\
CLI arguments: `-p`, `--plugins`
Define the list of plugins to use. Plugins will run in series, in the order defined, for each [steps](https://semantic-release.gitbook.io/semantic-release/readme#release-steps) if they implement it.
Plugins configuration can defined by wrapping the name and an options object in an array.
See [Plugins configuration](https://semantic-release.gitbook.io/semantic-release/plugins#plugins) for more details.
### dryRun
Type: `Boolean`\
Default: `false` if running in a CI environment, `true` otherwise\
CLI arguments: `-d`, `--dry-run`
The objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, addChannel, success and fail. In addition to this it prints the next version and release notes to the console.
**Note**: The Dry-run mode verifies the repository push permission, even though nothing will be pushed. The verification is done to help user to figure out potential configuration issues.
### ci
Type: `Boolean`\
Default: `true`\
CLI arguments: `--ci` / `--no-ci`
Set to `false` to skip Continuous Integration environment verifications. This allows for making releases from a local machine.
**Note**: The CLI arguments `--no-ci` is equivalent to `--ci false`.
### debug
Type: `Boolean`\
Default: `false`\
CLI argument: `--debug`
Output debugging information. This can also be enabled by setting the `DEBUG` environment variable to `semantic-release:*`.
**Note**: The `debug` is used only supported via CLI argument. To enable debug mode from the [JS API](https://semantic-release.gitbook.io/semantic-release/developer-guide/js-api#javascript-api) use `require('debug').enable('semantic-release:*')`.
## Git environment variables
| Variable | Description | Default |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------ |
| `GIT_AUTHOR_NAME` | The author name associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot. |
| `GIT_AUTHOR_EMAIL` | The author email associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot email address. |
| `GIT_COMMITTER_NAME` | The committer name associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot. |
| `GIT_COMMITTER_EMAIL` | The committer email associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot email address. |
## Existing version tags
**semantic-release** uses [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) to determine the commits added since the last release. If a release has been published before setting up **semantic-release** you must make sure the most recent commit included in the last published release is in the [release branches](#branches) history and is tagged with the version released, formatted according to the [tag format](#tagformat) configured (defaults to `vx.y.z`).
If the previous releases were published with [`npm publish`](https://docs.npmjs.com/cli/publish) this should already be the case.
For example, if your release branch is `master`/`main`, the last release published on your project is `1.1.0` and the last commit included has the sha `1234567`, you must make sure this commit is in `master`/`main` history and is tagged with `v1.1.0`.
```bash
# Make sure the commit 1234567 is in the release branch history
$ git branch --contains 1234567
# If the commit is not in the branch history it means that either:
# - you use a different branch than the one your release from before
# - or the commit sha has been rewritten (with git rebase)
# In both cases you need to configure your repository to have the last release commit in the history of the release branch
# List the tags for the commit 1234567
$ git tag --contains 1234567
# If v1.1.0 is not in the list you add it with
$ git tag v1.1.0 1234567
$ git push origin v1.1.0
```
# Plugins
Each [release step](https://semantic-release.gitbook.io/semantic-release/readme#release-steps) is implemented by configurable plugins. This allows for support of different [commit message formats](https://semantic-release.gitbook.io/semantic-release/readme#commit-message-format), release note generators and publishing platforms.
A plugin is a npm module that can implement one or more of the following steps:
| Step | Required | Description |
| ------------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `verifyConditions` | No | Responsible for verifying conditions necessary to proceed with the release: configuration is correct, authentication token are valid, etc... |
| `analyzeCommits` | Yes | Responsible for determining the type of the next release (`major`, `minor` or `patch`). If multiple plugins with a `analyzeCommits` step are defined, the release type will be the highest one among plugins output. |
| `verifyRelease` | No | Responsible for verifying the parameters (version, type, dist-tag etc...) of the release that is about to be published. |
| `generateNotes` | No | Responsible for generating the content of the release note. If multiple plugins with a `generateNotes` step are defined, the release notes will be the result of the concatenation of each plugin output. |
| `prepare` | No | Responsible for preparing the release, for example creating or updating files such as `package.json`, `CHANGELOG.md`, documentation or compiled assets and pushing a commit. |
| `publish` | No | Responsible for publishing the release. |
| `addChannel` | No | Responsible for adding a release channel (e.g. adding an npm dist-tag to a release). |
| `success` | No | Responsible for notifying of a new release. |
| `fail` | No | Responsible for notifying of a failed release. |
Release steps will run in that order. At each step, **semantic-release** will run every plugin in the [`plugins` array](#plugins-declaration-and-execution-order), as long as the plugin implements the step.
**Note:** If no plugin with a `analyzeCommits` step is defined `@semantic-release/commit-analyzer` will be used.
## Plugins installation
### Default plugins
These four plugins are already part of **semantic-release** and are listed in order of execution. They do not have to be installed separately:
```
"@semantic-release/commit-analyzer"
"@semantic-release/release-notes-generator"
"@semantic-release/npm"
"@semantic-release/github"
```
### Additional plugins
[Additional plugins](https://semantic-release.gitbook.io/semantic-release/extending/plugins-list) have to be installed via npm:
```bash
$ npm install @semantic-release/git @semantic-release/changelog -D
```
## Plugins declaration and execution order
Each plugin must be configured with the [`plugins` options](https://semantic-release.gitbook.io/semantic-release/configuration#plugins) by specifying the list of plugins by npm module name.
```json
{
"plugins": ["@semantic-release/commit-analyzer", "@semantic-release/release-notes-generator", "@semantic-release/npm"]
}
```
**Note:** If the `plugins` option is defined, it overrides the default plugin list, rather than merging with it.
For each [release step](https://semantic-release.gitbook.io/semantic-release/readme#release-steps) the plugins that implement that step will be executed in the order in which they are defined.
```json
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/npm",
"@semantic-release/git"
]
}
```
With this configuration **semantic-release** will:
* execute the `verifyConditions` implementation of `@semantic-release/npm` then `@semantic-release/git`
* execute the `analyzeCommits` implementation of `@semantic-release/commit-analyzer`
* execute the `generateNotes` implementation of `@semantic-release/release-notes-generator`
* execute the `prepare` implementation of `@semantic-release/npm` then `@semantic-release/git`
* execute the `publish` implementation of `@semantic-release/npm`
Order is first determined by release steps (such as `verifyConditions` â `analyzeCommits`). At each release step, plugins are executed in the order in which they are defined.
## Plugin options configuration
A plugin configuration can be specified by wrapping the name and an options object in an array. Options configured this way will be passed only to that specific plugin.
Global plugin configuration can be defined at the root of the **semantic-release** configuration object. Options configured this way will be passed to all plugins.
```json
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
[
"@semantic-release/github",
{
"assets": ["dist/**"]
}
],
"@semantic-release/git"
],
"preset": "angular"
}
```
With this configuration:
* All plugins will receive the `preset` option, which will be used by both `@semantic-release/commit-analyzer` and `@semantic-release/release-notes-generator` (and ignored by `@semantic-release/github` and `@semantic-release/git`)
* The `@semantic-release/github` plugin will receive the `assets` options (`@semantic-release/git` will not receive it and therefore will use it's default value for that option)
# Release Workflow configuration
**semantic-release** enables managing and automating complex release workflow, based on multiple Git branches and distribution channels. This enables:
* Distributing certain releases to a particular group of users via distribution channels
* Managing the availability of releases on distribution channels via branches merge
* Maintaining multiple lines of releases in parallel
* Working on large future releases outside the normal flow of one version increment per Git push
See [Release workflow recipes](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow#release-workflow) for detailed examples.
The release workflow is configured via the [branches option](https://semantic-release.gitbook.io/semantic-release/configuration#branches) which accepts a single or an array of branch definitions. Each branch can be defined either as a string, a [glob](https://github.com/micromatch/micromatch#matching-features) or an object. For string and glob definitions each [property](#branches-properties) will be defaulted.
A branch can be defined as one of three types:
* [release](#release-branches): to make releases on top of the last version released
* [maintenance](#maintenance-branches): to make releases on top of an old release
* [pre-release](#pre-release-branches): to make pre-releases
The type of the branch is automatically determined based on naming convention and/or [properties](#branches-properties).
## Branches properties
| Property | Branch type | Description | Default |
| ------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| `name` | All | **Required.** The Git branch holding the commits to analyze and the code to release. See [name](#name). | - The value itself if defined as a `String` or the matching branches name if defined as a glob. |
| `channel` | All | The distribution channel on which to publish releases from this branch. Set to `false` to force the default distribution channel instead of using the default. See [channel](#channel). | `undefined` for the first release branch, the value of `name` for subsequent ones. |
| `range` | [maintenance](#maintenance-branches) only | **Required unless `name` is formatted like `N.N.x` or `N.x` (`N` is a number).** The range of [semantic versions](https://semver.org) to support on this branch. See [range](#range). | The value of `name`. |
| `prerelease` | [pre-release](#pre-release-branches) only | **Required.** The pre-release denotation to append to [semantic versions](https://semver.org) released from this branch. See [prerelease](#prerelease). | - |
### name
A `name` is required for any type of branch. It can be defined as a [glob](https://github.com/micromatch/micromatch#matching-features) in which case the definition will be expanded to one per matching branch existing in the repository.
If `name` doesn't match to any branch existing in the repository, the definition will be ignored. For example the default configuration includes the definition `next` and `next-major` which will become active only when the branches `next` and/or `next-major` are created in the repository. This allow to define your workflow once with all potential branches you might use and have the effective configuration evolving as you create new branches.
For example the configuration `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next']` will be expanded as:
```js
{
branches: [
{ name: "1.x", range: "1.x", channel: "1.x" }, // Only after the `1.x` is created in the repo
{ name: "2.x", range: "2.x", channel: "2.x" }, // Only after the `2.x` is created in the repo
{ name: "master" },
{ name: "next", channel: "next" }, // Only after the `next` is created in the repo
];
}
```
### channel
The `channel` can be defined for any branch type. By default releases will be done on the default distribution channel (for example the `@latest` [dist-tag](https://docs.npmjs.com/cli/dist-tag) for npm) for the first [release branch](#release-branches) and on a distribution channel named based on the branch `name` for any other branch. If the `channel` property is set to `false` the default channel will be used.
The value of `channel`, if defined as a string, is generated with [Lodash template](https://lodash.com/docs#template) with the variable `name` available.
For example the configuration `['master', {name: 'next', channel: 'channel-${name}'}]` will be expanded as:
```js
{
branches: [
{ name: "master" }, // `channel` is undefined so the default distribution channel will be used
{ name: "next", channel: "channel-next" }, // `channel` is built with the template `channel-${name}`
];
}
```
### range
A `range` only applies to maintenance branches, is required and must be formatted like `N.N.x` or `N.x` (`N` is a number). In case the `name` is formatted as a range (for example `1.x` or `1.5.x`) the branch will be considered a maintenance branch and the `name` value will be used for the `range`.
For example the configuration `['1.1.x', '1.2.x', 'master']` will be expanded as:
```js
{
branches: [
{ name: "1.1.x", range: "1.1.x", channel: "1.1.x" },
{ name: "1.2.x", range: "1.2.x", channel: "1.2.x" },
{ name: "master" },
];
}
```
### prerelease
A `prerelease` property applies only to pre-release branches and the `prerelease` value must be valid per the [Semantic Versioning Specification](https://semver.org/#spec-item-9). It will determine the name of versions (for example if `prerelease` is set to `beta` the version be formatted like `2.0.0-beta.1`, `2.0.0-beta.2` etc...). If the `prerelease` property is set to `true` the `name` value will be used.
The value of `prerelease`, if defined as a string, is generated with [Lodash template](https://lodash.com/docs#template) with the variable `name` available.
For example the configuration `['master', {name: 'pre/rc', prerelease: '${name.replace(/^pre\\//g, "")}'}, {name: 'beta', prerelease: true}]` will be expanded as:
```js
{
branches: [
{ name: "master" },
{ name: "pre/rc", channel: "pre/rc", prerelease: "rc" }, // `prerelease` is built with the template `${name.replace(/^pre\\//g, "")}`
{ name: "beta", channel: "beta", prerelease: true }, // `prerelease` is set to `beta` as it is the value of `name`
];
}
```
## Branch types
### Release branches
A release branch is the base type of branch used by **semantic-release** that allows to publish releases with a [semantic version](https://semver.org), optionally on a specific distribution channel. Distribution channels (for example [npm dist-tags](https://docs.npmjs.com/cli/dist-tag) or [Chrome release channels](https://www.chromium.org/getting-involved/dev-channel)) are a way to distribute new releases only to a subset of users in order to get early feedback. Later on, those releases can be added to the general distribution channel to be made available to all users.
**semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release branch to another](#merging-into-a-release-branch).
A project must define a minimum of 1 release branch and can have a maximum of 3. The order of the release branch definitions is significant, as versions released on a given branch must always be higher than the last release made on the previous branch. This allow to avoid situation that would lead to an attempt to publish releases with the same version number but different codebase. When multiple release branches are configured and a commit that would create a version conflict is pushed, **semantic-release** will not perform the release and will throw an `EINVALIDNEXTVERSION` error, listing the problematic commits and the valid branches on which to move them.
**Note:** With **semantic-release** as with most package managers, a release version must be unique, independently of the distribution channel on which it is available.
See [publishing on distribution channels recipe](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/distribution-channels) for a detailed example.
#### Pushing to a release branch
With the configuration `"branches": ["master", "next"]`, if the last release published from `master` is `1.0.0` and the last one from `next` is `2.0.0` then:
* Only versions in range `1.x.x` can be published from `master`, so only `fix` and `feat` commits can be pushed to `master`
* Once `next` get merged into `master` the release `2.0.0` will be made available on the channel associated with `master` and both `master` and `next` will accept any commit type
This verification prevent scenario such as:
1. Create a `feat` commit on `next` which triggers the release of version `1.0.0` on the `next` channel
2. Merge `next` into `master` which adds `1.0.0` on the default channel
3. Create a `feat` commit on `next` which triggers the release of version `1.1.0` on the `next` channel
4. Create a `feat` commit on `master` which would attempt to release the version `1.1.0` on the default channel
In step 4 **semantic-release** will throw an `EINVALIDNEXTVERSION` error to prevent the attempt at releasing version `1.1.0` which was already released on step 3 with a different codebase. The error will indicate that the commit should be created on `next` instead. Alternatively if the `next` branch is merged into `master`, the version `1.1.0` will be made available on the default channel and the `feat` commit would be allowed on `master` to release `1.2.0`.
#### Merging into a release branch
When merging commits associated with a release from one release branch to another, **semantic-release** will make the corresponding version available on the channel associated with the target branch.
When merging commits not associated with a release, commits from a [maintenance branch](#maintenance-branches) or commits from a [pre-release branch](#pre-release-branches) **semantic-release** will treat them as [pushed commits](#pushing-to-a-release-branch) and publish a new release if necessary.
### Maintenance branches
A maintenance branch is a type of branch used by **semantic-release** that allows to publish releases with a [semantic version](https://semver.org) on top of the codebase of an old release. This is useful when you need to provide fixes or features to users who cannot upgrade to the last version of your package.
A maintenance branch is characterized by a range which defines the versions that can be published from it. The [`range`](#range) value of each maintenance branch must be unique across the project.
**semantic-release** will always publish releases to a distribution channel specific to the range, so only the users who choose to use that particular line of versions will receive new releases.
Maintenance branches are always considered lower than [release branches](#release-branches) and similarly to them, when a commit that would create a version conflict is pushed, **semantic-release** will not perform the release and will throw an `EINVALIDNEXTVERSION` error, listing the problematic commits and the valid branches on which to move them.
**semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release or maintenance branch to another maintenance branch](#merging-into-a-maintenance-branch), however only versions within the branch `range` can be merged. If a merged version is outside the maintenance branch `range`, **semantic-release** will not add to the corresponding channel and will throw an `EINVALIDMAINTENANCEMERGE` error.
See [publishing maintenance releases recipe](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/maintenance-releases) for a detailed example.
#### Pushing to a maintenance branch
With the configuration `"branches": ["1.0.x", "1.x", "master"]`, if the last release published from `master` is `1.5.0` then:
* Only versions in range `>=1.0.0 <1.1.0` can be published from `1.0.x`, so only `fix` commits can be pushed to `1.0.x`
* Only versions in range `>=1.1.0 <1.5.0` can be published from `1.x`, so only `fix` and `feat` commits can be pushed to `1.x` as long the resulting release is lower than `1.5.0`
* Once `2.0.0` is released from `master`, versions in range `>=1.1.0 <2.0.0` can be published from `1.x`, so any number of `fix` and `feat` commits can be pushed to `1.x`
#### Merging into a maintenance branch
With the configuration `"branches": ["1.0.x", "1.x", "master"]`, if the last release published from `master` is `1.0.0` then:
* Creating the branch `1.0.x` from `master` will make the `1.0.0` release available on the `1.0.x` distribution channel
* Pushing a `fix` commit on the `1.0.x` branch will release the version `1.0.1` on the `1.0.x` distribution channel
* Creating the branch `1.x` from `master` will make the `1.0.0` release available on the `1.x` distribution channel
* Merging the branch `1.0.x` into `1.x` will make the version `1.0.1` available on the `1.x` distribution channel
### Pre-release branches
A pre-release branch is a type of branch used by **semantic-release** that allows to publish releases with a [pre-release version](https://semver.org/#spec-item-9). Using a pre-release version allow to publish multiple releases with the same version. Those release will be differentiated via their identifiers (in `1.0.0-alpha.1` the identifier is `alpha.1`). This is useful when you need to work on a future major release that will include many breaking changes but you do not want to increment the version number for each breaking change commit.
A pre-release branch is characterized by the `prerelease` property that defines the static part of the version released (in `1.0.0-alpha.1` the static part fo the identifier is `alpha`). The [`prerelease`](#prerelease) value of each pre-release branch must be unique across the project.
**semantic-release** will always publish pre-releases to a specific distribution channel, so only the users who choose to use that particular line of versions will receive new releases.
When merging commits associated with an existing release, **semantic-release** will treat them as [pushed commits](#pushing-to-a-pre-release-branch) and publish a new release if necessary, but it will never add those releases to the distribution channel corresponding to the pre-release branch.
See [publishing pre-releases recipe](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/pre-releases) for a detailed example.
#### Pushing to a pre-release branch
With the configuration `"branches": ["master", {"name": "beta", "prerelease": true}]`, if the last release published from `master` is `1.0.0` then:
* Pushing a `BREAKING CHANGE` commit on the `beta` branch will release the version `2.0.0-beta.1` on the `beta` distribution channel
* Pushing either a `fix`, `feat` or a `BREAKING CHANGE` commit on the `beta` branch will release the version `2.0.0-beta.2` (then `2.0.0-beta.3`, `2.0.0-beta.4`, etc...) on the `beta` distribution channel
#### Merging into a pre-release branch
With the configuration `"branches": ["master", {"name": "beta", "prerelease": true}]`, if the last release published from `master` is `1.0.0` and the last one published from `beta` is `2.0.0-beta.1` then:
* Pushing a `fix` commit on the `master` branch will release the version `1.0.1` on the default distribution channel
* Merging the branch `master` into `beta` will release the version `2.0.0-beta.2` on the `beta` distribution channel
# Shareable configurations
A shareable configuration is an [npm](https://www.npmjs.com/) package that exports a **semantic-release** configuration object. It allows for use of the same configuration across several projects.
The shareable configurations to use can be set with the [extends](https://semantic-release.gitbook.io/semantic-release/configuration#extends) option.
See [shareable configurations list](https://semantic-release.gitbook.io/semantic-release/extending/shareable-configurations-list).
# Plugins
## Official plugins
* [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `analyzeCommits`: Determine the type of release by analyzing commits with [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog)
* [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `generateNotes`: Generate release notes for the commits added since the last release with [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog)
* [@semantic-release/github](https://github.com/semantic-release/github)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `verifyConditions`: Verify the presence and the validity of the GitHub authentication and release configuration
* `publish`: Publish a [GitHub release](https://help.github.com/articles/about-releases)
* `success`: Add a comment to GitHub issues and pull requests resolved in the release
* `fail`: Open a GitHub issue when a release fails
* [@semantic-release/npm](https://github.com/semantic-release/npm)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `verifyConditions`: Verify the presence and the validity of the npm authentication and release configuration
* `prepare`: Update the package.json version and create the npm package tarball
* `publish`: Publish the package on the npm registry
* [@semantic-release/gitlab](https://github.com/semantic-release/gitlab)
* `verifyConditions`: Verify the presence and the validity of the GitLab authentication and release configuration
* `publish`: Publish a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/)
* [@semantic-release/git](https://github.com/semantic-release/git)
* `verifyConditions`: Verify the presence and the validity of the Git authentication and release configuration
* `prepare`: Push a release commit and tag, including configurable files
* [@semantic-release/changelog](https://github.com/semantic-release/changelog)
* `verifyConditions`: Verify the presence and the validity of the configuration
* `prepare`: Create or update the changelog file in the local project repository
* [@semantic-release/exec](https://github.com/semantic-release/exec)
* `verifyConditions`: Execute a shell command to verify if the release should happen
* `analyzeCommits`: Execute a shell command to determine the type of release
* `verifyRelease`: Execute a shell command to verifying a release that was determined before and is about to be published
* `generateNotes`: Execute a shell command to generate the release note
* `prepare`: Execute a shell command to prepare the release
* `publish`: Execute a shell command to publish the release
* `success`: Execute a shell command to notify of a new release
* `fail`: Execute a shell command to notify of a failed release
* [@semantic-release/apm](https://github.com/semantic-release/apm)
* `verifyConditions`: Verify the presence of the `ATOM_ACCESS_TOKEN` environment variable and the [`apm`](https://github.com/atom/apm) CLI
* `prepare`: Update the `package.json` version with [`npm version`](https://docs.npmjs.com/cli/version)
* `publish`: Publish the [Atom package](https://flight-manual.atom.io/hacking-atom/sections/publishing)
## Community plugins
[Open a Pull Request](https://github.com/semantic-release/semantic-release/blob/master/CONTRIBUTING.md#submitting-a-pull-request) to add your plugin to the list.
* [semantic-release-slack-bot](https://github.com/juliuscc/semantic-release-slack-bot)
* `verifyConditions`: Verify that the environment variable `SLACK_WEBHOOK` has been defined.
* `success`: Publish a message about the success to a slack channel.
* `fail`: Optionally publish a message about failure to a slack channel.
* [semantic-release-docker](https://github.com/felixfbecker/semantic-release-docker)
* `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry.
* `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
* [@semantic-release-plus/docker](https://github.com/semantic-release-plus/semantic-release-plus/tree/master/packages/plugins/docker)
* `verifyConditions`: Verify that all needed configuration is present and login to the configured docker registry.
* `publish`: Tag the image specified by `name` with the new version and channel and push it to the configured docker registry.
* `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry i.e.: next to latest.
* [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr)
* `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry
* `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
* [semantic-release-vsce](https://github.com/raix/semantic-release-vsce)
* `verifyConditions`: Verify the presence and the validity of the "VS Code extension" authentication and release configuration
* `prepare`: Create a `.vsix` for distribution
* `publish`: Publish the package to the Visual Studio Code marketplace
* [semantic-release-verify-deps](https://github.com/piercus/semantic-release-verify-deps)
* `verifyConditions`: Check the dependencies format against a regexp before a release
* [semantic-release-openapi](https://github.com/aensley/semantic-release-openapi)
* `verifyConditions`: Verify `apiSpecFiles` is specified with at least one file name and all matching files have a .json, .yaml, or .yml extension.
* `prepare`: Write the correct version to all OpenAPI / Swagger files specified in `apiSpecFiles`.
* [semantic-release-chrome](https://github.com/GabrielDuarteM/semantic-release-chrome)
* `verifyConditions`: Verify the presence of the authentication (set via environment variables)
* `prepare`: Write the correct version to the `manifest.json` and creates a zip file of the whole dist folder
* `publish`: Uploads the generated zip file to the webstore, and publish the item
* [semantic-release-firefox-add-on](https://github.com/tophat/semantic-release-firefox-add-on)
* `verifyConditions`: Verify that all required options are present and authentication is set via environment variables
* `prepare`: Write the correct version to the `manifest.json`
* `publish`: Creates an unsigned `.xpi` file, and submits it to the Mozilla Add On store for signing. Once the package is signed, downloads the signed `.xpi` to a local directory
* [semantic-release-gerrit](https://github.com/pascalMN/semantic-release-gerrit)
* `generateNotes`: Generate release notes with Gerrit reviews URL
* [semantic-release-expo](https://github.com/bycedric/semantic-release-expo)
* `verifyConditions`: Verify Expo manifest(s) are readable and valid.
* `prepare`: Update version, ios build number and android version code in the Expo manifest(s).
* [maven-semantic-release](https://github.com/conveyal/maven-semantic-release)
* `verifyConditions`: Verifies that the `pom.xml` file and other files exist and are setup to allow releases
* `verifyRelease`: Checks and warns (does not error by default) if the version numbers found on maven central and within the Git project differ by quite a bit
* `prepare`: Changes the version number in the `pom.xml` (or all `pom.xml` files in maven projects with multiple `pom.xml` files) and optionally creates a commit with this version number and pushes it to `master`
* `publish`: Runs `mvn deploy` to deploy to maven central and optionally will update to next snapshot version and merge changes to development branch
* [maven-semantic-release](https://github.com/terrestris/maven-semantic-release) (alternative version)
* `verifyConditions`: Verifies that the `mvn` command exists.
* `prepare`: Changes version number in `pom.xml` and optionally in all child modules.
* `publish`: Runs one of the mvn targets `deploy`, `package jib:build` or `deploy jib:build`.
* `success`: Optionally sets new snapshot version and commits it.
* [semantic-release-ado](https://github.com/lluchmk/semantic-release-ado)
* `prepare`: Stores the version number as an Azure DevOps pipeline variable available to downstream steps on the job
* [gradle-semantic-release](https://github.com/KengoTODA/gradle-semantic-release-plugin)
* `verifyConditions`: Verify that project has a Gradle wrapper script, and `build.gradle` contains a task to publish artifacts.
* `prepare`: Changes the version number in the `gradle.properties`
* `publish`: Triggers Gradle to publish artifacts.
* [semantic-release-circleci-orb](https://github.com/matt-oakes/semantic-release-circleci-orb)
* `verifyConditions`: Verify the presence of the `CIRCLECI_API_TOKEN` environment variable, `orbName` option, and the `circleci` CLI.
* `publish`: Publish the CircleCI orb.
* [semantic-release-github-pages](https://github.com/qiwi/semantic-release-gh-pages-plugin)
* `verifyConditions`: Verify the presence of the auth token set via environment variables.
* `publish`: Pushes commit to the documentation branch.
* [semantic-release-github-pullrequest](https://github.com/asbiin/semantic-release-github-pullrequest)
* `verifyConditions`: Verify the presence and the validity of the GitHub authentication and other configuration.
* `publish`: Create a branch to upload all assets and create the pull request on the base branch on GitHub.
* [leiningen-semantic-release](https://github.com/NoxHarmonium/leiningen-semantic-release)
* `verifyConditions`: Checks the project.clj is syntactically valid.
* `prepare`: Update the project.clj version and package the output jar file.
* `publish`: Publish the jar (and generated Maven metadata) to a maven repository (or clojars).
* [@saithodev/semantic-release-gitea](https://github.com/saitho/semantic-release-gitea)
* `verifyConditions`: Verify the presence and the validity of the authentication and the assets option configuration.
* `publish`: Publish a Gitea release, optionally uploading file assets.
* `addChannel`: Update a Gitea release's pre-release field.
* [semantic-release-replace-plugin](https://github.com/jpoehnelt/semantic-release-replace-plugin)
* `prepare`: Replace version strings in files using regex and glob.
* [semantic-release-rubygem](https://github.com/Gusto/semantic-release-rubygem)
* `verifyConditions`: Locate and validate a `.gemspec` file, locate and validate a `lib/**/version.rb` file, verify the presence of the `GEM_HOST_API_KEY` environment variable, and create a credentials file with the API key.
* `prepare`: Update the version in the `lib/**/version.rb` version file and [build](https://guides.rubygems.org/command-reference/#gem-build) the gem.
* `publish`: [Push the Ruby gem](https://guides.rubygems.org/command-reference/#gem-push) to the gem server.
* [semantic-release-npm-deprecate-old-versions](https://github.com/ghusse/semantic-release-npm-deprecate-old-versions)
* `verifyConditions`: Validates configuration.
* `publish`: Deprecates old versions, based on the declaration of supported versions in the config.
* [amanda-mitchell/semantic-release-npm-multiple](https://github.com/amanda-mitchell/semantic-release-npm-multiple)
* **Note**: this is a thin wrapper around the built-in npm plugin that can target multiple registries
* `verifyConditions`: Verify the presence and the validity of the npm authentication and release configuration for multiple registries
* `prepare`: Update the package.json version and create the npm package tarball
* `publish`: Publish the package on the npm registry for multiple registries
* [semantic-release-license](https://github.com/cbhq/semantic-release-license) Automatically update dates and more in your license file for new releases.
* `verifyConditions`: Verify the presence of a license file
* `prepare`: Update the license file based on its type
* [semantic-release-pypi](https://github.com/abichinger/semantic-release-pypi)
* `verifyConditions`: Verify the environment variable `PYPI_TOKEN` and installation of build tools
* `prepare`: Update the version in `setup.cfg` and create the distribution packages
* `publish`: Publish the python package to a repository (default: pypi)
* [@covage/semantic-release-poetry-plugin](https://github.com/covage/semantic-release-poetry-plugin)
* `verifyConditions`: Verify the presence and validity of `pyproject.toml` file.
* `prepare`: Update the version in `pyproject.toml`.
* [semantic-release-codeartifact](https://github.com/ryansonshine/semantic-release-codeartifact)
* `verifyConditions`: Validate configuration, get AWS CodeArtifact authentication and repository, validate `publishConfig` or `.npmrc` (if they exist), then pass the configuration to the associated plugins.
* [semantic-release-telegram](https://github.com/pustovitDmytro/semantic-release-telegram)
* `verifyConditions`: Validate configuration and verify `TELEGRAM_BOT_ID` and `TELEGRAM_BOT_TOKEN`
* `success`: Publish a message about the successful release to a telegram chat
* `fail`: publish a message about failure to a telegram chat
* [semantic-release-heroku](https://github.com/pustovitDmytro/semantic-release-heroku)
* `verifyConditions`: Validate configuration and verify `HEROKU_API_KEY`
* `prepare`: Update the package.json version and create release tarball
* `publish`: Publish version to heroku
* [semantic-release-mattermost](https://github.com/ttrobisch/semantic-release-mattermost)
* `verifyConditions`: Verify that the webhook is setup and release-notes-generator is present.
* `success`: Send a message about the new release and its notes to a [mattermost](https://mattermost.com/) webhook.
* [semantic-release-github-milestones](https://github.com/nitzano/semantic-release-github-milestones)
* `verifyConditions`: Verify github tokens are present and valid.
* `verifyRelease`: Display information regarding the matching github milestone.
* [semantic-release-telegram-bot](https://github.com/skoropadas/semantic-release-telegram-bot)
* `verifyConditions`: Validate configuration and verify `TELEGRAM_BOT_TOKEN` and package name
* `success`: Publish a success message to certain telegram chats
* `fail`: Publish a fail message to certain telegram chats
* [semantic-release-npm-deprecate](https://github.com/jpoehnelt/semantic-release-npm-deprecate)
* `publish`: Automatically mark old versions as deprecated.
* [semantic-release-mirror-version](https://github.com/GarthDB/semantic-release-mirror-version)
* `prepare`: Update the version number in any file that matches the defined [file glob](https://github.com/isaacs/node-glob).
* [semantic-release-space](https://github.com/123FLO321/semantic-release-space)
* `verifyConditions` Verifies that all required options are set.
* `prepare` Creates a JetBrains Space Deployment Target if it does not yet exist.
* `publish` Starts a JetBrains Space Deployment.
* `success` Marks the JetBrains Space Deployment as completed.
* `fail` Marks the JetBrains Space Deployment as failed.
* [semantic-release-react-native](https://github.com/alexandermendes/semantic-release-react-native)
* `verifyConditions` Validate configuration.
* `prepare` Version native iOS and Android files.
* [semantic-release-cargo](https://github.com/buehler/semantic-release-cargo)
* `verifyConditions` Validate configuration, `Cargo.toml`, and local cargo executable. Also, logs in into `crates.io`.
* `prepare` Write the new version number into `Cargo.toml` file and perform `cargo check` if configured.
* `publish` Publish the Rust crate to `crates.io`
* [semantic-release-coralogix](https://github.com/adobe/semantic-release-coralogix)
* `verifyConditions` Verified that required credentials are provided and API is accessible
* `publish` add a release tag to Coralogix
* [semantic-release-jira-notes](https://github.com/iamludal/semantic-release-jira-notes)
* `verifyConditions`: Validate the config options.
* `generateNotes`: Generate the release notes with links to JIRA issues.
* [semantic-release-major-tag](https://github.com/doteric/semantic-release-major-tag)
* `success` Create major version tag, for example `v1`.
* [semantic-release-yarn](https://github.com/hongaar/semantic-release-yarn)
* **Note**: this is an alternative to the default `@semantic-release/npm` plugin and adds support for monorepos.
* `verifyConditions` Verify Yarn 2 or higher is installed, verify the presence of a NPM auth token (either in an environment variable or a `.yarnrc.yml` file) and verify the authentication method is valid.
* `prepare` Update the `package.json` version and create the package tarball.
* `addChannel` Add a tag for the release.
* `publish` Publish to the npm registry.
* [semantic-release-pub](https://github.com/zeshuaro/semantic-release-pub)
* `verifyConditions`: Verify the presence of the `pub.dev` authentication and release configuration
* `prepare`: Update the `pubspec.yaml` version
* `publish`: Publish the package onto the `pub.dev` registry
* [semantic-release-hackage](https://github.com/stackbuilders/semantic-release-hackage)
* `verifyConditions`: Verify the environment variable `HACKAGE_TOKEN`
* `prepare`: Update the version of .cabal file and create the distribution package (.tar)
* `publish`: Publish the release candidate to the specified repository in Hackage
* [semantic-release-pull-request-analyzer](https://github.com/bobvanderlinden/semantic-release-pull-request-analyzer)
* `verifyConditions` Verify configuration options and existance of GitHub token.
* `analyzeCommits` Determine the type of release by analyzing merged GitHub pull requests and their labels.
* `generateNotes` Generates release notes using [GitHub release notes generator](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes).
* [semantic-release-commits-lint](https://github.com/BondarenkoAlex/semantic-release-commits-lint)
* `analyzeCommits` Analyzing commit messages by [commitlint](https://github.com/conventional-changelog/commitlint).
* [semantic-release-kaniko](https://github.com/brendangeck/semantic-release-kaniko)
* `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry.
* `publish`: Build a container image using [Kaniko](https://github.com/GoogleContainerTools/kaniko) and (optionally) push it to a Docker registry.
* [semantic-release-skopeo](https://github.com/LukasWestholt/semantic-release-skopeo)
* `verifyConditions`: Verify that all needed configuration is present and check if destination is writeable (unless force=true).
* `publish`: Copy OCI images to a custom (Docker) registry using daemonless open-source tool [skopeo](https://github.com/containers/skopeo/).
* [sr-uv-plugin](https://github.com/Artessan-Devs/sr-uv-plugin)
* `verifyConditions`: Ensures `pyproject.toml` exists and contains a `[project]` section.
* `prepare`: Updates the `[project].version` field in `pyproject.toml` to match the release version.
* [semantic-release-uv](https://github.com/Deltamir/semantic-release-uv)
* `verifyConditions`: Verify the presence and validity of a `PYPI_TOKEN` and validate the `pyproject.toml` structure
* `prepare`: Update the version in `pyproject.toml`, locking and build the distribution with `uv`
* `publish`: Publish the package to PyPI or a custom index using `uv publish`
* [@jno21/semantic-release-github-commit](https://github.com/Jno21/semantic-release-github-commit)
* **Notes**: This plugin creates a commit on GitHub using the GitHub API, enabling signed commits via a GitHub App.
* `verifyConditions`: Verify GitHub authentication and configuration.
* `prepare`: Create a commit with the specified files using the GitHub API.
* [semantic-release-minecraft](https://github.com/pynickle/semantic-release)
* `verifyConditions`: Verify that all needed configuration is present.
* `prepare`: Convert different types of CurseForge game versions to their corresponding IDs.
* `publish`: Publish the Minecraft project to CurseForge and Modrinth.
# Shareable configuration
## Official configurations
* [@semantic-release/apm-config](https://github.com/semantic-release/apm-config) - semantic-release shareable configuration for releasing atom packages
* [@semantic-release/gitlab-config](https://github.com/semantic-release/gitlab-config) - semantic-release shareable configuration for GitLab
## Community configurations
* [@jedmao/semantic-release-npm-github-config](https://github.com/jedmao/semantic-release-npm-github-config)
* Provides an informative [Git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., `chore(release): 1.2.3 [skip ci]\n\nnotes`).
* Creates a tarball that gets uploaded with each [GitHub release](https://github.com/semantic-release/github).
* Publishes the same tarball to [npm](https://github.com/semantic-release/npm).
* Commits the version change in `package.json`.
* Creates or updates a [changelog](https://github.com/semantic-release/changelog) file.
* [semantic-release-npm-github-publish](https://github.com/oleg-koval/semantic-release-npm-github-publish)
* Based on [angular preset](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular).
* Adds more keywords for the `chore` **PATCH** release.
* Generates or updates a [changelog](https://github.com/semantic-release/changelog) file including all **PATCH** keywords (not included in default angular package).
* Updates GitHub release with release-notes.
* Bumps a version in package.json.
* Publishes the new version to [NPM](https://npmjs.org).
# CI configurations
* [CircleCI 2.0 workflows](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/circleci-workflows)
* [Travis CI](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/travis)
* [GitLab CI](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/gitlab-ci)
* [GitHub Actions](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/github-actions)
* [Jenkins CI](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/jenkins-ci)
# CircleCI 2.0
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured in [CircleCi Project Settings](https://circleci.com/docs/2.0/env-vars/#adding-environment-variables-in-the-app)..
Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](https://semantic-release.gitbook.io/semantic-release/usage/getting-started#getting-started).
## Multiple Node jobs configuration
### `.circleci/config.yml` configuration for multiple Node jobs
This example is a minimal configuration for **semantic-release** with tests running against Node 16 and 14. See [CircleCI documentation](https://circleci.com/docs/2.0) for additional configuration options.
In this example, the [`circleci/node`](https://circleci.com/developer/orbs/orb/circleci/node) orb is imported (Which makes some node operations easier), then a `release` job is defined which will run `semantic-release`.
To run our `release` job, we have created a workflow named `test_and_release` which will run two jobs, `node/test`, which comes from the node orb and will test our application, and our release job. Here, we are actually making use of [matrix jobs](https://circleci.com/blog/circleci-matrix-jobs/) so that our single `node/test` job will actually be executed twice, once for Node version 16, and once for version 14. Finally, we call our release job with a `requires` parameter so that `release` will run against the latest LTS version of node, only after `node/test` has successfully tested against v14 and v16.
```yaml
version: 2.1
orbs:
node: circleci/node@5.0.0
jobs:
release:
executor: node/default
steps:
- checkout
- node/install-packages # Install and automatically cache packages
# Run optional required steps before releasing
# - run: npm run build-script
- run: npx semantic-release
workflows:
test_and_release:
# Run the test jobs first, then the release only when all the test jobs are successful
jobs:
- node/test:
matrix:
parameters:
version:
- 16.1.0
- 14.17.0
- release:
requires:
- node/test
```
# Travis CI
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured in [Travis Repository Settings](https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-Settings) or with the [travis env set CLI](https://github.com/travis-ci/travis.rb#env).
Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](https://semantic-release.gitbook.io/semantic-release/usage/getting-started#getting-started).
## Node.js projects configuration
### `.travis.yml` configuration for multiple Node.js jobs
This example is a minimal configuration for **semantic-release** with a build running Node 14 and 16. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification.
**Note**: It's not recommended to run the `semantic-release` command in the Travis `script` step as each script in this step will be executed regardless of the outcome of the previous one. See [travis-ci/travis-ci#1066](https://github.com/travis-ci/travis-ci/issues/1066).
**Advanced configuration**: Running the tests in the `script` step of the `release` stage is not necessary as the previous stage(s) already ran them. To increase speed, the `script` step of the `release` stage can be overwritten to skip the tests. Note that other commands such as build or compilation might still be required.
```yaml
language: node_js
node_js:
- 14
- 16
jobs:
include:
# Define the release stage that runs semantic-release
- stage: release
node_js: lts/*
# Advanced: optionally overwrite your default `script` step to skip the tests
# script: skip
deploy:
provider: script
skip_cleanup: true
script:
- npx semantic-release
```
### `package.json` configuration for multiple Node jobs
A `package.json` is required only for [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation.
```json
{
"devDependencies": {
"semantic-release": "^18.0.0"
}
}
```
## Non-Node.js projects configuration
For projects that require to be tested with one or multiple version of a Non-JavaScript [language](https://docs.travis-ci.com/user/languages), optionally on multiple [Operating Systems](https://docs.travis-ci.com/user/multi-os).
This recipe cover the Travis specifics only. See [Non JavaScript projects recipe](https://semantic-release.gitbook.io/semantic-release/support/faq#can-i-use-semantic-release-to-publish-non-javascript-packages) for more information on the **semantic-release** configuration.
### `.travis.yml` configuration for non-JavaScript projects
This example is a minimal configuration for **semantic-release** with a build running [Go 1.6 and 1.7](https://docs.travis-ci.com/user/languages/go). See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification.
**Note**: It's not recommended to run the `semantic-release` command in the Travis `script` step as each script in this step will be executed regardless of the outcome of the previous one. See [travis-ci/travis-ci#1066](https://github.com/travis-ci/travis-ci/issues/1066).
**Advanced configuration**: Running the tests in the `script` step of the `release` stage is not necessary as the previous stage(s) already ran them. To increase speed, the `script` step of the `release` stage can be overwritten to skip the tests. Note that other commands such as build or compilation might still be required.
```yaml
language: go
go:
- 1.6
- 1.7
jobs:
include:
# Define the release stage that runs semantic-release
- stage: release
# Advanced: optionally overwrite your default `script` step to skip the tests
# script:
# - make
deploy:
provider: script
skip_cleanup: true
script:
# Use nvm to install and use the Node LTS version (nvm is installed on all Travis images)
- nvm install lts/*
- npx semantic-release
on:
all_branches: true
```
# GitLab CI
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured with [Protected variables](https://docs.gitlab.com/ce/ci/variables/README.html#protected-environment-variables).
**Note**: Make sure to configure your release branch as [protected](https://docs.gitlab.com/ce/user/project/protected_branches.html) in order for the CI/CD build to access the protected variables.
## npm provenance
Since GitLab CI is a [supported provider](https://docs.npmjs.com/generating-provenance-statements#provenance-limitations) for [npm provenance](https://docs.npmjs.com/generating-provenance-statements), it is recommended to enable this to increase supply-chain security for your npm packages. Find more detail about configuring npm to publish with provenance through semantic-release [in the documentation for our npm plugin](https://github.com/semantic-release/npm#npm-provenance).
## Node project configuration
GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) allowing to test on multiple Node versions and publishing a release only when all test pass.
**Note**: The publish pipeline must run a [Node version that meets our version requirement](https://semantic-release.gitbook.io/semantic-release/support/node-version).
### `.gitlab-ci.yml` configuration for Node projects
This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
**Note**: The`semantic-release` execution command varies depending on whether you are using a [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) or [global](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) **semantic-release** installation.
```yaml
# The release pipeline will run only if all jobs in the test pipeline are successful
stages:
- test
- release
before_script:
- npm install
node:10:
image: node:10
stage: test
script:
- npm test
node:12:
image: node:12
stage: test
script:
- npm test
publish:
image: node:12
stage: release
script:
- npx semantic-release
```
### `.gitlab-ci.yml` configuration for all projects
This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
**Note**: The`semantic-release` execution command varies depending if you are using a [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) or [global](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) **semantic-release** installation.
```yaml
# The release pipeline will run only on the master/main branch a commit is triggered
stages:
- release
release:
image: node:10-buster-slim
stage: release
before_script:
- apt-get update && apt-get install -y --no-install-recommends git-core ca-certificates
- npm install -g semantic-release @semantic-release/gitlab
script:
- semantic-release
rules:
- if: $CI_COMMIT_BRANCH == "master" # or main
release:
image: node:12-buster-slim
stage: release
before_script:
- apt-get update && apt-get install -y --no-install-recommends git-core ca-certificates
- npm install -g semantic-release @semantic-release/gitlab
script:
- semantic-release
rules:
- if: $CI_COMMIT_BRANCH == "master" # or main
```
### `package.json` configuration
A `package.json` is required only for [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation.
```json
{
"devDependencies": {
"semantic-release": "^15.0.0"
}
}
```
# GitHub Actions
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured with [Secret Variables](https://docs.github.com/en/actions/reference/encrypted-secrets).
In this example a publish type [`NPM_TOKEN`](https://docs.npmjs.com/creating-and-viewing-authentication-tokens) is required to publish a package to the npm registry. GitHub Actions [automatically populate](https://docs.github.com/en/actions/security-guides/automatic-token-authentication) a [`GITHUB_TOKEN`](https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line) environment variable which can be used in Workflows.
## Trusted publishing and npm provenance
For improved security and automation, it is recommended to leverage [trusted publishing](https://docs.npmjs.com/trusted-publishers) through [OpenID Connect (OIDC)](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) when publishing to npm from GitHub Actions. GitHub Actions is a [trusted identity provider](https://docs.npmjs.com/trusted-publishers#identity-providers) for npm, enabling configuration of a trust relationship between your GitHub repository and npm so that no long-lived secret (like an `NPM_TOKEN`) is required to publish packages to npm from GitHub Actions. The npm registry [recently increased restrictions for use of long-lived access tokens](https://github.blog/changelog/2025-09-29-strengthening-npm-security-important-changes-to-authentication-and-token-management/), further encouraging trusted publishing as the preferred approach for publishing to npm from GitHub Actions. Enabling trusted publishing requires granting the `id-token: write` permission to the job performing the publish step and [configuring a trust relationship](https://docs.npmjs.com/trusted-publishers#step-1-add-a-trusted-publisher-on-npmjscom) between your GitHub repository and npm.
**Note**: When setting up a Trusted Publisher on npmjs for GitHub Actions, it's crucial to specify the workflow file that triggers the release process, not necessarily the one that contains the release logic itself.\
If your release job is encapsulated in a [reusable workflow](https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows), the workflow file you must reference is the caller workflowâtypically the one triggered by events like `push` or `workflow_dispatch` on your main branch.\
This is because npm's Trusted Publisher mechanism authorizes the workflow that initiates the run, not any downstream workflows it invokes.
[npm provenance](https://docs.npmjs.com/generating-provenance-statements) is valuable for increasing supply-chain security for your npm packages. Before trusted publishing was available, generating provenance attestations required configuring your project to enable publishing with provenance. With trusted publishing, npm provenance is automatically generated for packages published to npm from GitHub Actions without any additional configuration.
## Important: Avoid `registry-url` in `setup-node`
**Do not** set the `registry-url` option in the `actions/setup-node` step when using semantic-release for npm publishing. The `registry-url` option causes `setup-node` to create an `.npmrc` file that can conflict with semantic-release's npm authentication mechanism, leading to `EINVALIDNPMTOKEN` errors even when your token is valid.
```yaml
# â Don't do this - can cause conflicts with semantic-release
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: "lts/*"
registry-url: "https://registry.npmjs.org"
# â
Do this instead - let semantic-release handle npm authentication
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: "lts/*"
```
If you need to specify a custom registry, configure it in your project's `.npmrc` file instead. This ensures consistent behavior between local development and CI environments, and avoids conflicts with semantic-release.
## Node project configuration
[GitHub Actions](https://github.com/features/actions) support [Workflows](https://help.github.com/en/articles/configuring-workflows), allowing to run tests on multiple Node versions and publish a release only when all test pass.
**Note**: The publish pipeline must run on a [Node version that meets our version requirement](https://semantic-release.gitbook.io/semantic-release/support/node-version).
### `.github/workflows/release.yml` configuration for Node projects
The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on the latest LTS version of Node when a new commit is pushed to a `master/main` branch. See the [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions) for additional configuration options.
```yaml
name: Release
on:
push:
branches:
- master # or main
permissions:
contents: read # for checkout
jobs:
release:
name: Release
runs-on: ubuntu-latest
permissions:
contents: write # to be able to publish a GitHub release
issues: write # to be able to comment on released issues
pull-requests: write # to be able to comment on released pull requests
id-token: write # to enable use of OIDC for trusted publishing and npm provenance
steps:
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: "lts/*"
- name: Install dependencies
run: npm clean-install
- name: Verify the integrity of provenance attestations and registry signatures for installed dependencies
run: npm audit signatures
- name: Release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: npx semantic-release
```
## Pushing `package.json` changes to your repository
If you choose to commit changes to your `package.json` [against our recommendation](https://semantic-release.gitbook.io/semantic-release/support/faq#making-commits-during-the-release-process-adds-significant-complexity), the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin can be used.
**Note**: Automatically populated `GITHUB_TOKEN` cannot be used if branch protection is enabled for the target branch. It is **not** advised to mitigate this limitation by overriding an automatically populated `GITHUB_TOKEN` variable with a [Personal Access Tokens](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line), as it poses a security risk. Since Secret Variables are available for Workflows triggered by any branch, it becomes a potential vector of attack, where a Workflow triggered from a non-protected branch can expose and use a token with elevated permissions, yielding branch protection insignificant. One can use Personal Access Tokens in trusted environments, where all developers should have the ability to perform administrative actions in the given repository and branch protection is enabled solely for convenience purposes, to remind about required reviews or CI checks.
If the risk is acceptable, some extra configuration is needed. The [actions/checkout `persist-credentials`](https://github.com/marketplace/actions/checkout#usage) option needs to be `false`, otherwise the generated `GITHUB_TOKEN` will interfere with the custom one. Example:
```yaml
- name: Checkout
uses: actions/checkout@v2
with:
fetch-depth: 0
persist-credentials: false # <--- this
```
## Trigger semantic-release on demand
### Using GUI:
You can use [Manual Triggers](https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/) for GitHub Actions.
### Using HTTP:
Use [`repository_dispatch`](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#repository_dispatch) event to have control on when to generate a release by making an HTTP request, e.g.:
```yaml
name: Release
on:
repository_dispatch:
types: [semantic-release]
jobs:
# ...
```
To trigger a release, call (with a [Personal Access Tokens](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line) stored in `GITHUB_TOKEN` environment variable):
```
$ curl -v -H "Accept: application/vnd.github.everest-preview+json" -H "Authorization: token ${GITHUB_TOKEN}" https://api.github.com/repos/[org-name-or-username]/[repository]/dispatches -d '{ "event_type": "semantic-release" }'
```
# Jenkins CI
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured in [Jenkins Project Settings](https://www.jenkins.io/doc/pipeline/tour/environment/)..
Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](https://semantic-release.gitbook.io/semantic-release/usage/getting-started#getting-started).
## Node.js project configuration
### `Jenkinsfile (Declarative Pipeline)` configuration for a Node.js job
**Note**: The publish pipeline must run a Node version that [meets our requirement](https://semantic-release.gitbook.io/semantic-release/support/node-version).
This example is a minimal configuration for **semantic-release** with a build running a version of Node labelled as "node LTS". Since versions of Node are manually downloaded and labelled, we recommend keeping the version used for the release steps up-to-date with the latest LTS version. See the [Jenkins documentation](https://www.jenkins.io/doc/) for additional configuration options.
```yaml
// The release stage in the pipeline will run only if the test stage in the pipeline is successful
pipeline {
agent any
environment {
GH_TOKEN = credentials('some-id')
}
stages {
stage('Test') {
steps {
sh '''
# Configure your test steps here (checkout, npm install, tests etc)
npm install
npm test
'''
}
}
stage('Release') {
tools {
nodejs "node LTS"
}
steps {
sh '''
# Run optional required steps before releasing
npx semantic-release
'''
}
}
}
}
```
### `package.json` configuration for a Node job
A `package.json` is required only for [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation.
```json
{
"devDependencies": {
"semantic-release": "^18.0.0"
}
}
```
# Git hosted services
* [Git authentication with SSH keys](https://semantic-release.gitbook.io/semantic-release/recipes/git-hosted-services/git-auth-ssh-keys)
# Git authentication with SSH keys
When using [environment variables](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) to set up the Git authentication, the remote Git repository will automatically be accessed via [https](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_http_protocols), independently of the [`repositoryUrl`](https://semantic-release.gitbook.io/semantic-release/usage/configuration#repositoryurl) format configured in the **semantic-release** [Configuration](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration) (the format will be automatically converted as needed).
Alternatively the Git repository can be accessed via [SSH](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_ssh_protocol) by creating SSH keys, adding the public one to your Git hosted account and making the private one available on the CI environment.
**Note:** SSH keys allow to push the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) associated to the released version. Some plugins might also require an API token. See each plugin documentation for additional information.
## Generating the SSH keys
In your local repository root:
```bash
$ ssh-keygen -t rsa -b 4096 -C "" -f git_deploy_key -N ""
```
`your_email` must be the email associated with your Git hosted account. `ssh_passphrase` must be a long and hard to guess string. It will be used later.
This will generate a public key in `git_deploy_key.pub` and a private key in `git_deploy_key`.
## Adding the SSH public key to the Git hosted account
Step by step instructions are provided for the following Git hosted services:
* [GitHub](#adding-the-ssh-public-key-to-github)
### Adding the SSH public key to GitHub
Open the `git_deploy_key.pub` file (public key) and copy the entire content.
In GitHub **Settings**, click on **SSH and GPG keys** in the sidebar, then on the **New SSH Key** button.
Paste the entire content of `git_deploy_key.pub` file (public key) and click the **Add SSH Key** button.
Delete the `git_deploy_key.pub` file:
```bash
$ rm git_deploy_key.pub
```
See [Adding a new SSH key to your GitHub account](https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account/) for more details.
## Adding the SSH private key to the CI environment
In order to be available on the CI environment, the SSH private key must be encrypted, committed to the Git repository and decrypted by the CI service.
Step by step instructions are provided for the following environments:
* [Travis CI](#adding-the-ssh-private-key-to-travis-ci)
* [Circle CI](#adding-the-ssh-private-key-to-circle-ci)
### Adding the SSH private key to Travis CI
Install the [Travis CLI](https://github.com/travis-ci/travis.rb#installation):
```bash
$ gem install travis
```
[Login](https://github.com/travis-ci/travis.rb#login) to Travis with the CLI:
```bash
$ travis login
```
Add the [environment](https://github.com/travis-ci/travis.rb#env) variable `SSH_PASSPHRASE` to Travis with the value set during the [SSH keys generation](#generating-the-ssh-keys) step:
```bash
$ travis env set SSH_PASSPHRASE
```
[Encrypt](https://github.com/travis-ci/travis.rb#encrypt) the `git_deploy_key` (private key) using a symmetric encryption (AES-256), and store the secret in a secure environment variable in the Travis environment:
```bash
$ travis encrypt-file git_deploy_key
```
The `travis encrypt-file` will encrypt the private key into the `git_deploy_key.enc` file and output in the console the command to add to your `.travis.yml` file. It should look like `openssl aes-256-cbc -K $encrypted_KKKKKKKKKKKK_key -iv $encrypted_VVVVVVVVVVVV_iv -in git_deploy_key.enc -out git_deploy_key -d`.
Copy this command to your `.travis.yml` file in the `before_install` step. Change the output path to write the unencrypted key in `/tmp`: `-out git_deploy_key` => `/tmp/git_deploy_key`. This will avoid to commit / modify / delete the unencrypted key by mistake on the CI. Then add the commands to decrypt the ssh private key and make it available to `git`:
```yaml
before_install:
# Decrypt the git_deploy_key.enc key into /tmp/git_deploy_key
- openssl aes-256-cbc -K $encrypted_KKKKKKKKKKKK_key -iv $encrypted_VVVVVVVVVVVV_iv -in git_deploy_key.enc -out /tmp/git_deploy_key -d
# Make sure only the current user can read the private key
- chmod 600 /tmp/git_deploy_key
# Create a script to return the passphrase environment variable to ssh-add
- echo 'echo ${SSH_PASSPHRASE}' > /tmp/askpass && chmod +x /tmp/askpass
# Start the authentication agent
- eval "$(ssh-agent -s)"
# Add the key to the authentication agent
- DISPLAY=":0.0" SSH_ASKPASS="/tmp/askpass" setsid ssh-add /tmp/git_deploy_key /tmp/askpass && chmod +x /tmp/askpass
# Start the authentication agent
- eval "$(ssh-agent -s)"
# Add the key to the authentication agent
- DISPLAY=":0.0" SSH_ASKPASS="/tmp/askpass" setsid ssh-add /tmp/git_deploy_key v1.0.0 on @latest
```
## Releasing a bug fix
We can now continue to commit changes and release updates to our users. For example we can commit a bug fix with the message `fix: a fix` to `master` or `main`. When pushing that commit, **semantic-release** will release the version `1.0.1` on the dist-tag `@latest`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
* fix: a fix # => v1.0.1 on @latest
```
## Releasing a feature on next
We now want to develop an important feature, which is a breaking change. Considering the scope of this feature we want to make it available, at first, only to our most dedicated users in order to get feedback. Once we get that feedback we can make improvements and ultimately make the new feature available to all users.
To implement that workflow we can create the branch `next` and commit our feature to this branch. When pushing that commit, **semantic-release** will release the version `2.0.0` on the dist-tag `@next`. That means only the users installing our module with `npm install example-module@next` will receive the version `2.0.0`. Other users installing with `npm install example-module` will still receive the version `1.0.1`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
* fix: a fix # => v1.0.1 on @latest
| \
| * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
```
## Releasing a bug fix on next
One of our users starts to use the new `2.0.0` release and reports a bug. We develop a bug fix and commit it to the `next` branch with the message `fix: fix something on the big feature`. When pushing that commit, **semantic-release** will release the version `2.0.1` on the dist-tag `@next`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
* fix: a fix # => v1.0.1 on @latest
| \
| * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
| * fix: fix something on the big feature # => v2.0.1 on @next
```
## Releasing a feature on latest
We now want to develop a smaller, non-breaking feature. Its scope is small enough that we don't need to have a phase of feedback and we can release it to all users right away.
If we were to commit that feature on `next` only a subset of users would get it, and we would need to wait for the end of our feedback period in order to make both the big and the small feature available to all users.
Instead, we develop that small feature commit it to `master` or `main` with the message `feat: a small feature`. When pushing that commit, **semantic-release** will release the version `1.1.0` on the dist-tag `@latest` so all users can benefit from it right away.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
* fix: a fix # => v1.0.1 on @latest
| \
| * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
| * fix: fix something on the big feature # => v2.0.1 on @next
* | feat: a small feature # => v1.1.0 on @latest
```
## Porting a feature to next
Most of our users now have access to the small feature, but we still need to make it available to our users using the `@next` dist-tag. To do so we need to merge our changes made on `master` or `main` (the commit `feat: a small feature`) into `next`. As `master`/`main` and `next` branches have diverged, this merge might require to resolve conflicts.
Once the conflicts are resolved and the merge commit is pushed to `next`, **semantic-release** will release the version `2.1.0` on the dist-tag `@next` which contains both our small and big feature.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
* fix: a fix # => v1.0.1 on @latest
| \
| * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
| * fix: fix something on the big feature # => v2.0.1 on @next
* | feat: a small feature # => v1.1.0 on @latest
| * Merge branch master/main into next # => v2.1.0 on @next
```
## Adding a version to latest
After a period of feedback from our users using the `@next` dist-tag we feel confident to make our big feature available to all users. To do so we merge the `next` branch into `master`/`main`. There should be no conflict as `next` is strictly ahead of `master`/`main`.
Once the merge commit is pushed to `master`/`main`, **semantic-release** will add the version `2.1.0` to the dist-tag `@latest` so all users will receive it when installing out module with `npm install example-module`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
* fix: a fix # => v1.0.1 on @latest
| \
| * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
| * fix: fix something on the big feature # => v2.0.1 on @next
* | feat: a small feature # => v1.1.0 on @latest
| * Merge branch master/main into next # => v2.1.0 on @next
| /|
* | Merge branch next into master/main # => v2.1.0 on @latest
```
We can now continue to push new fixes and features on `master`/`main`, or a new breaking change on `next` as we did before.
# Publishing maintenance releases
This recipe will walk you through a simple example that uses Git branches and distribution channels to publish fixes and features for old versions of a package.
This example uses the **semantic-release** default configuration:
* [branches](https://semantic-release.gitbook.io/semantic-release/usage/configuration#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'main', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
* [plugins](https://semantic-release.gitbook.io/semantic-release/usage/configuration#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`
## Initial release
We'll start by making the first commit of the project, with the code for the initial release and the message `feat: initial commit`. When pushing that commit, on `master`/`main` **semantic-release** will release the version `1.0.0` and make it available on the default distribution channel which is the dist-tag `@latest` for npm.
The Git history of the repository is:
```
* feat: initial commit # => v1.0.0 on @latest
```
## Releasing a breaking change
We now decide to drop Node.js 6 support for our package, and require Node.js 8 or higher, which is a breaking change.
We commit that change with the message `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required` to `master`/`main`. When pushing that commit, **semantic-release** will release the version `2.0.0` on the dist-tag `@latest`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
* feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required # => v2.0.0 on @latest
```
## Releasing a feature for version 1.x users
One of our users request a new feature, however they cannot migrate to Node.js 8 or higher due to corporate policies.
If we were to push that feature on `master`/`main` and release it, the new version would require Node.js 8 or higher as the release would also contain the commit `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required`.
Instead, we create the branch `1.x` from the tag `v1.0.0` with the command `git checkout -b 1.x v1.0.0` and we commit that feature with the message `feat: a feature` to the branch `1.x`. When pushing that commit, **semantic-release** will release the version `1.1.0` on the dist-tag `@release-1.x` so users who can't migrate to Node.js 8 or higher can benefit from it.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
* | feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required # => v2.0.0 on @latest
| * feat: a feature # => v1.1.0 on @1.x
```
## Releasing a bug fix for version 1.0.x users
Another user currently using version `1.0.0` reports a bug. They cannot migrate to Node.js 8 or higher and they also cannot migrate to `1.1.0` as they do not use the feature developed in `feat: a feature` and their corporate policies require to go through a costly quality assurance process for each `minor` upgrades.
In order to deliver the bug fix in a `patch` release, we create the branch `1.0.x` from the tag `v1.0.0` with the command `git checkout -b 1.0.x v1.0.0` and we commit that fix with the message `fix: a fix` to the branch `1.0.x`. When pushing that commit, **semantic-release** will release the version `1.0.1` on the dist-tag `@release-1.0.x` so users who can't migrate to `1.1.x` or `2.x` can benefit from it.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
* | feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required # => v2.0.0 on @latest
| | \
| * | feat: a feature # => v1.1.0 on @1.x
| | * fix: a fix # => v1.0.1 on @1.0.x
```
## Porting a bug fix from 1.0.x to 1.x
Now that we have released a fix in version `1.0.1` we want to make it available to `1.1.x` users as well.
To do so we need to merge the changes made on `1.0.x` (the commit `fix: a fix`) into the `1.x` branch. As `1.0.x` and `1.x` branches have diverged, this merge might require to resolve conflicts.
Once the conflicts are resolved and the merge commit is pushed to the branch `1.x`, **semantic-release** will release the version `1.1.1` on the dist-tag `@release-1.x` which contains both our feature and bug fix.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
* | feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required # => v2.0.0 on @latest
| | \
| * | feat: a feature # => v1.1.0 on @1.x
| | * fix: a fix # => v1.0.1 on @1.0.x
| | /|
| * | Merge branch 1.0.x into 1.x # => v1.1.1 on @1.x
```
## Porting bug fixes and features to master/main
Finally we want to make both our feature and bug fix available to users using the `@latest` dist-tag.
To do so we need to merge the changes made on `1.x` (the commits `feat: a feature` and `fix: a fix`) into `master`/`main`. As `1.x` and `master`/`main` branches have diverged, this merge might require to resolve conflicts.
Once the conflicts are resolved and the merge commit is pushed to `master` or `main`, **semantic-release** will release the version `2.1.0` on the dist-tag `@latest` which now contains the breaking change feature, the feature and the bug fix.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
* | feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required # => v2.0.0 on @latest
| | \
| * | feat: a feature # => v1.1.0 on @1.x
| | * fix: a fix # => v1.0.1 on @1.0.x
| | /|
| * | Merge branch 1.0.x into 1.x # => v1.1.1 on @1.x
| /| |
* | | Merge branch 1.x into master/main # => v2.1.0 on @latest
```
## Releasing a bug fix for version 2.1.0 users
One of our users using the version `2.1.0` version reports a bug.
We can simply commit the bug fix with the message `fix: another fix` to `master`/`main`. When pushing that commit, **semantic-release** will release the version `2.1.1` on the dist-tag `@latest`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
* | feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required # => v2.0.0 on @latest
| | \
| * | feat: a feature # => v1.1.0 on @1.x
| | * fix: a fix # => v1.0.1 on @1.0.x
| | /|
| * | Merge branch 1.0.x into 1.x # => v1.1.1 on @1.x
| /| |
* | | Merge branch 1.x into master/main # => v2.1.0 on @latest
* | | fix: another fix # => v2.1.1 on @latest
```
## Porting a bug fix from master/main to 1.x
The bug fix `fix: another fix` also affects version `1.1.1` users, so we want to port it to the `1.x` branch.
To do so we need to cherry pick our fix commit made on `master`/`main` (`fix: another fix`) into `1.x` with `git checkout 1.x && git cherry-pick `. As `master`/`main` and `1.x` branches have diverged, the cherry picking might require to resolve conflicts.
Once the conflicts are resolved and the commit is pushed to `1.x`, **semantic-release** will release the version `1.1.2` on the dist-tag `@release-1.x` which contains `feat: a feature`, `fix: a fix` and `fix: another fix` but not `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
* | feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required # => v2.0.0 on @latest
| | \
| * | feat: a feature # => v1.1.0 on @1.x
| | * fix: a fix # => v1.0.1 on @1.0.x
| | /|
| * | Merge branch 1.0.x into 1.x # => v1.1.1 on @1.x
| /| |
* | | Merge branch 1.x into master/main # => v2.1.0 on @latest
* | | fix: another fix # => v2.1.1 on @latest
| | |
| * | fix: another fix # => v1.1.2 on @1.x
```
# Publishing pre-releases
This recipe will walk you through a simple example that uses pre-releases to publish beta versions while working on a future major release and then make only one release on the default distribution.
This example uses the **semantic-release** default configuration:
* [branches](https://semantic-release.gitbook.io/semantic-release/usage/configuration#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'main', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
* [plugins](https://semantic-release.gitbook.io/semantic-release/usage/configuration#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`
## Initial release
We'll start by making the first commit of the project, with the code for the initial release and the message `feat: initial commit`. When pushing that commit, on `master`/`main` **semantic-release** will release the version `1.0.0` and make it available on the default distribution channel which is the dist-tag `@latest` for npm.
The Git history of the repository is:
```
* feat: initial commit # => v1.0.0 on @latest
```
## Working on a future release
We now decide to work on a future major release, which will be composed of multiple features, some of them being breaking changes. We want to publish our package for each new feature developed for test purpose, however we do not want to increment our package version or make it available to our users until all the features are developed and tested.
To implement that workflow we can create the branch `beta` and commit our first feature there. When pushing that commit, **semantic-release** will publish the pre-release version `2.0.0-beta.1` on the dist-tag `@beta`. That allow us to run integration tests by installing our module with `npm install example-module@beta`. Other users installing with `npm install example-module` will still receive the version `1.0.0`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
| * feat: first feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0-beta.1 on @beta
```
We can continue to work on our future release by committing and pushing other features or bug fixes on the `beta` branch. With each push, **semantic-release** will publish a new pre-release on the dist-tag `@beta`, which allow us to run our integration tests.
With another feature, the Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
| * feat: first feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0-beta.1 on @beta
| * feat: second feature # => v2.0.0-beta.2 on @beta
```
## Releasing a bug fix on the default distribution channel
In the meantime we can also continue to commit changes and release updates to our users.
For example, we can commit a bug fix with the message `fix: a fix` to `master`/`main`. When pushing that commit, **semantic-release** will release the version `1.0.1` on the dist-tag `@latest`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
| * feat: first feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0-beta.1 on @beta
| * feat: second feature # => v2.0.0-beta.2 on @beta
* | fix: a fix # => v1.0.1 on @latest
```
## Working on another future release
We now decide to work on another future major release, in parallel of the beta one, which will also be composed of multiple features, some of them being breaking changes.
To implement that workflow we can create the branch `alpha` from the branch `beta` and commit our first feature there. When pushing that commit, **semantic-release** will publish the pre-release version `3.0.0-alpha.1` on the dist-tag `@alpha`. That allow us to run integration tests by installing our module with `npm install example-module@alpha`. Other users installing with `npm install example-module` will still receive the version `1.0.1`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
| * feat: first feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0-beta.1 on @beta
| * feat: second feature # => v2.0.0-beta.2 on @beta
* | fix: a fix # => v1.0.1 on @latest
| | \
| | * feat: first feature of other release \n\n BREAKING CHANGE: it breaks something # => v3.0.0-alpha.1 on @alpha
```
We can continue to work on our future release by committing and pushing other features or bug fixes on the `alpha` branch. With each push, **semantic-release** will publish a new pre-release on the dist-tag `@alpha`, which allow us to run our integration tests.
With another feature, the Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
| * feat: first feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0-beta.1 on @beta
| * feat: second feature # => v2.0.0-beta.2 on @beta
* | fix: a fix # => v1.0.1 on @latest
| | \
| | * feat: first feature of other release \n\n BREAKING CHANGE: it breaks something # => v3.0.0-alpha.1 on @alpha
| | * feat: second feature of other release # => v3.0.0-alpha.2 on @alpha
```
## Publishing the 2.0.0 beta release to the default distribution channel
Once we've developed and pushed all the feature we want to include in the future version `2.0.0` in the `beta` branch and all our tests are successful we can release it to our users.
To do so we need to merge our changes made on `beta` into `master`/`main`. As `beta` and `master`/`main` branches have diverged, this merge might require to resolve conflicts.
Once the conflicts are resolved and the merge commit is pushed to `master`/`main`, **semantic-release** will release the version `2.0.0` on the dist-tag `@latest`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
| * feat: first feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0-beta.1 on @beta
| * feat: second feature # => v2.0.0-beta.2 on @beta
* | fix: a fix # => v1.0.1 on @latest
| | \
| | * feat: first feature of other release \n\n BREAKING CHANGE: it breaks something # => v3.0.0-alpha.1 on @alpha
| | * feat: second feature of other release # => v3.0.0-alpha.2 on @alpha
| /| |
* | | Merge branch beta into master/main # => v2.0.0 on @latest
```
## Publishing the 3.0.0 alpha release to the beta distribution channel
Now that we published our the version `2.0.0` that was previously in beta, we decide to promote the version `3.0.0` in alpha to beta.
To do so we need to merge our changes made on `alpha` into `beta`. There should be no conflict as `alpha` is strictly ahead of `master`/`main`.
Once the merge commit is pushed to `beta`, **semantic-release** will publish the pre-release version `3.0.0-beta.1` on the dist-tag `@beta`, which allow us to run our integration tests.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
| * feat: first feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0-beta.1 on @beta
| * feat: second feature # => v2.0.0-beta.2 on @beta
* | fix: a fix # => v1.0.1 on @latest
| | \
| | * feat: first feature of other release \n\n BREAKING CHANGE: it breaks something # => v3.0.0-alpha.1 on @alpha
| | * feat: second feature of other release # => v3.0.0-alpha.2 on @alpha
| /| |
* | | Merge branch beta into master/main # => v2.0.0 on @latest
| | /|
| * | Merge branch alpha into beta # => v3.0.0-beta.1 on @beta
```
## Publishing the 3.0.0 beta release to the default distribution channel
Once we've developed and pushed all the feature we want to include in the future version `3.0.0` in the `beta` branch and all our tests are successful we can release it to our users.
To do so we need to merge our changes made on `beta` into `master`/`main`. As `beta` and `master` branches have diverged, this merge might require to resolve conflicts.
Once the conflicts are resolved and the merge commit is pushed to `master` or `main`, **semantic-release** will release the version `3.0.0` on the dist-tag `@latest`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
| * feat: first feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0-beta.1 on @beta
| * feat: second feature # => v2.0.0-beta.2 on @beta
* | fix: a fix # => v1.0.1 on @latest
| | \
| | * feat: first feature of other release \n\n BREAKING CHANGE: it breaks something # => v3.0.0-alpha.1 on @alpha
| | * feat: second feature of other release # => v3.0.0-alpha.2 on @alpha
| /| |
* | | Merge branch beta into master/main # => v2.0.0 on @latest
| | /|
| * | Merge branch alpha into beta # => v3.0.0-beta.1 on @beta
| /| |
* | | Merge branch beta into master/main # => v3.0.0 on @latest
```
## Working on a third future release
We can now start to work on a new future major release, version `4.0.0`, on the `@beta` distribution channel.
To do so we first need to update the `beta` branch with all the changes from `master` or `main` (the commits `fix: a fix`). As `beta` and `master`/`main` branches have diverged, this merge might require to resolve conflicts.
We can now commit our new feature on `beta`. When pushing that commit, **semantic-release** will publish the pre-release version `3.1.0-beta.1` on the dist-tag `@beta`. That allow us to run integration tests by installing our module with `npm install example-module@beta`. Other users installing with `npm install example-module` will still receive the version `3.0.0`.
The Git history of the repository is now:
```
* feat: initial commit # => v1.0.0 on @latest
| \
| * feat: first feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0-beta.1 on @beta
| * feat: second feature # => v2.0.0-beta.2 on @beta
* | fix: a fix # => v1.0.1 on @latest
| | \
| | * feat: first feature of other release \n\n BREAKING CHANGE: it breaks something # => v3.0.0-alpha.1 on @alpha
| | * feat: second feature of other release # => v3.0.0-alpha.2 on @alpha
| /| |
* | | Merge branch beta into master/main # => v2.0.0 on @latest
| | /|
| * | Merge branch alpha into beta # => v3.0.0-beta.1 on @beta
| /| |
* | | Merge branch beta into master/main # => v3.0.0 on @latest
| \| |
| * | Merge branch master/main into beta
| * | feat: new feature # => v3.1.0-beta.1 on @beta
```
# JavaScript API
## Usage
```js
const semanticRelease = require("semantic-release");
const { WritableStreamBuffer } = require("stream-buffers");
const stdoutBuffer = new WritableStreamBuffer();
const stderrBuffer = new WritableStreamBuffer();
try {
const result = await semanticRelease(
{
// Core options
branches: [
"+([0-9])?(.{+([0-9]),x}).x",
"master",
"main",
"next",
"next-major",
{ name: "beta", prerelease: true },
{ name: "alpha", prerelease: true },
],
repositoryUrl: "https://github.com/me/my-package.git",
// Shareable config
extends: "my-shareable-config",
// Plugin options
githubUrl: "https://my-ghe.com",
githubApiPathPrefix: "/api-prefix",
},
{
// Run semantic-release from `/path/to/git/repo/root` without having to change local process `cwd` with `process.chdir()`
cwd: "/path/to/git/repo/root",
// Pass the variable `MY_ENV_VAR` to semantic-release without having to modify the local `process.env`
env: { ...process.env, MY_ENV_VAR: "MY_ENV_VAR_VALUE" },
// Store stdout and stderr to use later instead of writing to `process.stdout` and `process.stderr`
stdout: stdoutBuffer,
stderr: stderrBuffer,
}
);
if (result) {
const { lastRelease, commits, nextRelease, releases } = result;
console.log(
`Published ${nextRelease.type} release version ${nextRelease.version} containing ${commits.length} commits.`
);
if (lastRelease.version) {
console.log(`The last release was "${lastRelease.version}".`);
}
for (const release of releases) {
console.log(`The release was published with plugin "${release.pluginName}".`);
}
} else {
console.log("No release published.");
}
// Get stdout and stderr content
const logs = stdoutBuffer.getContentsAsString("utf8");
const errors = stderrBuffer.getContentsAsString("utf8");
} catch (err) {
console.error("The automated release failed with %O", err);
}
```
## API
### semanticRelease(\[options], \[config]) => Promise
Run **semantic-release** and returns a `Promise` that resolves to a [Result](#result) object.
#### options
Type: `Object`
**semantic-release** options.
Can be used to set any [core option](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration) or [plugin options](https://semantic-release.gitbook.io/semantic-release/usage/plugins#configuration).
Each option, will take precedence over options configured in the [configuration file](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration) and [shareable configurations](https://semantic-release.gitbook.io/semantic-release/usage/configuration#extends).
#### config
Type: `Object`
**semantic-release** configuration specific for API usage.
**cwd**
Type: `String`\
Default: `process.cwd()`
The current working directory to use. It should be configured to the root of the Git repository to release from.
It allows to run **semantic-release** from a specific path without having to change the local process `cwd` with `process.chdir()`.
**env**
Type: `Object`\
Default: `process.env`
The environment variables to use.
It allows to run **semantic-release** with specific environment variables without having to modify the local `process.env`.
**stdout**
Type: [`stream.Writable`](https://nodejs.org/api/stream.html#stream_writable_streams)\
Default: `process.stdout`
The [writable stream](https://nodejs.org/api/stream.html#stream_writable_streams) used to log information.
It allows to configure **semantic-release** to write logs to a specific stream rather than the local `process.stdout`.
**stderr**
Type: [`stream.Writable`](https://nodejs.org/api/stream.html#stream_writable_streams)\
Default: `process.stderr`
The [writable stream](https://nodejs.org/api/stream.html#stream_writable_streams) used to log errors.
It allows to configure **semantic-release** to write errors to a specific stream rather than the local `process.stderr`.
### Result
Type: `Object` `Boolean``
The list of commit(s) included in the new release.\
Each commit object has the following properties:
| Name | Type | Description |
| --------------- | -------- | ----------------------------------------------- |
| commit | `Object` | The commit abbreviated and full hash. |
| commit.long | `String` | The commit hash. |
| commit.short | `String` | The commit abbreviated hash. |
| tree | `Object` | The commit abbreviated and full tree hash. |
| tree.long | `String` | The commit tree hash. |
| tree.short | `String` | The commit abbreviated tree hash. |
| author | `Object` | The commit author information. |
| author.name | `String` | The commit author name. |
| author.email | `String` | The commit author email. |
| author.short | `String` | The commit author date. |
| committer | `Object` | The committer information. |
| committer.name | `String` | The committer name. |
| committer.email | `String` | The committer email. |
| committer.short | `String` | The committer date. |
| subject | `String` | The commit subject. |
| body | `String` | The commit body. |
| message | `String` | The commit full message (`subject` and `body`). |
| hash | `String` | The commit hash. |
| committerDate | `String` | The committer date. |
Example:
```js
[
{
commit: {
long: '68eb2c4d778050b0701136ca129f837d7ed494d2',
short: '68eb2c4'
},
tree: {
long: '7ab515d12bd2cf431745511ac4ee13fed15ab578',
short: '7ab515d'
},
author: {
name: 'Me',
email: 'me@email.com',
date: 2018-07-22T20:52:44.000Z
},
committer: {
name: 'Me',
email: 'me@email.com',
date: 2018-07-22T20:52:44.000Z
},
subject: 'feat: a new feature',
body: 'Description of the new feature',
hash: '68eb2c4d778050b0701136ca129f837d7ed494d2',
message: 'feat: a new feature\n\nDescription of the new feature',
committerDate: 2018-07-22T20:52:44.000Z
}
]
```
#### nextRelease
Type: `Object`
Information related to the newly published release:
| Name | Type | Description |
| ------- | -------- | ----------------------------------------------------------------------------------------------------------------------------- |
| type | `String` | The [semver](https://semver.org) type of the release (`patch`, `minor` or `major`). |
| version | `String` | The version of the new release. |
| gitHead | `String` | The sha of the last commit being part of the new release. |
| gitTag | `String` | The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) associated with the new release. |
| notes | `String` | The release notes for the new release. |
| channel | `String` | The distribution channel on which the next release will be made available (`undefined` for the default distribution channel). |
Example:
```js
{
type: 'minor',
gitHead: '68eb2c4d778050b0701136ca129f837d7ed494d2',
version: '1.1.0',
gitTag: 'v1.1.0',
notes: 'Release notes for version 1.1.0...',
channel : 'next'
}
```
#### releases
Type: `Array`
The list of releases published or made available to a distribution channel.\
Each release object has the following properties:
| Name | Type | Description |
| ---------- | -------- | -------------------------------------------------------------------------------------------------------------- |
| name | `String` | **Optional.** The release name, only if set by the corresponding `publish` plugin. |
| url | `String` | **Optional.** The release URL, only if set by the corresponding `publish` plugin. |
| type | `String` | The [semver](https://semver.org) type of the release (`patch`, `minor` or `major`). |
| version | `String` | The version of the release. |
| gitHead | `String` | The sha of the last commit being part of the release. |
| gitTag | `String` | The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) associated with the release. |
| notes | `String` | The release notes for the release. |
| pluginName | `String` | The name of the plugin that published the release. |
| channel | `String` | The distribution channel on which the release is available (`undefined` for the default distribution channel). |
Example:
```js
[
{
name: 'GitHub release',
url: 'https://github.com/me/my-package/releases/tag/v1.1.0',
type: 'minor',
gitHead: '68eb2c4d778050b0701136ca129f837d7ed494d2',
version: '1.1.0',
gitTag: 'v1.1.0',
notes: 'Release notes for version 1.1.0...',
pluginName: '@semantic-release/github'
channel: 'next'
},
{
name: 'npm package (@latest dist-tag)',
url: 'https://www.npmjs.com/package/my-package',
type: 'minor',
gitHead: '68eb2c4d778050b0701136ca129f837d7ed494d2',
version: '1.1.0',
gitTag: 'v1.1.0',
notes: 'Release notes for version 1.1.0...',
pluginName: '@semantic-release/npm'
channel: 'next'
}
]
```
# Plugin development
To create a plugin for `semantic-release`, you need to decide which parts of the release lifecycle are important to that plugin. For example, it is best to always have a `verifyConditions` step because you may be receiving inputs from a user and want to make sure they exist. A plugin can abide by any of the following lifecycles:
* `verifyConditions`
* `analyzeCommits`
* `verifyRelease`
* `generateNotes`
* `addChannel`
* `prepare`
* `publish`
* `success`
* `fail`
`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecycles stated above. For example, if your plugin only had a `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions.
In addition to the lifecycle methods, each lifecycle is passed two objects:
1. `pluginConfig` - an object containing the options that a user may pass in via their `release.config.js` file (or similar)
2. `context` - provided by `semantic-release` for access to things like `env` variables set on the running process.
For each lifecycle you create, you will want to ensure it can accept `pluginConfig` and `context` as parameters.
## Creating a Plugin Project
It is recommended that you generate a new project with `yarn init`. This will provide you with a basic node project to get started with. From there, create an `index.js` file, and make sure it is specified as the `main` in the `package.json`. We will use this file to orchestrate the lifecycle methods later on.
Next, create a `src` or `lib` folder in the root of the project. This is where we will store our logic and code for how our lifecycle methods work. Finally, create a `test` folder so you can write tests related to your logic.
We recommend you setup a linting system to ensure good javascript practices are enforced. ESLint is usually the system of choice, and the configuration can be whatever you or your team fancies.
## Exposing Lifecycle Methods
In your `index.js` file, you can start by writing the following code
```javascript
const verify = require("./src/verify");
let verified;
/**
* Called by semantic-release during the verification step
* @param {*} pluginConfig The semantic-release plugin config
* @param {*} context The context provided by semantic-release
*/
async function verifyConditions(pluginConfig, context) {
await verify(pluginConfig, context);
verified = true;
}
module.exports = { verifyConditions };
```
Then, in your `src` folder, create a file called `verify.js` and add the following
```javascript
const AggregateError = require("aggregate-error");
/**
* A method to verify that the user has given us a slack webhook url to post to
*/
module.exports = async (pluginConfig, context) => {
const { logger } = context;
const errors = [];
// Throw any errors we accumulated during the validation
if (errors.length > 0) {
throw new AggregateError(errors);
}
};
```
As of right now, this code won't do anything. However, if you were to run this plugin via `semantic-release`, it would run when the `verify` step occurred.
Following this structure, you can create different steps and checks to run through out the release process.
## Supporting Options
Let's say we want to verify that an `option` is passed. An `option` is a configuration object that is specific to your plugin. For example, the user may set an `option` in their release config like:
```js
{
prepare: {
path: "@semantic-release/my-special-plugin";
message: "My cool release message";
}
}
```
This `message` option will be passed to the `pluginConfig` object mentioned earlier. We can use the validation method we created to verify this option exists so we can perform logic based on that knowledge. In our `verify` file, we can add the following:
```js
const { message } = pluginConfig;
if (message.length) {
//...
}
```
## Context
### Common context keys
* `stdout`
* `stderr`
* `logger`
### Context object keys by lifecycle
#### verifyConditions
Initially the context object contains the following keys (`verifyConditions` lifecycle):
* `cwd`
* Current working directory
* `env`
* Environment variables
* `envCi`
* Information about CI environment
* Contains (at least) the following keys:
* `isCi`
* Boolean, true if the environment is a CI environment
* `commit`
* Commit hash
* `branch`
* Current branch
* `options`
* Options passed to `semantic-release` via CLI, configuration files etc.
* `branch`
* Information on the current branch
* Object keys:
* `channel`
* `tags`
* `type`
* `name`
* `range`
* `accept`
* `main`
* `branches`
* Information on branches
* List of branch objects (see above)
#### analyzeCommits
Compared to the verifyConditions, `analyzeCommits` lifecycle context has keys
* `commits` (List)
* List of commits taken into account when determining the new version.
* Keys:
* `commit` (Object)
* Keys:
* `long` (String, Commit hash)
* `short` (String, Commit hash)
* `tree` (Object)
* Keys:
* `long` (String, Commit hash)
* `short` (String, Commit hash)
* `author` (Object)
* Keys:
* `name` (String)
* `email` (String)
* `date` (String, ISO 8601 timestamp)
* `committer` (Object)
* Keys:
* `name` (String)
* `email` (String)
* `date` (String, ISO 8601 timestamp)
* `subject` (String, Commit message subject)
* `body` (String, Commit message body)
* `hash` (String, Commit hash)
* `committerDate` (String, ISO 8601 timestamp)
* `message` (String)
* `gitTags` (String, List of git tags)
* `releases` (List)
* `lastRelease` (Object)
* Keys
* `version` (String)
* `gitTag` (String)
* `channels` (List)
* `gitHead` (String, Commit hash)
* `name` (String)
#### verifyRelease
Additional keys:
* `nextRelease` (Object)
* `type` (String)
* `channel` (String)
* `gitHead` (String, Git hash)
* `version` (String, version without `v`)
* `gitTag` (String, version with `v`)
* `name` (String)
#### generateNotes
No new content in the context.
#### addChannel
*This is run only if there are releases that have been merged from a higher branch but not added on the channel of the current branch.*
Context content is similar to lifecycle `verifyRelease`.
#### prepare
Only change is that `generateNotes` has populated `nextRelease.notes`.
#### publish
No new content in the context.
#### success
Lifecycles `success` and `fail` are mutually exclusive, only one of them will be run.
Additional keys:
* `releases`
* Populated by `publish` lifecycle
#### fail
Lifecycles `success` and `fail` are mutually exclusive, only one of them will be run.
Additional keys:
* `errors`
### Supporting Environment Variables
Similar to `options`, environment variables exist to allow users to pass tokens and set special URLs. These are set on the `context` object instead of the `pluginConfig` object. Let's say we wanted to check for `GITHUB_TOKEN` in the environment because we want to post to GitHub on the user's behalf. To do this, we can add the following to our `verify` command:
```js
const { env } = context;
if (env.GITHUB_TOKEN) {
//...
}
```
## Logger
Use `context.logger` to provide debug logging in the plugin. Available logging functions: `log`, `warn`, `success`, `error`.
```js
const { logger } = context;
logger.log('Some message from plugin.').
```
The above usage yields the following where `PLUGIN_PACKAGE_NAME` is automatically inferred.
```
[3:24:04 PM] [semantic-release] [PLUGIN_PACKAGE_NAME] âș âč Some message from plugin.
```
## Execution order
For the lifecycles, the list at the top of the readme contains the order. If there are multiple plugins for the same lifecycle, then the order of the plugins determines the order in which they are executed.
## Handling errors
In order to be able to detect and handle errors properly, the errors thrown from the must be of type [SemanticReleaseError](https://github.com/semantic-release/error) or extend it as described in the package readme. This way the errors are handled properly and plugins using the `fail` lifecycle receive the errors correctly. For any other types of errors the internal error handling does nothing, lets them through up until the final catch and does not call any `fail` plugins.
## Advanced
Knowledge that might be useful for plugin developers.
### Multiple analyzeCommits plugins
While it may be trivial that multiple analyzeCommits (or any lifecycle plugins) can be defined, it is not that self-evident that the plugins executed AFTER the first one (for example, the default one: `commit-analyzer`) can change the result. This way it is possible to create more advanced rules or situations, e.g. if none of the commits would result in new release, then a default can be defined.
The commit must be a known release type, for example the commit-analyzer has the following default types:
* major
* premajor
* minor
* preminor
* patch
* prepatch
* prerelease
If the analyzeCommits-lifecycle plugin does not return anything, then the earlier result is used, but if it returns a supported string value, then that overrides the previous result.
# Shareable configuration development
# Resources
## Videos
* ["Introducing Reliable Dependency and Release Management for npm Packages" - Gregor Martynus](https://www.youtube.com/watch?v=R2RJWLcfzwc)
* ["Kill all humans" - Jan Lehnardt](https://www.youtube.com/watch?v=ZXyx_1kN1L8\&t=2s)
* ["Publishing JavaScript Packages" - JavaScript Air](https://javascriptair.com/episodes/2016-07-20)
* ["Managing Dependencies like a boss đ" - JavaScript Air](https://javascriptair.com/episodes/2016-08-17)
* ["Dependency Hell Just Froze Over" - Stephan Bönnemann](https://www.youtube.com/watch?v=PA139CERNbc)
* ["semantic-release Q\&A with Kent C. Dodds"](https://www.youtube.com/watch?v=g6y3DnhkjrI)
* ["We fail to follow SemVer â and why it neednât matter" - Stephan Bönnemann](https://www.youtube.com/watch?v=tc2UgG5L7WM)
## Articles
* ["Introduction to SemVer" - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2)
* ["Introduction to Semantic Release" - liv](https://blog.greenkeeper.io/introduction-to-semantic-release-33f73b117c8)
* ["Series - Semantic Release Automation" - Abdelrahman Wahdan](https://dev.to/abdelrahmanahmed/semantic-release-and-how-to-automate-it-part-1-4pa2)
* ["Explain semantic release and how to use it on GitLab pipeline"](https://regoo707.medium.com/auto-bump-apps-versions-and-releases-using-gitlab-pipeline-e32f1d7fa3ee)
## Tutorials
* ["How to Write a JavaScript Library - Automating Releases with semantic-release" â egghead.io](https://egghead.io/lessons/javascript-automating-releases-with-semantic-release)
# Frequently Asked Questions
## Why is the `package.json`âs version not updated in my repository?
### It is not needed for semantic-release to do its job
[`@semantic-release/npm`](https://github.com/semantic-release/npm) takes care of updating the `package.json`âs version before publishing to [npm](https://www.npmjs.com) based on the previous version that was tracked as a git tag. By default, only the published package will contain the version, which is the only place where it is *really* required, but the updated `package.json` will not be pushed to the Git repository. A git tag is added to track the new version, so committing the version is not necessary for semantic-release to pick up from there for the next release.
### It can lead to confusion
Some teams find value in being able to reference the repository to determine the current latest version available for the published package. Unfortunately, there are some failure scenarios where semantic-release might leave the committed version in the repository out of sync with the version that exists in the registry. The best way to determine available versions is to consult the registry that your package is published to, since it is the actual source of truth. The [npm CLI](https://docs.npmjs.com/cli/npm) can be used to consult the registry with the following command:
```shell
npm dist-tags ls
```
When not committing updates to the version, a value that follows the semver guidelines is still required for the `version` property within the `package.json`. To make it clear to contributors that the version is not kept up to date, we recommend using a value like `0.0.0-development` or `0.0.0-semantically-released`.
### Making commits during the release process adds significant complexity
While the [`@semantic-release/git`](https://github.com/semantic-release/git) enables committing such changes and pushing them back to the repository as part of a release, we strongly recommend against this practice.
Making commits and pushing them back to the repository adds significant additional complexity to your release process that can be avoided:
* Branch protection configuration must account for allowing the release user account to bypass restrictions enforced for human contributors, which might require elevating the access level of the release user beyond what would otherwise be desired/considered secure.
* Pre-commit hooks configured for a project, which is a popular practice when enabling [commitlint](https://commitlint.js.org/) through [husky](https://typicode.github.io/husky/), for example, must be accounted for in the release process. (We recommend disabling tools like this for automated commits, but you need to decide what is appropriate for your project)
### There are valid reasons to commit during a release
If you make your npm package available directly via a GitHub repository rather than publishing to a registry, for example, making a commit and pushing to the repository is a necessary step. In such a case you will want to use [`@semantic-release/git`](https://github.com/semantic-release/git) to coordinate the commit and push. You can set the project to `"private": true,` within your `package.json` to [prevent publishing to the registry](https://docs.npmjs.com/cli/v10/using-npm/registry#how-can-i-prevent-my-package-from-being-published-in-the-official-registry).
However, if you are choosing to follow this path because you can't use the official npm registry and don't want to manage your own registry, consider [publishing to GitHub packages](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry) instead.
## Should release notes be committed to a `CHANGELOG.md` in my repository during a release?
[`@semantic-release/changelog`](https://github.com/semantic-release/changelog) can be used to add release notes to a `CHANGELOG.md` file within your repository as part of each release. Committing changes to a `CHANGELOG.md` or similar file introduces the same [complexities](#making-commits-during-the-release-process-adds-significant-complexity) as committing an updated version within a `package.json` file. In addition, the release notes that would be added to a changelog file are likely redundant with the release notes added as GitHub releases, if that is also configured for your project (enabled by default).
Before deciding that a changelog file is necessary for your project, please consider whether the added complexity is worth it when GitHub releases (or similar for your host, if not GitHub) might accomplish the same goal. It could also be worth considering whether having a `CHANGELOG.md` in your repository that only contains a link to the project's GitHub releases could be an acceptable middle ground.
## How can I use a npm build script that requires the `package.json`âs version ?
The `package.json`âs version will be updated by the `semantic-release` command just before publishing to [npm](https://www.npmjs.com), therefore it won't be available for scripts ran before the `semantic-release` command.
As the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin uses the [npm CLI](https://docs.npmjs.com/cli/npm) to update the `package.json` version and publish the package, all [npm hook scripts](https://docs.npmjs.com/misc/scripts#description) will be executed.
You can run your build script in:
* the `prepublishOnly` or `prepack` hook so it will be executed during the `publish` step of `@semantic-release/npm`
* the `postversion` hook so it will be executed during the `prepare` step of `@semantic-release/npm`, which allow for example to update files before committing them with the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin
If using npm hook scripts is not possible, and alternative solution is to [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to run your script in the `prepare` step:
```json
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/npm",
[
"@semantic-release/exec",
{
"prepareCmd": "./my-build-script.sh ${nextRelease.version}"
}
]
]
}
```
## Is there a way to preview which version would currently get published?
Yes with the [dry-run options](https://semantic-release.gitbook.io/semantic-release/usage/configuration#dryrun) which prints to the console the next version to be published and the release notes.
## Can I use semantic-release to publish non-JavaScript packages?
Yes, **semantic-release** is a Node CLI application, but it can be used to publish any type of packages.
To publish a non-Node package (without a `package.json`) you would need to:
* Use a [global](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) **semantic-release** installation
* Set **semantic-release** [options](https://semantic-release.gitbook.io/semantic-release/usage/configuration#options) via [CLI arguments or `.rc` file](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration)
* Make sure your CI job executing the `semantic-release` command has access to a version of Node that [meets our version requirement](https://semantic-release.gitbook.io/semantic-release/support/node-version) to execute the `semantic-release` command
See the [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow#ci-configurations) for more details on specific CI environments.
In addition, you will need to configure the **semantic-release** [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins#plugins) to disable the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin which is used by default and use a plugin for your project type.
If there is no specific plugin for your project type you can use the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to publish the release with a shell command.
Here is a basic example to create [GitHub releases](https://help.github.com/articles/about-releases) and use a shell command to publish:
```json
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/github",
[
"@semantic-release/exec",
{
"prepareCmd": "set-version ${nextRelease.version}",
"publishCmd": "publish-package"
}
]
]
}
```
**Note**: This is a theoretical example where the command `set-version` update the project version with the value passed as its first argument and `publish-package` publishes the package to a registry.
See the [package managers and languages recipes](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow#package-managers-and-languages) for more details on specific project types and the [available plugins list](https://semantic-release.gitbook.io/semantic-release/extending/plugins-list) to see if there are community-supported plugins already available for the stack you are interested in.
## Can I use semantic-release with any CI service?
Yes, **semantic-release** can be used with any CI service, as long as it provides:
* A way to set [authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) via environment variables
* A way to guarantee that the `semantic-release` command is [executed only after all the tests of all the jobs in the CI build pass](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded)
See the [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow#ci-configurations) for more details on specific CI environments.
## Can I run semantic-release on my local machine rather than on a CI server?
Yes, you can by explicitly setting the [`--no-ci` CLI option](https://semantic-release.gitbook.io/semantic-release/usage/configuration#ci) option. You will also have to set the required [authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) via environment variables on your local machine, for example:
```bash
$ NPM_TOKEN= GH_TOKEN= npx semantic-release --no-ci
```
However this is not the recommended approach, as running unit and integration tests on an independent machine before publishing software is a crucial part of the release workflow.
## Can I use semantic-release with GitLab?
Yes, with the [`@semantic-release/gitlab-config`](https://github.com/semantic-release/gitlab-config) shareable configuration.
See the [GitLab CI recipes](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/gitlab-ci#using-semantic-release-with-gitlab-ci) for the CI configuration.
## Can I use semantic-release with any Git hosted environment?
By default **semantic-release** uses the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin to publish a [GitHub release](https://help.github.com/articles/about-releases). For other Git hosted environment the [`@semantic-release/git`](https://github.com/semantic-release/git) and [`@semantic-release/changelog`](https://github.com/semantic-release/changelog) plugins can be used via [plugins configuration](https://semantic-release.gitbook.io/semantic-release/usage/plugins).
See the [`@semantic-release/git`](https://github.com/semantic-release/git#semantic-releasegit) [`@semantic-release/changelog`](https://github.com/semantic-release/changelog#semantic-releasechangelog) plugins documentation for more details.
## Can I skip the release to the npm registry?
Yes, the publishing to the npm registry can be disabled with the [`npmPublish`](https://github.com/semantic-release/npm#options) option of the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. In addition the [`tarballDir`](https://github.com/semantic-release/npm#options) option allow to generate the package tarball in order to publish it to your repository with the [`@semantic-release/git`](https://github.com/semantic-release/git) or to a [GitHub release](https://help.github.com/articles/about-releases) with the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin.
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#semantic-releasenpm) plugin documentation for more details.
## How can I revert a release?
If you have introduced a breaking bug in a release you have 2 options:
* If you have a fix immediately ready, commit and push it (or merge it via a pull request) to the release branch
* Otherwise, [revert the commit](https://git-scm.com/docs/git-revert) that introduced the bug and push the revert commit (or merge it via a pull request) to the release branch
In both cases **semantic-release** will publish a new release, so your package users will get the fixed/reverted version.
Depending on the package manager you are using, you might be able to un-publish or deprecate a release, in order to prevent users from downloading it by accident. For example, npm allows you to [un-publish](https://docs.npmjs.com/cli/unpublish) [within 72 hours](https://www.npmjs.com/policies/unpublish) after release. You may also [deprecate](https://docs.npmjs.com/cli/deprecate) a release if you would rather avoid un-publishing.
In any case **do not remove the Git tag associated with the buggy version**, otherwise **semantic-release** will later try to republish that version. Publishing a version after un-publishing is not supported by most package managers.
**Note**: If you are using the default [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) be aware that it uses a different revert commit format than the standard one created by [git revert](https://git-scm.com/docs/git-revert), contrary to what is [claimed in the convention](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#revert). Therefore, if you revert a commit with [`git revert`](https://git-scm.com/docs/git-revert), use the [`--edit` option](https://git-scm.com/docs/git-revert#git-revert---edit) to format the message according to the [Angular revert commit message format](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#revert). See [conventional-changelog/conventional-changelog#348](https://github.com/conventional-changelog/conventional-changelog/issues/348) for more details.
## Can I use `.npmrc` options?
Yes, all the [npm configuration options](https://docs.npmjs.com/misc/config) are supported via the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository.
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
## How can I set the access level of the published npm package?
The [npm `access` option](https://docs.npmjs.com/misc/config#access) can be set in the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository:
```rc
access=public
```
Or with the `publishConfig.access` key in your project's `package.json`:
```json
{
"publishConfig": {
"access": "public"
}
}
```
## Can I manually trigger the release of a specific version?
You can trigger a release by pushing to your Git repository. You deliberately cannot trigger a *specific* version release, because this is the whole point of semantic-release.
## Can I exclude commits from the analysis?
Yes, every commits that contains `[skip release]` or `[release skip]` in their message will be excluded from the commit analysis and won't participate in the release type determination.
## How can I change the type of commits that trigger a release?
By default **semantic-release** uses the [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) and triggers releases based on the following rules:
| Commit | Release type |
| --------------------------- | -------------------------- |
| Commit with breaking change | ~~Major~~ Breaking release |
| Commit with type `feat` | ~~Minor~~ Feature release |
| Commit with type `fix` | Patch release |
| Commit with type `perf` | Patch release |
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
This is fully customizable with the [`@semantic-release/commit-analyzer`](https://github.com/semantic-release/commit-analyzer) plugin's [`release-rules` option](https://github.com/semantic-release/commit-analyzer#release-rules).
## Is it *really* a good idea to release on every push?
It is indeed a great idea because it *forces* you to follow best practices. If you donât feel comfortable releasing every feature or fix on your `master`/`main` you might not treat your `master`/`main` branch as intended.
From [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/index.html):
> Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master/main branch is always deployable.
If you need more control over the timing of releases, see [Triggering a release](https://semantic-release.gitbook.io/semantic-release/readme#triggering-a-release) for different options.
**Note**: Only the codebase changes altering the published package will trigger a release (for example new features, bug fixes or performance improvements would trigger a release while refactoring or changing code style would not). See [How can I change the type of commits that trigger a release?](#how-can-i-change-the-type-of-commits-that-trigger-a-release) for more details.
## Can I set the initial release version of my package to `0.0.1`?
This is not supported by semantic-release. [Semantic Versioning](https://semver.org/) rules apply differently to major version zero and supporting those differences is out of scope and not one of the goals of the semantic-release project.
If your project is under heavy development, with frequent breaking changes, and is not production ready yet we recommend [publishing pre-releases](https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/pre-releases#publishing-pre-releases).
See [âIntroduction to SemVerâ - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) for more details on [Semantic Versioning](https://semver.org) and the recommendation to start at version `1.0.0`.
## Can I trust semantic-release with my releases?
**semantic-release** has a full unit and integration test suite that tests `npm` publishes against the [verdaccio](https://www.npmjs.com/package/verdaccio).
In addition, the [verify conditions step](https://semantic-release.gitbook.io/semantic-release/readme#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
## What is npx?
[`npx`](https://www.npmjs.com/package/npx) â short for "npm exec" â is a CLI to find and execute npm binaries within the local `node_modules` folder or in the $PATH. If a binary can't be located npx will download the required package and execute it from its cache location. The tool is bundled with [npm](https://www.npmjs.com/package/npm) >= 5.2, or can be installed via `npm install -g npx`. For more details and motivation read the [introductory blog post](https://medium.com/@maybekatz/introducing-npx-an-npm-package-runner-55f7d4bd282b) by [@zkat](https://github.com/zkat).
# Troubleshooting
## You do not have permission to publish 'package-name'
When running semantic-release you might encounter the following error:
```bash
npm ERR! publish Failed PUT 403
npm ERR! code E403
npm ERR! You do not have permission to publish "". Are you logged in as the correct user? :
```
This is most likely related to a misconfiguration of the [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) or to your user [missing permission](https://docs.npmjs.com/cli/team) for publishing.
It might also happen if the package name you are trying to publish already exists (in the case of npm, you may be trying to publish a new version of a package that is not yours, hence the permission error).
To verify if your package name is available you can use [npm-name-cli](https://github.com/sindresorhus/npm-name-cli):
```bash
$ npm install --global npm-name-cli
$ npm-name
```
If the package name is not available, change it in your `package.json` or consider using an [npm scope](https://docs.npmjs.com/misc/scope).
## Squashed commits are ignored by **semantic-release**
**semantic-release** parses commits according to a [commit message convention](https://github.com/semantic-release/semantic-release#commit-message-format) to figure out how they affect the codebase. Commits that doesn't follow the project's commit message convention are simply ignored.
When [squashing commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) most Git tools will by default generate a new commit message with a summary of the squashed commits. This commit message will most likely not be compliant with the project's commit message convention and therefore will be ignored by **semantic-release**.
When squashing commits make sure to rewrite the resulting commit message to be compliant with the project's commit message convention.
**Note**: if the resulting squashed commit encompasses multiple changes (for example multiple unrelated features or fixes) then it's probably not a good idea to squash those commits together. A commit should contain exactly one self-contained functional change and a functional change should be contained in exactly one commit. See [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit).
## `reference already exists` error when pushing tag
**semantic-release** read [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) that are present in the history of your release branch in order to determine the last release published. Then it determines the next version to release based on the commits pushed since then and create the corresponding tag. If a tag with the name already in your repository, Git will throw and error as tags must be unique across the repository. This situation happens when you have a version tag identical to the new one **semantic-release** is trying to create that is not in the history of the current branch.
If an actual release with that version number was published you need to merge all the commits up to that release into your release branch.
If there is no published release with that version number, the tag must be deleted.
```bash
# Verify if the commit exists in the repository
$ git rev-list -1
# If a commit sha is returned, then the tag exists
# Verify the branches having the tagged commit in their history
$ git branch --contains
# Delete the tag
$ git tag -d
$ git push origin :refs/tags/
```
## release not found release branch after `git push --force`
**semantic-release** is using both [git tags](https://git-scm.com/docs/git-tag) and [git notes](https://git-scm.com/docs/git-notes) to store information about which releases happened in which branch.
After a git history rewrite due to a `git push --force`, the git tags and notes referencing the commits that were rewritten are lost.
To recover from that situation, do the following:
1. Delete the tag(s) for the release(s) that have been lost from the git history. You can delete each tag from remote using `git push origin -d :[TAG NAME]`, e.g. `git push origin -d :v2.0.0-beta.1`. You can delete tags locally using `git tag -d [TAG NAME]`, e.g. `git tag -d v2.0.0-beta.1`.
2. Re-create the tags locally: `git tag [TAG NAME] [COMMIT HASH]`, where `[COMMIT HASH]` is the new commit that created the release for the lost tag. E.g. `git tag v2.0.0-beta.1 abcdef0`
3. Re-create the git notes for each release tag, e.g. `git notes --ref semantic-release add -f -m '{"channels":["beta"]}' v2.0.0-beta.1`. If the release was also published in the default channel (usually `master`/`main`), then set the first channel to `null`, e.g. `git notes --ref semantic-release add -f -m '{"channels":[null, "beta"]}'`
4. Push the local notes: `git push --force origin refs/notes/semantic-release`. The `--force` is needed after the rebase. Be careful.
# Node version requirement
**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 22.14.0 or higher**.
**semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency. Therefore, the only constraint is to run the `semantic-release` in a CI environment providing version of Node that meets our version requirement.
See our [Node Support Policy](https://semantic-release.gitbook.io/semantic-release/support/node-support-policy) for our long-term promise regarding Node version support.
## Recommended solution
### Run at least one CI job with a version of Node that meets our version requirement
The recommended approach is to run the `semantic-release` command from a CI job running on the latest available LTS version of node. This can either be a job used by your project to test on the latest Node LTS version or a dedicated job for the release steps.
See [CI configuration](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration) and [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations#ci-configurations) for more details.
## Alternative solutions
### Use `npx` to execute in the latest LTS version of Node
`npx` is included with npm >= 5.2 and can be used to download the latest [Node LTS package published on npm](https://www.npmjs.com/package/node). Use it to execute the `semantic-release` command.
```bash
$ npx -p node@v24 -c "npx semantic-release"
```
**Note**: See [What is npx](https://semantic-release.gitbook.io/semantic-release/faq#what-is-npx) for more details.
### Use `nvm`
If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to the latest LTS version of Node before running the `semantic-release` command.
```bash
$ nvm install 'lts/*' && npx semantic-release
```
# Node Support Policy
We will always support at least the latest [Long-Term Support](https://github.com/nodejs/Release) version of Node, but provide no promise of support for older versions. The supported range will always be defined in the `engines.node` property of the `package.json` of our packages.
We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment.
It's possible this package will work correctly on newer versions of Node. It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support.
As new Node LTS versions become available we may remove previous versions from the `engines.node` property of our package's `package.json` file. Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package. We will not accept any requests to support an end-of-life version of Node. Any merge requests or issues supporting an end-of-life version of Node will be closed.
We will accept code that allows this package to run on newer, non-LTS, versions of Node. Furthermore, we will attempt to ensure our own changes work on the latest version of Node. To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current.
JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property. If you encounter issues installing this package, please report the issue to your package manager.
# Git version requirement
**semantic-release** uses Git CLI commands to read information about the repository such as branches, commit history and tags. Certain commands and options (such as [the `--merged` option of the `git tag` command](https://git-scm.com/docs/git-tag/2.7.0#git-tag---no-mergedltcommitgt) or bug fixes related to `git ls-files`) used by **semantic-release** are only available in Git version 2.7.1 and higher.
# Introduction
đŠđ semantic-release
Fully automated version management and package publishing
[](https://spectrum.chat/semantic-release) [](https://travis-ci.org/semantic-release/semantic-release) [](https://codecov.io/gh/semantic-release/semantic-release) [](https://greenkeeper.io) [](#badge)
[](https://www.npmjs.com/package/semantic-release) [](https://www.npmjs.com/package/semantic-release) [](https://www.npmjs.com/package/semantic-release)
**semantic-release** automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org) specification.
> Trust us, this will change your workflow for the better. â [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release)
## Highlights
* Fully automated release
* Enforce [Semantic Versioning](https://semver.org) specification
* New features and fixes are immediately available to users
* Notify maintainers and users of new releases
* Use formalized commit message convention to document changes in the codebase
* Publish on different distribution channels (such as [npm dist-tags](https://docs.npmjs.com/cli/dist-tag)) based on git merges
* Integrate with your [continuous integration workflow](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations)
* Avoid potential errors associated with manual releases
* Support any [package managers and languages](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#package-managers-and-languages) via [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins)
* Simple and reusable configuration via [shareable configurations](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations)
## How does it work?
### Commit message format
**semantic-release** uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publishes the release.
By default **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). The commit message format can be changed with the [`preset` or `config` options](https://semantic-release.gitbook.io/semantic-release/usage/configuration#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins.
Tools such as [commitizen](https://github.com/commitizen/cz-cli) or [commitlint](https://github.com/conventional-changelog/commitlint) can be used to help contributors and enforce valid commit messages.
Here is an example of the release type that will be done based on a commit messages:
| Commit message | Release type |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |
| `fix(pencil): stop graphite breaking when too much pressure applied` | Patch Release |
| `feat(pencil): add 'graphiteWidth' option` | ~~Minor~~ Feature Release |
| perf(pencil): remove graphiteWidth optionBREAKING CHANGE: The graphiteWidth option has been removed.The default graphite width of 10mm is always used for performance reasons.
| ~~Major~~ Breaking Release |
### Automation with CI
**semantic-release** is meant to be executed on the CI environment after every successful build on the release branch. This way no human is directly involved in the release process and the releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org).
### Triggering a release
For each new commits added to one of the release branches (for example `master`, `next`, `beta`), with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities.
**semantic-release** offers various ways to control the timing, the content and the audience of published releases. See example workflows in the following recipes:
* [Using distribution channels](https://github.com/semantic-release/semantic-release/tree/55be0ba2b1d8a5f7d817f0d4567be04170580028/docs/recipes/distribution-channels.md#publishing-on-distribution-channels)
* [Maintenance releases](https://github.com/semantic-release/semantic-release/tree/55be0ba2b1d8a5f7d817f0d4567be04170580028/docs/recipes/maintenance-releases.md#publishing-maintenance-releases)
* [Pre-releases](https://github.com/semantic-release/semantic-release/tree/55be0ba2b1d8a5f7d817f0d4567be04170580028/docs/recipes/pre-releases.md#publishing-pre-releases)
### Release steps
After running the tests, the command `semantic-release` will execute the following steps:
| Step | Description |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Verify Conditions | Verify all the conditions to proceed with the release. |
| Get last release | Obtain the commit corresponding to the last release by analyzing [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). |
| Analyze commits | Determine the type of release based on the commits added since the last release. |
| Verify release | Verify the release conformity. |
| Generate notes | Generate release notes for the commits added since the last release. |
| Create Git tag | Create a Git tag corresponding to the new release version. |
| Prepare | Prepare the release. |
| Publish | Publish the release. |
| Notify | Notify of new releases or errors. |
## Requirements
In order to use **semantic-release** you need:
* To host your code in a [Git repository](https://git-scm.com)
* Use a Continuous Integration service that allows you to [securely set up credentials](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication)
* Git CLI version [2.7.1 or higher](https://semantic-release.gitbook.io/semantic-release/support/faq#why-does-semantic-release-require-git-version--271) installed in your Continuous Integration environment
* [Node.js](https://nodejs.org) version [10.18 or higher](https://semantic-release.gitbook.io/semantic-release/support/faq#why-does-semantic-release-require-node-version--1018) installed in your Continuous Integration environment
## Documentation
* Usage
* [Getting started](https://semantic-release.gitbook.io/semantic-release/usage/getting-started#getting-started)
* [Installation](https://semantic-release.gitbook.io/semantic-release/usage/installation#installation)
* [CI Configuration](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#ci-configuration)
* [Configuration](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration)
* [Plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins)
* [Workflow configuration](https://semantic-release.gitbook.io/semantic-release/usage/workflow-configuration)
* [Shareable configurations](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations)
* Extending
* [Plugins](https://semantic-release.gitbook.io/semantic-release/extending/plugins-list)
* [Shareable configuration](https://semantic-release.gitbook.io/semantic-release/extending/shareable-configurations-list)
* Recipes
* [CI configurations](https://semantic-release.gitbook.io/semantic-release/recipes/recipes)
* [Git hosted services](https://semantic-release.gitbook.io/semantic-release/recipes/recipes)
* [Release workflow](https://semantic-release.gitbook.io/semantic-release/recipes/recipes)
* [Package managers and languages](https://semantic-release.gitbook.io/semantic-release/recipes/recipes)
* Developer guide
* [JavaScript API](https://semantic-release.gitbook.io/semantic-release/developer-guide/js-api)
* [Plugins development](https://semantic-release.gitbook.io/semantic-release/developer-guide/plugin)
* [Shareable configuration development](https://semantic-release.gitbook.io/semantic-release/developer-guide/shareable-configuration)
* Support
* [Resources](https://semantic-release.gitbook.io/semantic-release/support/resources)
* [Frequently Asked Questions](https://semantic-release.gitbook.io/semantic-release/support/faq)
* [Troubleshooting](https://semantic-release.gitbook.io/semantic-release/support/troubleshooting)
* [Node version requirement](https://semantic-release.gitbook.io/semantic-release/support/node-version)
* [Node Support Policy](https://semantic-release.gitbook.io/semantic-release/support/node-support-policy)
## Get help
* [Stack Overflow](https://stackoverflow.com/questions/tagged/semantic-release)
* [Spectrum community](https://spectrum.chat/semantic-release)
* [Twitter](https://twitter.com/SemanticRelease)
## Badge
Let people know that your package is published using **semantic-release** by including this badge in your readme.
[](https://github.com/semantic-release/semantic-release)
```
[](https://github.com/semantic-release/semantic-release)
```
## Team
| [](https://github.com/boennemann) | [](https://github.com/relekang) | [](https://github.com/jo) | [](https://github.com/gr2m) | [](https://github.com/finnp) | [](https://github.com/pvdlg) | [](https://github.com/christophwitzko) |
| ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| [Stephan Bönnemann](https://github.com/boennemann) | [Rolf Erik Lekang](https://github.com/relekang) | [Johannes Jörg Schmidt](https://github.com/jo) | [Gregor Martynus](https://github.com/gr2m) | [Finn Pauls](https://github.com/finnp) | [Pierre Vanduynslager](https://github.com/pvdlg) | [Christoph Witzko](https://github.com/christophwitzko) |
# Getting started
In order to use **semantic-release** you must follow these steps: 1. [Install](https://semantic-release.gitbook.io/semantic-release/installation#installation) **semantic-release** in your project 2. Configure your Continuous Integration service to [run **semantic-release**](https://semantic-release.gitbook.io/semantic-release/ci-configuration#run-semantic-release-only-after-all-tests-succeeded) 3. Configure your Git repository and package manager repository [authentication](https://semantic-release.gitbook.io/semantic-release/ci-configuration#authentication) in your Continuous Integration service 4. Configure **semantic-release** [options and plugins](https://semantic-release.gitbook.io/semantic-release/configuration#configuration)
Alternatively those steps can be easily done with the [**semantic-release** interactive CLI](https://github.com/semantic-release/cli):
```bash
npm install -g semantic-release-cli
cd your-module
semantic-release-cli setup
```
See the [semantic-release-cli](https://github.com/semantic-release/cli#what-it-does) documentation for more details.
**Note**: only a limited number of options, CI services and plugins are currently supported by `semantic-release-cli`.
# Installation
## Local installation
For [Node modules projects](https://docs.npmjs.com/getting-started/creating-node-modules) we recommend installing **semantic-release** locally and running the `semantic-release` command with [npx](https://www.npmjs.com/package/npx):
```bash
$ npm install --save-dev semantic-release
```
Then in the CI environment:
```bash
$ npx semantic-release
```
**Note:** `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently find the semantic-release binary and to execute it. See [What is npx](https://semantic-release.gitbook.io/semantic-release/support/faq#what-is-npx) for more details.
## Global installation
For other type of projects we recommend installing **semantic-release** directly in the CI environment, also with [npx](https://www.npmjs.com/package/npx):
```bash
$ npx semantic-release
```
**Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@15`). This way your build will not automatically use the next major **semantic-release** release that could possibly break your build. You will have to upgrade manually when a new major version is released.
**Note**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it. See [What is npx](https://semantic-release.gitbook.io/semantic-release/support/faq#what-is-npx) for more details.
# CI Configuration
## Run `semantic-release` only after all tests succeeded
The `semantic-release` command must be executed only after all the tests in the CI build pass. If the build runs multiple jobs (for example to test on multiple Operating Systems or Node versions) the CI has to be configured to guarantee that the `semantic-release` command is executed only after all jobs are successful. Here is a few example of the CI services that can be used to achieve this:
* [Travis Build Stages](https://docs.travis-ci.com/user/build-stages)
* [CircleCI Workflows](https://circleci.com/docs/2.0/workflows)
* [GitHub Actions](https://github.com/features/actions)
* [Codeship Deployment Pipelines](https://documentation.codeship.com/basic/builds-and-configuration/deployment-pipelines)
* [GitLab Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html#introduction-to-pipelines-and-jobs)
* [Codefresh Pipelines](https://codefresh.io/docs/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines)
* [Wercker Workflows](http://devcenter.wercker.com/docs/workflows)
* [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline).
See [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details.
## Authentication
### Push access to the remote repository
**semantic-release** requires push access to the project Git repository in order to create [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). The Git authentication can be set with one of the following environment variables:
| Variable | Description |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `GH_TOKEN` or `GITHUB_TOKEN` | A GitHub [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line). |
| `GL_TOKEN` or `GITLAB_TOKEN` | A GitLab [personal access token](https://docs.gitlab.com/ce/user/profile/personal_access_tokens.html). |
| `BB_TOKEN` or `BITBUCKET_TOKEN` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html). |
| `GIT_CREDENTIALS` | [URL encoded](https://en.wikipedia.org/wiki/Percent-encoding) Git username and password in the format `:`. The username and password must each be individually URL encoded, not the `:` separating them. |
Alternatively the Git authentication can be set up via [SSH keys](https://semantic-release.gitbook.io/semantic-release/recipes/git-hosted-services/git-auth-ssh-keys).
### Authentication for plugins
Most **semantic-release** [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins) require setting up authentication in order to publish to a package manager registry. The default [@semantic-release/npm](https://github.com/semantic-release/npm#environment-variables) and [@semantic-release/github](https://github.com/semantic-release/github#environment-variables) plugins require the following environment variables:
| Variable | Description |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `NPM_TOKEN` | npm token created via npm token create .Note : Only the auth-only level of npm two-factor authentication is supported.
|
| `GH_TOKEN` | GitHub authentication token.Note : Only the personal token authentication is supported.
|
See each plugin's documentation for the environment variables required.
The authentication token/credentials have to be made available in the CI service via environment variables.
See [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details on how to configure environment variables in your CI service.
**Note**: The environment variables `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN` and `GITLAB_TOKEN` can be used for both the Git authentication and the API authentication required by [@semantic-release/github](https://github.com/semantic-release/github) and [@semantic-release/gitlab](https://github.com/semantic-release/gitlab).
# Configuration
**semantic-release** configuration consists of:
* Git repository ([URL](#repositoryurl) and options [release branches](#branches) and [tag format](#tagformat))
* Plugins [declaration](#plugins) and options
* Run mode ([debug](#debug), [dry run](#dryrun) and [local (no CI)](#ci))
All of these options can be configured through config file, CLI arguments or by extending a [shareable configuration](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations).
Additionally, metadata of Git tags generated by **semantic-release** can be customized via standard [Git environment variables](#git-environment-variables).
## Configuration file
**semantic-release**âs [options](#options), mode and [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins) can be set via either:
* A `.releaserc` file, written in YAML or JSON, with optional extensions: .`yaml`/`.yml`/`.json`/`.js`
* A `release.config.js` file that exports an object
* A `release` key in the project's `package.json` file
Alternatively, some options can be set via CLI arguments.
The following three examples are the same.
* Via `release` key in the project's `package.json` file:
```javascript
{
"release": {
"branches": ["master", "next"]
}
}
```
* Via `.releaserc` file:
```javascript
{
"branches": ["master", "next"]
}
```
* Via CLI argument:
```bash
$ semantic-release --branches next
```
**Note**: CLI arguments take precedence over options configured in the configuration file.
**Note**: Plugin options cannot be defined via CLI arguments and must be defined in the configuration file.
**Note**: When configuring via `package.json`, the configuration must be under the `release` property. However, when using a `.releaserc` or a `release.config.js` file, the configuration must be set without a `release` property.
## Options
### extends
Type: `Array`, `String`\
CLI arguments: `-e`, `--extends`
List of modules or file paths containing a [shareable configuration](https://semantic-release.gitbook.io/semantic-release/usage/shareable-configurations). If multiple shareable configurations are set, they will be imported in the order defined with each configuration option taking precedence over the options defined in a previous shareable configuration.
**Note**: Options defined via CLI arguments or in the configuration file will take precedence over the ones defined in any shareable configuration.
### branches
Type: `Array`, `String`, `Object`\
Default: `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`\
CLI arguments: `--branches`
The branches on which releases should happen. By default **semantic-release** will release:
* regular releases to the default distribution channel from the branch `master`
* regular releases to a distribution channel matching the branch name from any existing branch with a name matching a maintenance release range (`N.N.x` or `N.x.x` or `N.x` with `N` being a number)
* regular releases to the `next` distribution channel from the branch `next` if it exists
* regular releases to the `next-major` distribution channel from the branch `next-major` if it exists
* prereleases to the `beta` distribution channel from the branch `beta` if it exists
* prereleases to the `alpha` distribution channel from the branch `alpha` if it exists
**Note**: If your repository does not have a release branch, then **semantic-release** will fail with an `ERELEASEBRANCHES` error message. If you are using the default configuration, you can fix this error by pushing a `master` branch.
**Note**: Once **semantic-release** is configured, any user with the permission to push commits on one of those branches will be able to publish a release. It is recommended to protect those branches, for example with [GitHub protected branches](https://help.github.com/articles/about-protected-branches).
See [Workflow configuration](https://semantic-release.gitbook.io/semantic-release/workflow-configuration#workflow-configuration) for more details.
### repositoryUrl
Type: `String`\
Default: `repository` property in `package.json` or [git origin url](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes)\
CLI arguments: `-r`, `--repository-url`
The git repository URL.
Any valid git url format is supported (See [Git protocols](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols)).
### tagFormat
Type: `String`\
Default: `v${version}`\
CLI arguments: `-t`, `--tag-format`
The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) format used by **semantic-release** to identify releases. The tag name is generated with [Lodash template](https://lodash.com/docs#template) and will be compiled with the `version` variable.
**Note**: The `tagFormat` must contain the `version` variable exactly once and compile to a [valid Git reference](https://git-scm.com/docs/git-check-ref-format#_description).
### plugins
Type: `Array`\
Default: `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`\
CLI arguments: `-p`, `--plugins`
Define the list of plugins to use. Plugins will run in series, in the order defined, for each [steps](https://semantic-release.gitbook.io/semantic-release/undefined#release-steps) if they implement it.
Plugins configuration can defined by wrapping the name and an options object in an array.
See [Plugins configuration](https://semantic-release.gitbook.io/semantic-release/plugins#plugins) for more details.
### dryRun
Type: `Boolean`\
Default: `false` if running in a CI environment, `true` otherwise\
CLI arguments: `-d`, `--dry-run`
Dry-run mode, skip publishing, print next version and release notes.
### ci
Type: `Boolean`\
Default: `true`\
CLI arguments: `--ci` / `--no-ci`
Set to `false` to skip Continuous Integration environment verifications. This allows for making releases from a local machine.
**Note**: The CLI arguments `--no-ci` is equivalent to `--ci false`.
### debug
Type: `Boolean`\
Default: `false`\
CLI argument: `--debug`
Output debugging information. This can also be enabled by setting the `DEBUG` environment variable to `semantic-release:*`.
**Note**: The `debug` is used only supported via CLI argument. To enable debug mode from the [JS API](https://semantic-release.gitbook.io/semantic-release/developer-guide/js-api#javascript-api) use `require('debug').enable('semantic-release:*')`.
## Git environment variables
| Variable | Description | Default |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------ |
| `GIT_AUTHOR_NAME` | The author name associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot. |
| `GIT_AUTHOR_EMAIL` | The author email associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot email address. |
| `GIT_COMMITTER_NAME` | The committer name associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot. |
| `GIT_COMMITTER_EMAIL` | The committer email associated with the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). See [Git environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_committing). | @semantic-release-bot email address. |
## Existing version tags
**semantic-release** uses [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) to determine the commits added since the last release. If a release has been published before setting up **semantic-release** you must make sure the most recent commit included in the last published release is in the [release branches](#branches) history and is tagged with the version released, formatted according to the [tag format](#tagformat) configured (defaults to `vx.y.z`).
If the previous releases were published with [`npm publish`](https://docs.npmjs.com/cli/publish) this should already be the case.
For example, if your release branch is `master`, the last release published on your project is `1.1.0` and the last commit included has the sha `1234567`, you must make sure this commit is in `master` history and is tagged with `v1.1.0`.
```bash
# Make sure the commit 1234567 is in the release branch history
$ git branch --contains 1234567
# If the commit is not in the branch history it means that either:
# - you use a different branch than the one your release from before
# - or the commit sha has been rewritten (with git rebase)
# In both cases you need to configure your repository to have the last release commit in the history of the release branch
# List the tags for the commit 1234567
$ git tag --contains 1234567
# If v1.1.0 is not in the list you add it with
$ git tag v1.1.0 1234567
$ git push origin v1.1.0
```
# Plugins
Each [release step](https://semantic-release.gitbook.io/semantic-release/undefined#release-steps) is implemented by configurable plugins. This allows for support of different [commit message formats](https://semantic-release.gitbook.io/semantic-release/undefined#commit-message-format), release note generators and publishing platforms.
A plugin is a npm module that can implement one or more of the following steps:
| Step | Required | Description |
| ------------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `verifyConditions` | No | Responsible for verifying conditions necessary to proceed with the release: configuration is correct, authentication token are valid, etc... |
| `analyzeCommits` | Yes | Responsible for determining the type of the next release (`major`, `minor` or `patch`). If multiple plugins with a `analyzeCommits` step are defined, the release type will be the highest one among plugins output. |
| `verifyRelease` | No | Responsible for verifying the parameters (version, type, dist-tag etc...) of the release that is about to be published. |
| `generateNotes` | No | Responsible for generating the content of the release note. If multiple plugins with a `generateNotes` step are defined, the release notes will be the result of the concatenation of each plugin output. |
| `prepare` | No | Responsible for preparing the release, for example creating or updating files such as `package.json`, `CHANGELOG.md`, documentation or compiled assets and pushing a commit. |
| `publish` | No | Responsible for publishing the release. |
| `success` | No | Responsible for notifying of a new release. |
| `fail` | No | Responsible for notifying of a failed release. |
**Note:** If no plugin with a `analyzeCommits` step is defined `@semantic-release/commit-analyzer` will be used.
## Plugins installation
### Default plugins
These four plugins are already part of **semantic-release** and don't have to be installed separately:
```
"@semantic-release/commit-analyzer"
"@semantic-release/github"
"@semantic-release/npm"
"@semantic-release/release-notes-generator"
```
### Additional plugins
[Additional plugins](https://semantic-release.gitbook.io/semantic-release/extending/plugins-list) have to be installed via npm:
```bash
$ npm install @semantic-release/git @semantic-release/changelog -D
```
## Plugins declaration and execution order
Each plugin must be configured with the [`plugins` options](https://semantic-release.gitbook.io/semantic-release/configuration#plugins) by specifying the list of plugins by npm module name.
```javascript
{
"plugins": ["@semantic-release/commit-analyzer", "@semantic-release/release-notes-generator", "@semantic-release/npm"]
}
```
**Note:** If the `plugins` option is defined, it overrides the default plugin list, rather than merging with it.
For each [release step](https://semantic-release.gitbook.io/semantic-release/undefined#release-steps) the plugins that implement that step will be executed in the order in which they are defined.
```javascript
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/npm",
"@semantic-release/git"
]
}
```
With this configuration **semantic-release** will:
* execute the `verifyConditions` implementation of `@semantic-release/npm` then `@semantic-release/git`
* execute the `analyzeCommits` implementation of `@semantic-release/commit-analyzer`
* execute the `generateNotes` implementation of `@semantic-release/release-notes-generator`
* execute the `prepare` implementation of `@semantic-release/npm` then `@semantic-release/git`
* execute the `publish` implementation of `@semantic-release/npm`
## Plugin options configuration
A plugin configuration can be specified by wrapping the name and an options object in an array. Options configured this way will be passed only to that specific plugin.
Global plugin configuration can be defined at the root of the **semantic-release** configuration object. Options configured this way will be passed to all plugins.
```javascript
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
["@semantic-release/github", {
"assets": ["dist/**"]
}],
"@semantic-release/git"
],
"preset": "angular"
}
```
With this configuration:
* All plugins will receive the `preset` option, which will be used by both `@semantic-release/commit-analyzer` and `@semantic-release/release-notes-generator` (and ignored by `@semantic-release/github` and `@semantic-release/git`)
* The `@semantic-release/github` plugin will receive the `assets` options (`@semantic-release/git` will not receive it and therefore will use it's default value for that option)
# Workflow configuration
**semantic-release** allow to manage and automate complex release workflow, based on multiple Git branches and distribution channels. This allow to:
* Distributes certain releases to a particular group of users via distribution channels
* Manage the availability of releases on distribution channels via branches merge
* Maintain multiple lines of releases in parallel
* Work on large future releases outside the normal flow of one version increment per Git push
See [Release workflow recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#release-workflow) for detailed examples.
The release workflow is configured via the [branches option](https://semantic-release.gitbook.io/semantic-release/configuration#branches) which accepts a single or an array of branch definitions. Each branch can be defined either as a string, a [glob](https://github.com/micromatch/micromatch#matching-features) or an object. For string and glob definitions each [property](#branches-properties) will be defaulted.
A branch can defined as one of three types:
* [release](#release-branches): to make releases on top of the last version released
* [maintenance](#maintenance-branches): to make release on top of an old release
* [pre-release](#pre-release-branches): to make pre-releases
The type of the branch is automatically determined based on naming convention and/or [properties](#branches-properties).
## Branches properties
| Property | Branch type | Description | Default |
| ------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| `name` | All | **Required.** The Git branch holding the commits to analyze and the code to release. See [name](#name). | - The value itself if defined as a `String` or the matching branches name if defined as a glob. |
| `channel` | All | The distribution channel on which to publish releases from this branch. Set to `false` to force the default distribution channel instead of using the default. See [channel](#channel). | `undefined` for the first release branch, the value of `name` for subsequent ones. |
| `range` | [maintenance](#maintenance-branches) only | **Required unless `name` is formatted like `N.N.x` or `N.x` (`N` is a number).** The range of [semantic versions](https://semver.org) to support on this branch. See [range](#range). | The value of `name`. |
| `prerelease` | [pre-release](#pre-release-branches) only | **Required.** The pre-release detonation to append to [semantic versions](https://semver.org) released from this branch. See [prerelease](#prerelease). | - |
### name
A `name` is required for any type of branch. It can be defined as a [glob](https://github.com/micromatch/micromatch#matching-features) in which case the definition will be expanded to one per matching branch existing in the repository.
If `name` doesn't match to any branch existing in the repository, the definition will be ignored. For example the default configuration includes the definition `next` and `next-major` which will become active only when the branches `next` and/or `next-major` are created in the repository. This allow to define your workflow once with all potential branches you might use and have the effective configuration evolving as you create new branches.
For example the configuration `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next']` will be expanded as:
```javascript
{
branches: [
{name: '1.x', range: '1.x', channel: '1.x'}, // Only after the `1.x` is created in the repo
{name: '2.x', range: '2.x', channel: '2.x'}, // Only after the `2.x` is created in the repo
{name: 'master'},
{name: 'next', channel: 'next'}, // Only after the `next` is created in the repo
]
}
```
### channel
The `channel` can be defined for any branch type. By default releases will be done on the default distribution channel (for example the `@latest` [dist-tag](https://docs.npmjs.com/cli/dist-tag) for npm) for the first [release branch](#release-branches) and on a distribution channel named based on the branch `name` for any other branch. If the `channel` property is set to `false` the default channel will be used.
The value of `channel`, if defined as a string, is generated with [Lodash template](https://lodash.com/docs#template) with the variable `name` available.
For example the configuration `['master', {name: 'next', channel: 'channel-${name}'}]` will be expanded as:
```javascript
{
branches: [
{name: 'master'}, // `channel` is undefined so the default distribution channel will be used
{name: 'next', channel: 'channel-next'}, // `channel` is built with the template `channel-${name}`
]
}
```
### range
A `range` only applies to maintenance branches, is required and must be formatted like `N.N.x` or `N.x` (`N` is a number). In case the `name` is formatted as a range (for example `1.x` or `1.5.x`) the branch will be considered a maintenance branch and the `name` value will be used for the `range`.
For example the configuration `['1.1.x', '1.2.x', 'master']` will be expanded as:
```javascript
{
branches: [
{name: '1.1.x', range: '1.1.x', channel: '1.1.x'},
{name: '1.2.x', range: '1.2.x', channel: '1.2.x'},
{name: 'master'},
]
}
```
### prerelease
A `prerelease` property applies only to pre-release branches and the `prerelease` value must be valid per the [Semantic Versioning Specification](https://semver.org/#spec-item-9). It will determine the name of versions (for example if `prerelease` is set to `beta` the version be formatted like `2.0.0-beta.1`, `2.0.0-beta.2` etc...). If the `prerelease` property is set to `true` the `name` value will be used.
The value of `prerelease`, if defined as a string, is generated with [Lodash template](https://lodash.com/docs#template) with the variable `name` available.
For example the configuration `['master', {name: 'pre/rc', prerelease: '${name.replace(/^pre\\//g, "")}'}, {name: 'beta', prerelease: true}]` will be expanded as:
```javascript
{
branches: [
{name: 'master'},
{name: 'pre/rc', channel: 'pre/rc', prerelease: 'rc'}, // `prerelease` is built with the template `${name.replace(/^pre\\//g, "")}`
{name: 'beta', channel: 'beta', prerelease: 'beta'}, // `prerelease` is set to `beta` as it is the value of `name`
]
}
```
## Branch types
### Release branches
A release branch is the base type of branch used by **semantic-release** that allows to publish releases with a [semantic version](https://semver.org), optionally on a specific distribution channel. Distribution channels (for example [npm dist-tags](https://docs.npmjs.com/cli/dist-tag) or [Chrome release channels](https://www.chromium.org/getting-involved/dev-channel)) are a way to distribute new releases only to a subset of users in order to get early feedback. Later on, those releases can be added to the general distribution channel to be made available to all users.
**semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release branch to another](#merging-into-a-release-branch).
A project must define a minimum of 1 release branch and can have a maximum of 3. The order of the release branch definitions is significant, as versions released on a given branch must always be higher than the last release made on the previous branch. This allow to avoid situation that would lead to an attempt to publish releases with the same version number but different codebase. When multiple release branches are configured and a commit that would create a version conflict is pushed, **semantic-release** will not perform the release and will throw an `EINVALIDNEXTVERSION` error, listing the problematic commits and the valid branches on which to move them.
**Note:** With **semantic-release** as with most package managers, a release version must be unique, independently of the distribution channel on which it is available.
See [publishing on distribution channels recipe](https://github.com/semantic-release/semantic-release/tree/6b5b02ea755b74e1c2ea9a2dfff6576f5f15e870/docs/recipes/distribution-channels.md) for a detailed example.
#### Pushing to a release branch
With the configuration `"branches": ["master", "next"]`, if the last release published from `master` is `1.0.0` and the last one from `next` is `2.0.0` then:
* Only versions in range `1.x.x` can be published from `master`, so only `fix` and `feat` commits can be pushed to `master`
* Once `next` get merged into `master` the release `2.0.0` will be made available on the channel associated with `master` and both `master` and `next` will accept any commit type
This verification prevent scenario such as: 1. Create a `feat` commit on `next` which triggers the release of version `1.0.0` on the `next` channel 2. Merge `next` into `master` which adds `1.0.0` on the default channel 3. Create a `feat` commit on `next` which triggers the release of version `1.1.0` on the `next` channel 4. Create a `feat` commit on `master` which would attempt to release the version `1.1.0` on the default channel
In step 4 **semantic-release** will throw an `EINVALIDNEXTVERSION` error to prevent the attempt at releasing version `1.1.0` which was already released on step 3 with a different codebase. The error will indicate that the commit should be created on `next` instead. Alternatively if the `next` branch is merged into `master`, the version `1.1.0` will be made available on the default channel and the `feat` commit would be allowed on `master` to release `1.2.0`.
#### Merging into a release branch
When merging commits associated with a release from one release branch to another, **semantic-release** will make the corresponding version available on the channel associated with the target branch.
When merging commits not associated with a release, commits from a [maintenance branch](#maintenance-branches) or commits from a [pre-release branch](#pre-release-branches) **semantic-release** will treat them as [pushed commits](#pushing-to-a-release-branch) and publish a new release if necessary.
### Maintenance branches
A maintenance branch is a type of branch used by **semantic-release** that allows to publish releases with a [semantic version](https://semver.org) on top of the codebase of an old release. This is useful when you need to provide fixes or features to users who cannot upgrade to the last version of your package.
A maintenance branch is characterized by a range which defines the versions that can be published from it. The [`range`](#range) value of each maintenance branch must be unique across the project.
**semantic-release** will always publish releases to a distribution channel specific to the range, so only the users who choose to use that particular line of versions will receive new releases.
Maintenance branches are always considered lower than [release branches](#release-branches) and similarly to them, when a commit that would create a version conflict is pushed, **semantic-release** will not perform the release and will throw an `EINVALIDNEXTVERSION` error, listing the problematic commits and the valid branches on which to move them.
**semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release or maintenance branch to another maintenance branch](#merging-into-a-maintenance-branch), however only version version within the branch `range` can be merged. Ia merged version is outside the maintenance branch `range` **semantic-release** will not add to the corresponding channel and will throw an `EINVALIDMAINTENANCEMERGE` error.
See [publishing maintenance releases recipe](https://github.com/semantic-release/semantic-release/tree/6b5b02ea755b74e1c2ea9a2dfff6576f5f15e870/docs/recipes/maintenance-releases.md) for a detailed example.
#### Pushing to a maintenance branch
With the configuration `"branches": ["1.0.x", "1.x", "master"]`, if the last release published from `master` is `1.5.0` then:
* Only versions in range `>=1.0.0 <1.1.0` can be published from `1.0.x`, so only `fix` commits can be pushed to `1.0.x`
* Only versions in range `>=1.1.0 <1.5.0` can be published from `1.x`, so only `fix` and `feat` commits can be pushed to `1.x` as long the resulting release is lower than `1.5.0`
* Once `2.0.0` is released from `master`, versions in range `>=1.1.0 <2.0.0` can be published from `1.x`, so any number of `fix` and `feat` commits can be pushed to `1.x`
#### Merging into a maintenance branch
With the configuration `"branches": ["1.0.x", "1.x", "master"]`, if the last release published from `master` is `1.0.0` then:
* Creating the branch `1.0.x` from `master` will make the `1.0.0` release available on the `1.0.x` distribution channel
* Pushing a `fix` commit on the `1.0.x` branch will release the version `1.0.1` on the `1.0.x` distribution channel
* Creating the branch `1.x` from `master` will make the `1.0.0` release available on the `1.x` distribution channel
* Merging the branch `1.0.x` into `1.x` will make the version `1.0.1` available on the `1.x` distribution channel
### Pre-release branches
A pre-release branch is a type of branch used by **semantic-release** that allows to publish releases with a [pre-release version](https://semver.org/#spec-item-9). Using a pre-release version allow to publish multiple releases with the same version. Those release will be differentiated via there identifiers (in `1.0.0-alpha.1` the identifier is `alpha.1`). This is useful when you need to work on a future major release that will include many breaking changes but you do not want to increment the version number for each breaking change commit.
A pre-release branch is characterized by the `prerelease` property that defines the static part of the version released (in `1.0.0-alpha.1` the static part fo the identifier is `alpha`). The [`prerelease`](#prerelease) value of each pre-release branch must be unique across the project.
**semantic-release** will always publish pre-releases to a specific distribution channel, so only the users who choose to use that particular line of versions will receive new releases.
When merging commits associated with an existing release, **semantic-release** will treat them as [pushed commits](#pushing-to-a-pre-release-branch) and publish a new release if necessary, but it will never add those releases to the distribution channel corresponding to the pre-release branch.
See [publishing pre-releases recipe](https://github.com/semantic-release/semantic-release/tree/6b5b02ea755b74e1c2ea9a2dfff6576f5f15e870/docs/recipes/pre-releases.md) for a detailed example.
#### Pushing to a pre-release branch
With the configuration `"branches": ["master", {"name": "beta", "prerelease": true}]`, if the last release published from `master` is `1.0.0` then:
* Pushing a `BREAKING CHANGE` commit on the `beta` branch will release the version `2.0.0-beta.1` on the `beta` distribution channel
* Pushing either a `fix`, `feat` or a `BREAKING CHANGE` commit on the `beta` branch will release the version `2.0.0-beta.2` (then `2.0.0-beta.3`, `2.0.0-beta.4`, etc...) on the `beta` distribution channel
#### Merging into a pre-release branch
With the configuration `"branches": ["master", {"name": "beta", "prerelease": true}]`, if the last release published from `master` is `1.0.0` and the last one published from `beta` is `2.0.0-beta.1` then:
* Pushing a `fix` commit on the `master` branch will release the version `1.0.1` on the default distribution channel
* Merging the branch `master` into `beta` will release the version `2.0.0-beta.2` on the `beta` distribution channel
# Shareable configurations
A shareable configuration is an [npm](https://www.npmjs.com/) package that exports a **semantic-release** configuration object. It allows for use of the same configuration across several projects.
The shareable configurations to use can be set with the [extends](https://semantic-release.gitbook.io/semantic-release/configuration#extends) option.
See [shareable configurations list](https://semantic-release.gitbook.io/semantic-release/extending/shareable-configurations-list).
# Plugins
## Official plugins
* [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `analyzeCommits`: Determine the type of release by analyzing commits with [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog)
* [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `generateNotes`: Generate release notes for the commits added since the last release with [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog)
* [@semantic-release/github](https://github.com/semantic-release/github)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `verifyConditions`: Verify the presence and the validity of the GitHub authentication and release configuration
* `publish`: Publish a [GitHub release](https://help.github.com/articles/about-releases)
* `success`: Add a comment to GitHub issues and pull requests resolved in the release
* `fail`: Open a GitHub issue when a release fails
* [@semantic-release/npm](https://github.com/semantic-release/npm)
* **Note**: this is already part of semantic-release and does not have to be installed separately
* `verifyConditions`: Verify the presence and the validity of the npm authentication and release configuration
* `prepare`: Update the package.json version and create the npm package tarball
* `publish`: Publish the package on the npm registry
* [@semantic-release/gitlab](https://github.com/semantic-release/gitlab)
* `verifyConditions`: Verify the presence and the validity of the GitLab authentication and release configuration
* `publish`: Publish a [GitLab release](https://docs.gitlab.com/ce/workflow/releases.html)
* [@semantic-release/git](https://github.com/semantic-release/git)
* `verifyConditions`: Verify the presence and the validity of the Git authentication and release configuration
* `prepare`: Push a release commit and tag, including configurable files
* [@semantic-release/changelog](https://github.com/semantic-release/changelog)
* `verifyConditions`: Verify the presence and the validity of the configuration
* `prepare`: Create or update the changelog file in the local project repository
* [@semantic-release/exec](https://github.com/semantic-release/exec)
* `verifyConditions`: Execute a shell command to verify if the release should happen
* `analyzeCommits`: Execute a shell command to determine the type of release
* `verifyRelease`: Execute a shell command to verifying a release that was determined before and is about to be published
* `generateNotes`: Execute a shell command to generate the release note
* `prepare`: Execute a shell command to prepare the release
* `publish`: Execute a shell command to publish the release
* `success`: Execute a shell command to notify of a new release
* `fail`: Execute a shell command to notify of a failed release
* [@semantic-release/apm](https://github.com/semantic-release/apm)
* `verifyConditions`: Verify the presence of the `ATOM_ACCESS_TOKEN` environment variable and the [`apm`](https://github.com/atom/apm) CLI
* `prepare`: Update the `package.json` version with [`npm version`](https://docs.npmjs.com/cli/version)
* `publish`: Publish the [Atom package](https://flight-manual.atom.io/hacking-atom/sections/publishing)
## Community plugins
[Open a Pull Request](https://github.com/semantic-release/semantic-release/blob/master/CONTRIBUTING.md#submitting-a-pull-request) to add your plugin to the list.
* [semantic-release-slack-bot](https://github.com/juliuscc/semantic-release-slack-bot)
* `verifyConditions`: Verify that the environment variable `SLACK_WEBHOOK` has been defined.
* `success`: Publish a message about the success to a slack channel.
* `fail`: Optionally publish a message about failure to a slack channel.
* [semantic-release-docker](https://github.com/felixfbecker/semantic-release-docker)
* `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry.
* `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
* [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr)
* `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry
* `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
* [semantic-release-vsce](https://github.com/raix/semantic-release-vsce)
* `verifyConditions`: Verify the presence and the validity of the vsce authentication and release configuration
* `prepare`: Create a `.vsix` for distribution
* `publish`: Publish the package to the Visual Studio Code marketplace
* [semantic-release-verify-deps](https://github.com/piercus/semantic-release-verify-deps)
* `verifyConditions`: Check the dependencies format against a regexp before a release
* [semantic-release-chrome](https://github.com/GabrielDuarteM/semantic-release-chrome)
* `verifyConditions`: Verify the presence of the authentication (set via environment variables)
* `prepare`: Write the correct version to the `manifest.json` and creates a zip file of the whole dist folder
* `publish`: Uploads the generated zip file to the webstore, and publish the item
* [semantic-release-firefox-add-on](https://github.com/tophat/semantic-release-firefox-add-on)
* `verifyConditions`: Verify that all required options are present and authentication is set via environment variables
* `prepare`: Write the correct version to the `manifest.json`
* `publish`: Creates an unsigned `.xpi` file, and submits it to the Mozilla Add On store for signing. Once the package is signed, downloads the signed `.xpi` to a local directory
* [semantic-release-gerrit](https://github.com/pascalMN/semantic-release-gerrit)
* `generateNotes`: Generate release notes with Gerrit reviews URL
* [semantic-release-expo](https://github.com/bycedric/semantic-release-expo)
* `verifyConditions`: Verify Expo manifest(s) are readable and valid.
* `prepare`: Update version, ios build number and android version code in the Expo manifest(s).
* [maven-semantic-release](https://github.com/conveyal/maven-semantic-release)
* `verifyConditions`: Verifies that the `pom.xml` file and other files exist and are setup to allow releases
* `verifyRelease`: Checks and warns (does not error by default) if the version numbers found on maven central and within the Git project differ by quite a bit
* `prepare`: Changes the version number in the `pom.xml` (or all `pom.xml` files in maven projects with multiple `pom.xml` files) and optionally creates a commit with this version number and pushes it to `master`
* `publish`: Runs `mvn deploy` to deploy to maven central and optionally will update to next snapshot version and merge changes to development branch
* [semantic-release-ado](https://github.com/lluchmk/semantic-release-ado)
* `prepare`: Stores the version number as an Azure DevOps pipeline variable availabe to downstream steps on the job
* [gradle-semantic-release](https://github.com/KengoTODA/gradle-semantic-release-plugin)
* `verifyConditions`: Verify that project has a Gradle wrapper script, and `build.gradle` contains a task to publish artifacts.
* `prepare`: Changes the version number in the `gradle.properties`
* `publish`: Triggers Gradle to publish artifacts.
* [semantic-release-circleci-orb](https://github.com/matt-oakes/semantic-release-circleci-orb)
* `verifyConditions`: Verify the presence of the `CIRCLECI_API_TOKEN` environment variable, `orbName` option, and the `circleci` CLI.
* `publish`: Publish the CircleCI orb.
* [semantic-release-github-pages](https://github.com/qiwi/semantic-release-gh-pages-plugin)
* `verifyConditions`: Verify the presence of the auth token set via environment variables.
* `publish`: Pushes commit to the documentation branch.
* [leiningen-semantic-release](https://github.com/NoxHarmonium/leiningen-semantic-release)
* `verifyConditions`: Checks the project.clj is syntactically valid.
* `prepare`: Update the project.clj version and package the output jar file.
* `publish`: Publish the jar (and generated Maven metadata) to a maven repository (or clojars).
* [@saithodev/semantic-release-gitea](https://github.com/saitho/semantic-release-gitea)
* `verifyConditions`: Verify the presence and the validity of the authentication and the assets option configuration.
* `publish`: Publish a Gitea release, optionally uploading file assets.
* `addChannel`: Update a Gitea release's pre-release field.
# Shareable configuration
## Official configurations
* [@semantic-release/apm-config](https://github.com/semantic-release/apm-config) - semantic-release shareable configuration for releasing atom packages
* [@semantic-release/gitlab-config](https://github.com/semantic-release/gitlab-config) - semantic-release shareable configuration for GitLab
## Community configurations
* [@jedmao/semantic-release-npm-github-config](https://github.com/jedmao/semantic-release-npm-github-config)
* Provides an informative [git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., "chore(release): 1.2.3 \[skip ci]\n\nnotes").
* Creates a tarball that gets uploaded with each [GitHub release](https://github.com/semantic-release/github).
* Publishes the same tarball to [npm](https://github.com/semantic-release/npm).
* Commits the version change in `package.json`.
* Creates or updates a [changelog](https://github.com/semantic-release/changelog) file.
* [semantic-release-npm-github-publish](https://github.com/oleg-koval/semantic-release-npm-github-publish)
* Based on [angular preset](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular).
* Adds more keywords for the `chore` **PATCH** release.
* Generates or updates a [changelog](https://github.com/semantic-release/changelog) file including all **PATCH** keywords (not included in default angular package).
* Updates GitHub release with release-notes.
* Bumps a version in package.json.
* Publishes the new version to [NPM](https://npmjs.org).
# CI configurations
## CI configurations
* [CircleCI 2.0 workflows](https://semantic-release.gitbook.io/semantic-release/recipes/recipes/circleci-workflows)
* [Travis CI](https://semantic-release.gitbook.io/semantic-release/recipes/recipes/travis)
* [GitLab CI](https://semantic-release.gitbook.io/semantic-release/recipes/recipes/gitlab-ci)
* [GitHub Actions](https://github.com/semantic-release/semantic-release/tree/6b5b02ea755b74e1c2ea9a2dfff6576f5f15e870/docs/recipes/github-actions.md)
## Git hosted services
* [Git authentication with SSH keys](https://semantic-release.gitbook.io/semantic-release/recipes/git-hosted-services/git-auth-ssh-keys)
## Release workflow
* [Publishing on distribution channels](https://github.com/semantic-release/semantic-release/tree/6b5b02ea755b74e1c2ea9a2dfff6576f5f15e870/docs/recipes/distribution-channels.md)
* [Publishing maintenance releases](https://github.com/semantic-release/semantic-release/tree/6b5b02ea755b74e1c2ea9a2dfff6576f5f15e870/docs/recipes/maintenance-releases.md)
* [Publishing pre-releases](https://github.com/semantic-release/semantic-release/tree/6b5b02ea755b74e1c2ea9a2dfff6576f5f15e870/docs/recipes/pre-releases.md)
## Package managers and languages
# CircleCI 2.0
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured in [CircleCi Project Settings](https://circleci.com/docs/2.0/env-vars/#adding-environment-variables-in-the-app)..
Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](https://semantic-release.gitbook.io/semantic-release/usage/getting-started#getting-started).
## Multiple Node jobs configuration
### `.circleci/config.yml` configuration for multiple Node jobs
This example is a minimal configuration for **semantic-release** with a build running Node 6 and 8. See [CircleCI documentation](https://circleci.com/docs/2.0) for additional configuration options.
This example create the workflows `test_node_4`, `test_node_6`, `test_node_8` and `release`. The release workflows will [run `semantic-release` only after the all the `test_node_*` are successful](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
```yaml
version: 2
jobs:
test_node_6:
docker:
- image: circleci/node:6
steps:
# Configure your test steps here (checkout, npm install, cache management, tests etc...)
test_node_8:
docker:
- image: circleci/node:8
steps:
# Configure your test steps here (checkout, npm install, cache management, tests etc...)
release:
docker:
- image: circleci/node:8
steps:
- checkout
- run: npm install
# Run optional required steps before releasing
# - run: npm run build-script
- run: npx semantic-release
workflows:
version: 2
test_and_release:
# Run the test jobs first, then the release only when all the test jobs are successful
jobs:
- test_node_6
- test_node_8
- release:
requires:
- test_node_6
- test_node_8
```
### `package.json` configuration for multiple Node jobs
A `package.json` is required only for [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation.
```javascript
{
"devDependencies": {
"semantic-release": "^15.0.0"
}
}
```
# Travis CI
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured in [Travis Repository Settings](https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-Settings) or with the [travis env set CLI](https://github.com/travis-ci/travis.rb#env).
Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](https://semantic-release.gitbook.io/semantic-release/usage/getting-started#getting-started).
## Node.js projects configuration
### `.travis.yml` configuration for multiple Node.js jobs
This example is a minimal configuration for **semantic-release** with a build running Node 6 and 8. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification.
**Note**: It's not recommended to run the `semantic-release` command in the Travis `script` step as each script in this step will be executed regardless of the outcome of the previous one. See [travis-ci/travis-ci#1066](https://github.com/travis-ci/travis-ci/issues/1066).
**Advanced configuration**: Running the tests in the `script` step of the `release` stage is not necessary as the previous stage(s) already ran them. To increase speed, the `script` step of the `release` stage can be overwritten to skip the tests. Note that other commands such as build or compilation might still be required.
```yaml
language: node_js
node_js:
- 8
- 6
jobs:
include:
# Define the release stage that runs semantic-release
- stage: release
node_js: lts/*
# Advanced: optionally overwrite your default `script` step to skip the tests
# script: skip
deploy:
provider: script
skip_cleanup: true
script:
- npx semantic-release
```
### `package.json` configuration for multiple Node jobs
A `package.json` is required only for [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation.
```javascript
{
"devDependencies": {
"semantic-release": "^15.0.0"
}
}
```
## Non-Node.js projects configuration
For projects that require to be tested with one or multiple version of a Non-JavaScript [language](https://docs.travis-ci.com/user/languages), optionally on multiple [Operating Systems](https://docs.travis-ci.com/user/multi-os).
This recipe cover the Travis specifics only. See [Non JavaScript projects recipe](https://semantic-release.gitbook.io/semantic-release/support/faq#can-i-use-semantic-release-to-publish-non-javascript-packages) for more information on the **semantic-release** configuration.
### `.travis.yml` configuration for non-JavaScript projects
This example is a minimal configuration for **semantic-release** with a build running [Go 1.6 and 1.7](https://docs.travis-ci.com/user/languages/go). See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification.
**Note**: It's not recommended to run the `semantic-release` command in the Travis `script` step as each script in this step will be executed regardless of the outcome of the previous one. See [travis-ci/travis-ci#1066](https://github.com/travis-ci/travis-ci/issues/1066).
**Advanced configuration**: Running the tests in the `script` step of the `release` stage is not necessary as the previous stage(s) already ran them. To increase speed, the `script` step of the `release` stage can be overwritten to skip the tests. Note that other commands such as build or compilation might still be required.
```yaml
language: go
go:
- 1.6
- 1.7
jobs:
include:
# Define the release stage that runs semantic-release
- stage: release
# Advanced: optionally overwrite your default `script` step to skip the tests
# script:
# - make
deploy:
provider: script
skip_cleanup: true
script:
# Use nvm to install and use the Node LTS version (nvm is installed on all Travis images)
- nvm install lts/*
- npx semantic-release
on:
all_branches: true
```
# GitLab CI
## Environment variables
The [Authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) environment variables can be configured with [Protected variables](https://docs.gitlab.com/ce/ci/variables/README.html#protected-environment-variables).
**Note**: Make sure to configure your release branch as [protected](https://docs.gitlab.com/ce/user/project/protected_branches.html) in order for the CI/CD build to access the protected variables.
## Node project configuration
GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) allowing to test on multiple Node versions and publishing a release only when all test pass.
**Note**: The publish pipeline must run a [Node >= 10.18 version](https://semantic-release.gitbook.io/semantic-release/support/faq#why-does-semantic-release-require-node-version--1018).
### `.gitlab-ci.yml` configuration for Node projects
This example is a minimal configuration for **semantic-release** with a build running Node 6 and 8. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
**Note**: The`semantic-release` execution command varies depending if you are using a [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) or [global](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) **semantic-release** installation.
```yaml
# The release pipeline will run only if all jobs in the test pipeline are successful
stages:
- test
- release
before_script:
- npm install
node:6:
image: node:6
stage: test
script:
- npm test
node:8:
image: node:8
stage: test
script:
- npm test
publish:
image: node:8
stage: release
script:
- npx semantic-release
```
### `package.json` configuration
A `package.json` is required only for [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation.
```javascript
{
"devDependencies": {
"semantic-release": "^15.0.0"
}
}
```
# Git hosted services
# Git authentication with SSH keys
When using [environment variables](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) to set up the Git authentication, the remote Git repository will automatically be accessed via [https](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_http_protocols), independently of the [`repositoryUrl`](https://semantic-release.gitbook.io/semantic-release/usage/configuration#repositoryurl) format configured in the **semantic-release** [Configuration](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration) (the format will be automatically converted as needed).
Alternatively the Git repository can be accessed via [SSH](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_ssh_protocol) by creating SSH keys, adding the public one to your Git hosted account and making the private one available on the CI environment.
**Note:** SSH keys allow to push the [Git release tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) associated to the released version. Some plugins might also require an API token. See each plugin documentation for additional information.
## Generating the SSH keys
In your local repository root:
```bash
$ ssh-keygen -t rsa -b 4096 -C "" -f git_deploy_key -N ""
```
`your_email` must be the email associated with your Git hosted account. `ssh_passphrase` must be a long and hard to guess string. It will be used later.
This will generate a public key in `git_deploy_key.pub` and a private key in `git_deploy_key`.
## Adding the SSH public key to the Git hosted account
Step by step instructions are provided for the following Git hosted services:
* [GitHub](#adding-the-ssh-public-key-to-github)
### Adding the SSH public key to GitHub
Open the `git_deploy_key.pub` file (public key) and copy the entire content.
In GitHub **Settings**, click on **SSH and GPG keys** in the sidebar, then on the **New SSH Key** button.
Paste the entire content of `git_deploy_key.pub` file (public key) and click the **Add SSH Key** button.
Delete the `git_deploy_key.pub` file:
```bash
$ rm git_deploy_key.pub
```
See [Adding a new SSH key to your GitHub account](https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account/) for more details.
## Adding the SSH private key to the CI environment
In order to be available on the CI environment, the SSH private key must be encrypted, committed to the Git repository and decrypted by the CI service.
Step by step instructions are provided for the following environments:
* [Travis CI](#adding-the-ssh-private-key-to-travis-ci)
* [Circle CI](#adding-the-ssh-private-key-to-circle-ci)
### Adding the SSH private key to Travis CI
Install the [Travis CLI](https://github.com/travis-ci/travis.rb#installation):
```bash
$ gem install travis
```
[Login](https://github.com/travis-ci/travis.rb#login) to Travis with the CLI:
```bash
$ travis login
```
Add the [environment](https://github.com/travis-ci/travis.rb#env) variable `SSH_PASSPHRASE` to Travis with the value set during the [SSH keys generation](#generating-the-ssh-keys) step:
```bash
$ travis env set SSH_PASSPHRASE
```
[Encrypt](https://github.com/travis-ci/travis.rb#encrypt) the `git_deploy_key` (private key) using a symmetric encryption (AES-256), and store the secret in a secure environment variable in the Travis environment:
```bash
$ travis encrypt-file git_deploy_key
```
The `travis encrypt-file` will encrypt the private key into the `git_deploy_key.enc` file and output in the console the command to add to your `.travis.yml` file. It should look like `openssl aes-256-cbc -K $encrypted_KKKKKKKKKKKK_key -iv $encrypted_VVVVVVVVVVVV_iv -in git_deploy_key.enc -out git_deploy_key -d`.
Copy this command to your `.travis.yml` file in the `before_install` step. Change the output path to write the unencrypted key in `/tmp`: `-out git_deploy_key` => `/tmp/git_deploy_key`. This will avoid to commit / modify / delete the unencrypted key by mistake on the CI. Then add the commands to decrypt the ssh private key and make it available to `git`:
```yaml
before_install:
# Decrypt the git_deploy_key.enc key into /tmp/git_deploy_key
- openssl aes-256-cbc -K $encrypted_KKKKKKKKKKKK_key -iv $encrypted_VVVVVVVVVVVV_iv -in git_deploy_key.enc -out /tmp/git_deploy_key -d
# Make sure only the current user can read the private key
- chmod 600 /tmp/git_deploy_key
# Create a script to return the passphrase environment variable to ssh-add
- echo 'echo ${SSH_PASSPHRASE}' > /tmp/askpass && chmod +x /tmp/askpass
# Start the authentication agent
- eval "$(ssh-agent -s)"
# Add the key to the authentication agent
- DISPLAY=":0.0" SSH_ASKPASS="/tmp/askpass" setsid ssh-add /tmp/git_deploy_key /tmp/askpass && chmod +x /tmp/askpass
# Start the authentication agent
- eval "$(ssh-agent -s)"
# Add the key to the authentication agent
- DISPLAY=":0.0" SSH_ASKPASS="/tmp/askpass" setsid ssh-add /tmp/git_deploy_key Promise
Run **semantic-release** and returns a `Promise` that resolves to a [Result](#result) object.
#### options
Type: `Object`
**semantic-release** options.
Can be used to set any [core option](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration) or [plugin options](https://semantic-release.gitbook.io/semantic-release/usage/plugins#configuration).
Each option, will take precedence over options configured in the [configuration file](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration) and [shareable configurations](https://semantic-release.gitbook.io/semantic-release/usage/configuration#extends).
#### config
Type: `Object`
**semantic-release** configuration specific for API usage.
**cwd**
Type: `String`\
Default: `process.cwd()`
The current working directory to use. It should be configured to the root of the Git repository to release from.
It allows to run **semantic-release** from a specific path without having to change the local process `cwd` with `process.chdir()`.
**env**
Type: `Object`\
Default: `process.env`
The environment variables to use.
It allows to run **semantic-release** with specific environment variables without having to modify the local `process.env`.
**stdout**
Type: [`stream.Writable`](https://nodejs.org/api/stream.html#stream_writable_streams)\
Default: `process.stdout`
The [writable stream](https://nodejs.org/api/stream.html#stream_writable_streams) used to log information.
It allows to configure **semantic-release** to write logs to a specific stream rather than the local `process.stdout`.
**stderr**
Type: [`stream.Writable`](https://nodejs.org/api/stream.html#stream_writable_streams)\
Default: `process.stderr`
The [writable stream](https://nodejs.org/api/stream.html#stream_writable_streams) used to log errors.
It allows to configure **semantic-release** to write errors to a specific stream rather than the local `process.stderr`.
### Result
Type: `Object` `Boolean``
The list of commit included in the new release.\
Each commit object has the following properties:
| Name | Type | Description |
| --------------- | -------- | ----------------------------------------------- |
| commit | `Object` | The commit abbreviated and full hash. |
| commit.long | `String` | The commit hash. |
| commit.short | `String` | The commit abbreviated hash. |
| tree | `Object` | The commit abbreviated and full tree hash. |
| tree.long | `String` | The commit tree hash. |
| tree.short | `String` | The commit abbreviated tree hash. |
| author | `Object` | The commit author information. |
| author.name | `String` | The commit author name. |
| author.email | `String` | The commit author email. |
| author.short | `String` | The commit author date. |
| committer | `Object` | The committer information. |
| committer.name | `String` | The committer name. |
| committer.email | `String` | The committer email. |
| committer.short | `String` | The committer date. |
| subject | `String` | The commit subject. |
| body | `String` | The commit body. |
| message | `String` | The commit full message (`subject` and `body`). |
| hash | `String` | The commit hash. |
| committerDate | `String` | The committer date. |
Example:
```javascript
[
{
commit: {
long: '68eb2c4d778050b0701136ca129f837d7ed494d2',
short: '68eb2c4'
},
tree: {
long: '7ab515d12bd2cf431745511ac4ee13fed15ab578',
short: '7ab515d'
},
author: {
name: 'Me',
email: 'me@email.com',
date: 2018-07-22T20:52:44.000Z
},
committer: {
name: 'Me',
email: 'me@email.com',
date: 2018-07-22T20:52:44.000Z
},
subject: 'feat: a new feature',
body: 'Description of the new feature',
hash: '68eb2c4d778050b0701136ca129f837d7ed494d2',
message: 'feat: a new feature\n\nDescription of the new feature',
committerDate: 2018-07-22T20:52:44.000Z
}
]
```
#### nextRelease
Type: `Object`
Information related to the newly published release:
| Name | Type | Description |
| ------- | -------- | ----------------------------------------------------------------------------------------------------------------------------- |
| type | `String` | The [semver](https://semver.org) type of the release (`patch`, `minor` or `major`). |
| version | `String` | The version of the new release. |
| gitHead | `String` | The sha of the last commit being part of the new release. |
| gitTag | `String` | The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) associated with the new release. |
| notes | `String` | The release notes for the new release. |
| channel | `String` | The distribution channel on which the next release will be made available (`undefined` for the default distribution channel). |
Example:
```javascript
{
type: 'minor',
gitHead: '68eb2c4d778050b0701136ca129f837d7ed494d2',
version: '1.1.0',
gitTag: 'v1.1.0',
notes: 'Release notes for version 1.1.0...',
channel : 'next'
}
```
#### releases
Type: `Array`
The list of releases published or made available to a distribution channel.\
Each release object has the following properties:
| Name | Type | Description |
| ---------- | -------- | -------------------------------------------------------------------------------------------------------------- |
| name | `String` | **Optional.** The release name, only if set by the corresponding `publish` plugin. |
| url | `String` | **Optional.** The release URL, only if set by the corresponding `publish` plugin. |
| type | `String` | The [semver](https://semver.org) type of the release (`patch`, `minor` or `major`). |
| version | `String` | The version of the release. |
| gitHead | `String` | The sha of the last commit being part of the release. |
| gitTag | `String` | The [Git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) associated with the release. |
| notes | `String` | The release notes for the release. |
| pluginName | `String` | The name of the plugin that published the release. |
| channel | `String` | The distribution channel on which the release is available (`undefined` for the default distribution channel). |
Example:
```javascript
[
{
name: 'GitHub release',
url: 'https://github.com/me/my-package/releases/tag/v1.1.0',
type: 'minor',
gitHead: '68eb2c4d778050b0701136ca129f837d7ed494d2',
version: '1.1.0',
gitTag: 'v1.1.0',
notes: 'Release notes for version 1.1.0...',
pluginName: '@semantic-release/github'
channel: 'next'
},
{
name: 'npm package (@latest dist-tag)',
url: 'https://www.npmjs.com/package/my-package',
type: 'minor',
gitHead: '68eb2c4d778050b0701136ca129f837d7ed494d2',
version: '1.1.0',
gitTag: 'v1.1.0',
notes: 'Release notes for version 1.1.0...',
pluginName: '@semantic-release/npm'
channel: 'next'
}
]
```
# Plugin development
To create a plugin for `semantic-release`, you need to decide which parts of the release lifecycle are important to that plugin. For example, it is best to always have a `verify` step because you may be receiving inputs from a user and want to make sure they exist. A plugin can abide by any of the following lifecycles:
* `verify`
* `prepare`
* `publish`
* `success`
* `fail`
`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecyles stated above. For example, if your plugin only had a `verify` and `success` step, the `main` file for your object would need to `export` an object with `verify` and `success` functions.
In addition to the lifecycle methods, each lifecyle is passed two objects:
1. `pluginConfig` - an object containing the options that a user may pass in via their `release.config.js` file (or similar)
2. `context` - provided by `semantic-release` for access to things like `env` variables set on the running process.
For each lifecycle you create, you will want to ensure it can accept `pluginConfig` and `context` as parameters.
## Creating a Plugin Project
It is recommended that you generate a new project with `yarn init`. This will provide you with a basic node project to get started with. From there, create an `index.js` file, and make sure it is specified as the `main` in the `package.json`. We will use this file to orchestrate the lifecycle methods later on.
Next, create a `src` or `lib` folder in the root of the project. This is where we will store our logic and code for how our lifecycle methods work. Finally, create a `test` folder so you can write tests related to your logic.
We recommend you setup a linting system to ensure good javascript practices are enforced. ESLint is usually the system of choice, and the configuration can be whatever you or your team fancies.
## Exposing Lifecycle Methods
In your `index.js` file, you can start by writing the following code
```javascript
const verifyConditions = require('./src/verify');
let verified;
/**
* Called by semantic-release during the verification step
* @param {*} pluginConfig The semantic-release plugin config
* @param {*} context The context provided by semantic-release
*/
async function verify(pluginConfig, context) {
await verifyConditions(pluginConfig, context);
verified = true;
}
module.exports = { verify };
```
Then, in your `src` folder, create a file called `verify.js` and add the following
```javascript
const AggregateError = require('aggregate-error');
/**
* A method to verify that the user has given us a slack webhook url to post to
*/
module.exports = async (pluginConfig, context) => {
const { logger } = context;
const errors = [];
// Throw any errors we accumulated during the validation
if (errors.length > 0) {
throw new AggregateError(errors);
}
};
```
As of right now, this code won't do anything. However, if you were to run this plugin via `semantic-release`, it would run when the `verify` step occurred.
Following this structure, you can create different steps and checks to run through out the release process.
## Supporting Options
Let's say we want to verify that an `option` is passed. An `option` is a configuration object that is specific to your plugin. For example, the user may set an `option` in their release config like:
```javascript
{
prepare: {
path: "@semantic-release/my-special-plugin"
message: "My cool release message"
}
}
```
This `message` option will be passed to the `pluginConfig` object mentioned earlier. We can use the validation method we created to verify this option exists so we can perform logic based on that knowledge. In our `verify` file, we can add the following:
```javascript
const { message } = pluginConfig;
if (message.length) {
//...
}
```
## Supporting Environment Variables
Similar to `options`, environment variables exist to allow users to pass tokens and set special URLs. These are set on the `context` object instead of the `pluginConfig` object. Let's say we wanted to check for `GITHUB_TOKEN` in the environment because we want to post to GitHub on the user's behalf. To do this, we can add the following to our `verify` command:
```javascript
const { env } = context;
if (env.GITHUB_TOKEN) {
//...
}
```
# Shareable configuration development
# Resources
## Videos
* ["Introducing Reliable Dependency and Release Management for npm Packages" - Gregor Martynus](https://www.youtube.com/watch?v=R2RJWLcfzwc)
* ["Kill all humans" - Jan Lehnardt](https://www.youtube.com/watch?v=ZXyx_1kN1L8\&t=2s)
* ["Publishing JavaScript Packages" - JavaScript Air](https://javascriptair.com/episodes/2016-07-20)
* ["Managing Dependencies like a boss đ" - JavaScript Air](https://javascriptair.com/episodes/2016-08-17)
* ["Dependency Hell Just Froze Over" - Stephan Bönnemann](https://www.youtube.com/watch?v=PA139CERNbc)
* ["semantic-release Q\&A with Kent C. Dodds"](https://www.youtube.com/watch?v=g6y3DnhkjrI)
* ["We fail to follow SemVer â and why it neednât matter" - Stephan Bönnemann](https://www.youtube.com/watch?v=tc2UgG5L7WM)
## Articles
* ["Introduction to SemVer" - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2)
* ["Introduction to Semantic Release" - liv](https://blog.greenkeeper.io/introduction-to-semantic-release-33f73b117c8)
## Tutorials
* ["How to Write a JavaScript Library - Automating Releases with semantic-release" â egghead.io](https://egghead.io/lessons/javascript-automating-releases-with-semantic-release)
# Frequently Asked Questions
## Why is the `package.json`âs version not updated in my repository?
**semantic-release** takes care of updating the `package.json`âs version before publishing to [npm](https://www.npmjs.com).
By default, only the published package will contain the version, which is the only place where it is *really* required, but the updated `package.json` will not be pushed to the Git repository
However, the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin can be used to push the updated `package.json` as well as other files to the Git repository.
## How can I use a npm build script that requires the `package.json`âs version ?
The `package.json`âs version will be updated by the `semantic-release` command just before publishing to [npm](https://www.npmjs.com), therefore it won't be available for scripts ran before the `semantic-release` command.
As the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin uses the [npm CLI](https://docs.npmjs.com/cli/npm) to update the `package.json` version and publish the package, all [npm hook scripts](https://docs.npmjs.com/misc/scripts#description) will be executed.
You can run your build script in:
* the `prepublishOnly` or `prepack` hook so it will be executed during the `publish` step of `@semantic-release/npm`
* the `postversion` hook so it will be executed during the `prepare` step of `@semantic-release/npm`, which allow for example to update files before committing them with the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin
If using npm hook scripts is not possible, and alternative solution is to [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to run your script in the `prepare` step:
```javascript
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/npm",
["@semantic-release/exec", {
"prepareCmd": "./my-build-script.sh ${nextRelease.version}",
}],
]
}
```
## Is there a way to preview which version would currently get published?
Yes with the [dry-run options](https://semantic-release.gitbook.io/semantic-release/usage/configuration#dryrun) which prints to the console the next version to be published and the release notes.
## Can I use semantic-release with Yarn?
If you are using a [local](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) **semantic-release** installation and run multiple CI jobs with different versions, the `yarn install` command will fail on jobs running with Node < 8 as **semantic-release** requires [Node >= 10.18](#why-does-semantic-release-require-node-version--1018) and specifies it in its `package.json`s [`engines`](https://docs.npmjs.com/files/package.json#engines) key.
The recommended solution is to use the [Yarn](https://yarnpkg.com) [--ignore-engines](https://yarnpkg.com/en/docs/cli/install#toc-yarn-install-ignore-engines) option to install the project dependencies on the CI environment, so Yarn will ignore the **semantic-release**'s `engines` key:
```bash
$ yarn install --ignore-engines
```
**Note**: Several CI services use Yarn by default if your repository contains a `yarn.lock` file. So you should override the install step to specify `yarn install --ignore-engines`.
Alternatively you can use a [global](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) **semantic-release** installation and make sure to install and run the `semantic-release` command only in a CI jobs running with Node >= 10.18.
If your CI environment provides [nvm](https://github.com/creationix/nvm) you can switch to Node 8 before installing and running the `semantic-release` command:
```bash
$ nvm install 8 && yarn global add semantic-release && semantic-release
```
See the [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details on specific CI environments.
As `semantic-release` is recommended to be executed with [`npx`](https://www.npmjs.com/package/npx) an alternative is required for usage with Yarn. Even though it is possible to install npx with Yarn, it's not recommended. Yarn and npx would be using different cache locations.
For [local installation](https://semantic-release.gitbook.io/semantic-release/usage/installation#local-installation) replace `npx semantic-release` with `yarn run semantic-release`.
For [global installation](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) replace `npx semantic-release` with `yarn global add semantic-release && semantic-release`.
## Can I use semantic-release to publish non-JavaScript packages?
Yes, **semantic-release** is a Node CLI application but it can be used to publish any type of packages.
To publish a non-Node package (without a `package.json`) you would need to:
* Use a [global](https://semantic-release.gitbook.io/semantic-release/usage/installation#global-installation) **semantic-release** installation
* Set **semantic-release** [options](https://semantic-release.gitbook.io/semantic-release/usage/configuration#options) via [CLI arguments or rc file](https://semantic-release.gitbook.io/semantic-release/usage/configuration#configuration)
* Make sure your CI job executing the `semantic-release` command has access to [Node >= 10.18](#why-does-semantic-release-require-node-version--1018) to execute the `semantic-release` command
See the [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details on specific CI environments.
In addition you will need to configure the **semantic-release** [plugins](https://semantic-release.gitbook.io/semantic-release/usage/plugins#plugins) to disable the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin which is used by default and use a plugin for your project type.
If there is no specific plugin for your project type you can use the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to publish the release with a shell command.
Here is a basic example to create [GitHub releases](https://help.github.com/articles/about-releases) and use a shell command to publish:
```javascript
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/github",
["@semantic-release/exec", {
"prepareCmd" : "set-version ${nextRelease.version}",
"publishCmd" : "publish-package"
}]
]
}
```
**Note**: This is a theoretical example where the command `set-version` update the project version with the value passed as its first argument and `publish-package` publishes the package to a registry.
See the [package managers and languages recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#package-managers-and-languages) for more details on specific project types.
## Can I use semantic-release with any CI service?
Yes, **semantic-release** can be used with any CI service, as long as it provides:
* A way to set [authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) via environment variables
* A way to guarantee that the `semantic-release` command is [executed only after all the tests of all the jobs in the CI build pass](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded)
See the [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details on specific CI environments.
## Can I run semantic-release on my local machine rather than on a CI server?
Yes, you can by explicitly setting the [`--no-ci` CLI option](https://semantic-release.gitbook.io/semantic-release/usage/configuration#ci) option. You will also have to set the required [authentication](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#authentication) via environment variables on your local machine, for example:
```bash
$ NPM_TOKEN= GH_TOKEN= npx semantic-release --no-ci
```
However this is not the recommended approach, as running unit and integration tests on an independent machine before publishing software is a crucial part of the release workflow.
## Can I use semantic-release with GitLab?
Yes, with the [`@semantic-release/gitlab-config`](https://github.com/semantic-release/gitlab-config) shareable configuration.
See the [GitLab CI recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes/gitlab-ci#using-semantic-release-with-gitlab-ci) for the CI configuration.
## Can I use semantic-release with any Git hosted environment?
By default **semantic-release** uses the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin to publish a [GitHub release](https://help.github.com/articles/about-releases). For other Git hosted environment the [`@semantic-release/git`](https://github.com/semantic-release/git) and [`@semantic-release/changelog`](https://github.com/semantic-release/changelog) plugins can be used via [plugins configuration](https://semantic-release.gitbook.io/semantic-release/usage/plugins).
See the [`@semantic-release/git`](https://github.com/semantic-release/git#semantic-releasegit) [`@semantic-release/changelog`](https://github.com/semantic-release/changelog#semantic-releasechangelog) plugins documentation for more details.
## Can I skip the release to the npm registry?
Yes, the publishing to the npm registry can be disabled with the [`npmPublish`](https://github.com/semantic-release/npm#options) option of the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. In addition the [`tarballDir`](https://github.com/semantic-release/npm#options) option allow to generate the package tarball in order to publish it to your repository with the [`@semantic-release/git`](https://github.com/semantic-release/git) or to a [GitHub release](https://help.github.com/articles/about-releases) with the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin.
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#semantic-releasenpm) plugin documentation for more details.
## How can I revert a release?
If you have introduced a breaking bug in a release you have 2 options:
* If you have a fix immediately ready, commit and push it (or merge it via a pull request) to the release branch
* Otherwise, [revert the commit](https://git-scm.com/docs/git-revert) that introduced the bug and push the revert commit (or merge it via a pull request) to the release branch
In both cases **semantic-release** will publish a new release, so your package users will get the fixed/reverted version.
Depending on the package manager you are using, you might be able to un-publish or deprecate a release, in order to prevent users from downloading it by accident. For example, npm allows you to [un-publish](https://docs.npmjs.com/cli/unpublish) [within 72 hours](https://www.npmjs.com/policies/unpublish) after release. You may also [deprecate](https://docs.npmjs.com/cli/deprecate) a release if you would rather avoid un-publishing.
In any case **do not remove the Git tag associated with the buggy version**, otherwise **semantic-release** will later try to republish that version. Publishing a version after un-publishing is not supported by most package managers.
**Note**: If you are using the default [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) be aware that it uses a different revert commit format than the standard one created by [git revert](https://git-scm.com/docs/git-revert), contrary to what is [claimed in the convention](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#revert). Therefore, if you revert a commit with [`git revert`](https://git-scm.com/docs/git-revert), use the [`--edit` option](https://git-scm.com/docs/git-revert#git-revert---edit) to format the message according to the [Angular revert commit message format](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#revert). See [conventional-changelog/conventional-changelog#348](https://github.com/conventional-changelog/conventional-changelog/issues/348) for more details.
## Can I use `.npmrc` options?
Yes, all the [npm configuration options](https://docs.npmjs.com/misc/config) are supported via the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository.
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
## How can I set the access level of the published npm package?
The [npm `access` option](https://docs.npmjs.com/misc/config#access) can be set in the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository:
```
access=public
```
Or with the `publishConfig.access` key in your project's `package.json`:
```javascript
{
"publishConfig": {
"access": "public"
}
}
```
## Can I use semantic-release to publish a package on Artifactory?
Any npm compatible registry is supported with the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. For Artifactory versions prior to 5.4, the legacy authentication has to be used (with `NPM_USERNAME`, `NPM_PASSWORD` and `NPM_EMAIL` [environment variables](https://github.com/semantic-release/npm#environment-variables)).
See [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) for more details.
See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactiry configuration.
## Can I manually trigger the release of a specific version?
You can trigger a release by pushing to your Git repository. You deliberately cannot trigger a *specific* version release, because this is the whole point of semantic-release.
## Can I exclude commits from the analysis?
Yes, every commits that contains `[skip release]` or `[release skip]` in their message will be excluded from the commit analysis and won't participate in the release type determination.
## How can I change the type of commits that trigger a release?
By default **semantic-release** uses the [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) and triggers releases based on the following rules:
| Commit | Release type |
| --------------------------- | -------------------------- |
| Commit with breaking change | ~~Major~~ Breaking release |
| Commit with type `feat` | ~~Minor~~ Feature release |
| Commit with type `fix` | Patch release |
| Commit with type `perf` | Patch release |
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
This is fully customizable with the [`@semantic-release/commit-analyzer`](https://github.com/semantic-release/commit-analyzer) plugin's [`release-rules` option](https://github.com/semantic-release/commit-analyzer#release-rules).
## Is it *really* a good idea to release on every push?
It is indeed a great idea because it *forces* you to follow best practices. If you donât feel comfortable releasing every feature or fix on your `master` you might not treat your `master` branch as intended.
From [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/index.html):
> Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable.
If you need more control over the timing of releases, see [Triggering a release](https://semantic-release.gitbook.io/semantic-release/undefined#triggering-a-release) for different options.
**Note**: Only the codebase changes altering the published package will trigger a release (for example new features, bug fixes or performance improvements would trigger a release while refactoring or changing code style would not). See [How can I change the type of commits that trigger a release?](#how-can-i-change-the-type-of-commits-that-trigger-a-release) for more details.
## Can I set the initial release version of my package to `0.0.1`?
This is not supported by **semantic-release** as it's not considered a good practice, mostly because [Semantic Versioning](https://semver.org) rules applies differently to major version zero.
If your project is under heavy development, with frequent breaking changes, and is not production ready yet we recommend [publishing pre-releases](https://github.com/semantic-release/semantic-release/tree/55be0ba2b1d8a5f7d817f0d4567be04170580028/docs/recipes/pre-releases.md#publishing-pre-releases).
See [âIntroduction to SemVerâ - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) for more details on [Semantic Versioning](https://semver.org) and the recommendation to start at version `1.0.0`.
## Can I trust semantic-release with my releases?
**semantic-release** has a full unit and integration test suite that tests `npm` publishes against the [npm-registry-couchapp](https://github.com/npm/npm-registry-couchapp).
In addition the [verify conditions step](https://semantic-release.gitbook.io/semantic-release/undefined#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
## Why does semantic-release require Node version >= 10.18?
**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 10.18 or higher**.
See [Node version requirement](https://semantic-release.gitbook.io/semantic-release/node-version#node-version-requirement) for more details and solutions.
## Why does semantic-release require Git version >= 2.7.1?
**semantic-release** uses Git CLI commands to read information about the repository such as branches, commit history and tags. Certain commands and options (such as [the `--merged` option of the `git tag` command](https://git-scm.com/docs/git-tag/2.7.0#git-tag---no-mergedltcommitgt) or bug fixes related to `git ls-files`) used by **semantic-release** are only available in Git version 2.7.1 and higher.
## What is npx?
[`npx`](https://www.npmjs.com/package/npx) â short for "npm exec" â is a CLI to find and execute npm binaries within the local `node_modules` folder or in the $PATH. If a binary can't be located npx will download the required package and execute it from its cache location. The tool is bundled with [npm](https://www.npmjs.com/package/npm) >= 5.2, or can be installed via `npm install -g npx`. For more details and motivation read the [introductory blog post](https://medium.com/@maybekatz/introducing-npx-an-npm-package-runner-55f7d4bd282b) by [@zkat](https://github.com/zkat).
# Troubleshooting
## You do not have permission to publish 'package-name'
When running semantic-release you might encounter the following error:
```bash
npm ERR! publish Failed PUT 403
npm ERR! code E403
npm ERR! You do not have permission to publish "". Are you logged in as the correct user? :
```
This is most likely related to a misconfiguration of the [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) or to your user [missing permission](https://docs.npmjs.com/cli/team) for publishing.
It might also happen if the package name you are trying to publish already exists (in the case of npm, you may be trying to publish a new version of a package that is not yours, hence the permission error).
To verify if your package name is available you can use [npm-name-cli](https://github.com/sindresorhus/npm-name-cli):
```bash
$ npm install --global npm-name-cli
$ npm-name
```
If the package name is not available, change it in your `package.json` or consider using an [npm scope](https://docs.npmjs.com/misc/scope).
## Squashed commits are ignored by **semantic-release**
**semantic-release** parses commits according to a [commit message convention](https://github.com/semantic-release/semantic-release#commit-message-format) to figure out how they affect the codebase. Commits that doesn't follow the project's commit message convention are simply ignored.
When [squashing commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) most Git tools will by default generate a new commit message with a summary of the squashed commits. This commit message will most likely not be compliant with the project's commit message convention and therefore will be ignored by **semantic-release**.
When squashing commits make sure to rewrite the resulting commit message to be compliant with the project's commit message convention.
**Note**: if the resulting squashed commit would encompasses multiple changes (for example multiple unrelated features or fixes) then it's probably not a good idea to squash those commits together. A commit should contain exactly one self-contained functional change and a functional change should be contained in exactly one commit. See [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit).
## `reference already exists` error when pushing tag
**semantic-release** read [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) that are present in the history of your release branch in order to determine the last release published. Then it determines the next version to release based on the commits pushed since then and create the corresponding tag. If a tag with the name already in your repository, Git will throw and error as tags must be unique across the repository. This situation happens when you have a version tag identical to the new one **semantic-release** is trying to create that is not in the history of the current branch.
If an actual release with that version number was published you need to merge all the commits up to that release into your release branch.
If there is no published release with that version number, the tag must be deleted.
```bash
# Verify if the commit exists in the repository
$ git rev-list -1
# If a commit sha is returned, then the tag exists
# Verify the branches having the tagged commit in their history
$ git branch --contains
# Delete the tag
$ git tag -d
$ git push origin :refs/tags/
```
## release not found release branch after `git push --force`
**semantic-release** is using both [git tags](https://git-scm.com/docs/git-tag) and [git notes](https://git-scm.com/docs/git-notes) to store information about which releases happened in which branch.
After a git history rewrite due to a `git push --force`, the git tags and notes referencing the commits that were rewritten are lost.
To recover from that situation, do the following:
1. Delete the tag(s) for the release(s) that have been lost from the git history. You can delete each tag from remote using `git push origin :[TAG NAME]`, e.g. `git push origin :v2.0.0-beta.1`. You can delete tags locally using `git tag -d [TAG NAME]`, e.g. `git tag -d v2.0.0-beta.1`.
2. Re-create the tags locally: `git tag [TAG NAME] [COMMIT HASH]`, where `[COMMIT HASH]` is the new commit that created the release for the lost tag. E.g. `git tag v2.0.0-beta.1 abcdef0`
3. Re-create the git notes for each release tag, e.g. `git notes --ref semantic-release add -f -m '{"channels":["beta"]}' v3.0.0-beta.1`. If the release was also published in the default channel (usually `master`), then set the first channel to `null`, e.g. \`git notes --ref semantic-release add -f -m '{"channels":\[null, "beta"]}'
4. Push the local notes: `git push --force origin refs/notes/semantic-release`. The `--force` is needed after the rebase. Be careful.
# Node version requirement
**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which requires **requires Node version 10 or higher**.
**semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency. Therefore the only constraint is to run the `semantic-release` in a CI environment providing Node 8 or higher.
See our [Node Support Policy](https://semantic-release.gitbook.io/semantic-release/support/node-support-policy) for our long-term promise regarding Node version support.
## Recommended solution
### Run at least one CI job with Node >= 10.18
The recommended approach is to run the `semantic-release` command from a CI job running on Node 10.18 or higher. This can either be a job used by your project to test on Node >= 10.18 or a dedicated job for the release steps.
See [CI configuration](https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration) and [CI configuration recipes](https://semantic-release.gitbook.io/semantic-release/recipes/recipes#ci-configurations) for more details.
## Alternative solutions
### Use `npx`
`npx` is included with npm >= 5.2 and can be used to download the latest [Node 8 package published on npm](https://www.npmjs.com/package/node). Use it to execute the `semantic-release` command.
```bash
$ npx -p node@8 -c "npx semantic-release"
```
**Note:**: See [What is npx](https://semantic-release.gitbook.io/semantic-release/faq#what-is-npx) for more details.
### Use `nvm`
If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to Node 8 before running the `semantic-release` command.
```bash
$ nvm install 8 && npx semantic-release
```
# Node Support Policy
We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 8.9.0 (LTS)](https://nodejs.org/en/blog/release/v8.9.0).
We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment.
It's possible this package will work correctly on newer versions of Node. It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support.
As each Node LTS version reaches its end-of-life we will remove that version from the node engines property of our package's package.json file. Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package. We will not accept any requests to support an end-of-life version of Node. Any merge requests or issues supporting an end-of-life version of Node will be closed.
We will accept code that allows this package to run on newer, non-LTS, versions of Node. Furthermore, we will attempt to ensure our own changes work on the latest version of Node. To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current.
JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property. If you encounter issues installing this package, please report the issue to your package manager.