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:

See CI configuration recipes 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. The Git authentication can be set with one of the following environment variables:

Variable
Description

GH_TOKEN or GITHUB_TOKEN

GL_TOKEN or GITLAB_TOKEN

BB_TOKEN or BITBUCKET_TOKEN

BB_TOKEN_BASIC_AUTH or BITBUCKET_TOKEN_BASIC_AUTH

GIT_CREDENTIALS

Alternatively the Git authentication can be set up via SSH keys.

Authentication for plugins

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

GH_TOKEN

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 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 and @semantic-release/gitlab.

Last updated