semantic-release
AboutGitHubNeed Help?
next
next
  • Introduction
  • Usage
    • Getting started
    • Installation
    • CI Configuration
    • Configuration
    • Plugins
    • Workflow configuration
    • Shareable configurations
  • Extending
    • Plugins
    • Shareable configuration
  • Recipes
    • CI configurations
      • CircleCI 2.0
      • Travis CI
      • GitLab CI
    • Git hosted services
      • Git authentication with SSH keys
    • Package managers and languages
  • Developer guide
    • JavaScript API
    • Plugin development
    • Shareable configuration development
  • Support
    • Resources
    • Frequently Asked Questions
    • Troubleshooting
    • Node version requirement
    • Node Support Policy
Powered by GitBook
On this page
  • Run semantic-release only after all tests succeeded
  • Authentication
  • Push access to the remote repository
  • Authentication for plugins
Edit on Git
  1. Usage

CI Configuration

PreviousInstallationNextConfiguration

Last updated 5 years ago

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:

  • .

See for more details.

Authentication

Push access to the remote repository

semantic-release requires push access to the project Git repository in order to create . 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

GIT_CREDENTIALS

Authentication for plugins

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.

A GitHub .

A GitLab .

A Bitbucket .

Git username and password in the format <username>:<password>. The username and password must each be individually URL encoded, not the : separating them.

Alternatively the Git authentication can be set up via .

Most semantic-release require setting up authentication in order to publish to a package manager registry. The default and plugins require the following environment variables:

npm token created via . Note: Only the auth-only is supported.

GitHub authentication token. Note: Only the authentication is supported.

See 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 and .

SSH keys
plugins
@semantic-release/npm
@semantic-release/github
@semantic-release/github
@semantic-release/gitlab
personal access token
personal access token
personal access token
URL encoded
npm token create
level of npm two-factor authentication
personal token
Travis Build Stages
CircleCI Workflows
GitHub Actions
Codeship Deployment Pipelines
GitLab Pipelines
Codefresh Pipelines
Wercker Workflows
GoCD Pipelines
Git tags
CI configuration recipes
CI configuration recipes