CI Configuration
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. This can be achieved with Travis Build Stages, CircleCI Workflows, Codeship Deployment Pipelines, GitLab Pipelines, Codefresh Pipelines, Wercker Workflows or GoCD Pipelines.
See CI configuration recipes for more details.
semantic-release requires push access to the project Git repository in order to create Git tags. The Git authentication can be set with one of the following environment variables:
Variable | Description |
| A GitHub personal access token. |
| A GitLab personal access token. |
| A Bitbucket personal access token. |
| URL encoded Git username and password in the format |
Alternatively the Git authentication can be set up via SSH keys.
Most semantic-release plugins require setting up authentication in order to publish to a package manager registry. The default @semantic-release/npm and @semantic-release/github plugins require the following environment variables:
Variable | Description |
| npm token created via npm token create.
Note: Only the |
| GitHub authentication token. Note: Only the personal token authentication is supported. |
See each plugin documentation for the environment variables to set up.
The authentication token/credentials have to be made available in the CI service via environment variables.
See CI configuration recipes for more details on how to configure environment variables in your CI service.