GitLab CI template for semantic-release

This project implements a GitLab CI/CD template to automate your versionning and release management with semantic-release, supporting one or several of the following features:

• determine the next release version number,
• generate the changelog,
• commit any changed resource to the Git repository,
• create and push the Git tag,
• publish the packages (in GitLab or any other package repository of your choice),
• any additional custom behavior you are able to script, triggered on the release steps.

Usage

In order to include this template in your project, add the following to your gitlab-ci.yml:

include:
  - project: 'to-be-continuous/semantic-release'
    ref: '3.2.2'
    file: '/templates/gitlab-ci-semrel.yml'

Global configuration

The semantic-release template uses some global configuration used throughout all jobs.

Jobs will extract required plugin packages from discovered configuration. If your configuration needs additional packages, add them, one per line, to SEMREL_REQUIRED_PLUGINS_FILE file. Each line must be a valid npm install package argument.

Jobs

semantic-release job

This job runs semantic-release in ci mode.

⚠️ This template supports all semantic-release configuration files except for release.config.js and custom CLI arguments.

If no configuration is found, the template will generate one with the following options:

• debug: true if the $TRACE variable is set, false otherwise
• dryRun: true if the $SEMREL_DRY_RUN variable is set, false otherwise
• tagFormat: see $SEMREL_TAG_FORMAT variable
• plugins:
  • @semantic-release/commit-analyzer
  • @semantic-release/release-notes-generator
  • @semantic-release/gitlab
  • @semantic-release/git
  • optional @semantic-release/changelog if SEMREL_CHANGELOG_ENABLED is set to true
  • optional @semantic-release/exec if any hook script is found (see hook scripts)
• branches: master

Variables

As specified in the previous chapter, these variables are only used to generated a .releaserc when no configuration is found in the repository.

Hook scripts

The generated .releaserc will include the @semantic-release/exec plugin if any of the following scripts is found in the $SEMREL_HOOKS_DIR folder:

verify-conditions.sh

See exec verifyConditionsCmd.

Parameters: none

verify-release.sh

See exec verifyReleaseCmd.

Parameters:

1. Last release version
2. next release version
3. next release type

prepare.sh

See exec prepareCmd.

Parameters:

1. Last release version
2. next release version
3. next release type

publish.sh

See exec publishCmd.

Parameters:

1. Last release version
2. next release version
3. release branch
4. commits count
5. current date

success.sh

See exec successCmd.

Parameters:

1. Last release version
2. next release version

fail.sh

See exec failcmd.

Parameters:

1. Last release version
2. next release version

Signing release commits with GPG

For an introduction on commit signing, see GitLab documentation.

To make semantic-release sign its commits, use the following variable.

semantic-release-info job

This job (disabled by default) runs semantic-release with dry-run mode in .pre stage to save the following variables as dotenv artifact making them available for the next pipeline stages:

• SEMREL_INFO_LAST_VERSION: latest released version
• SEMREL_INFO_NEXT_VERSION: next release version (based on actual commits and comments)
• SEMREL_INFO_NEXT_VERSION_TYPE: next release type (major|minor|patch)

⚠️ SEMREL_INFO_NEXT_VERSION and SEMREL_INFO_NEXT_VERSION_TYPE wont be available when semantic-release commits analysis determine that no release will be performed.

This job can be enabled by defining the SEMREL_INFO_ON variable:

• prod to enable on production branch only (master by default)
• protected to enable on protected references
• all to enable on all Git references. ⚠️ Beware that this job requires the GITLAB_TOKEN variable so you must unprotect it (this will make privilege escalation possible from developer to maintainer).

Secrets management

Here are some advices about your secrets (variables marked with a 🔒):

1. Manage them as project or group CI/CD variables:
   • masked to prevent them from being inadvertently displayed in your job logs,
   • protected if you want to secure some secrets you don't want everyone in the project to have access to (for instance production secrets).
2. In case a secret contains characters that prevent it from being masked, simply define its value as the Base64 encoded value prefixed with @b64@: it will then be possible to mask it and the template will automatically decode it prior to using it.
3. Don't forget to escape special characters (ex: $ -> $$).