Each new commit with a message in the format of Conventional Commits triggers a new minor, major or patch release based on rules of the commit analyzer.

The component also adds a merge request validation job that checks Conventional Commits before the release pipeline runs. For squash merges it validates the merge request title, including draft titles with Draft:, WIP:, [Draft], or [WIP] prefixes. For no-squash merges it checks that at least one merge request commit subject is a Conventional Commit. The default pattern follows the Conventional Commits 1.0.0 shape for known semantic-release types:

<feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert>[optional scope][optional !]: <description>

Use ! before the colon or a BREAKING CHANGE: footer for breaking changes. Projects can set validate-enabled: false when this validation is not wanted, override validate-pattern for stricter local conventions, set validate-allow-failure when the validation should be advisory, and override validate-rules when validation must run in another merge request pipeline context such as a child pipeline.

This component will also set the regex ([0-9]+\.[0-9]+\.[0-9]+(-hotfix\.[0-9]+)?|latest|main) as the default for the cleanup policy of the container registry.

Bugs

CI_JOB_TOKEN

Variables

Name	required	Hints
GITLAB_TOKEN	no	Access token of a service account fallback to `CI_JOB_TOKEN` with limitations

Access Token Permissions and Security

[!WARNING] Checklist:

Group or project access token has role Maintainer
Group or project access token has permission api to write to the API.
Protected branches are set like main
Protected tags are set with * permissions for Maintainer

[!NOTE] Protected branches and tags are required to prevent manual releases by developers to the main branch. This ensures that all changes go through the CI pipeline and are properly released.

[!NOTE] If the pipeline releases a components catalog in a private or internal repository, you will see tagged pipelines not being triggered.

Take one of the following options for this project:

Create a service account with a personal access token. Group service accounts might be unavailable to maintainers of a group.
Make the components project public. This is the easiest option, but it may not be suitable for all organizations.
Use your personal access token.

[!NOTE] Ask an internal GitLab administrator to uncheck the external user checkbox for the service account, if you want the use the service account to also access internal resources like the bash library.

Usage

Ensure your projects have a description
Set GITLAB_TOKEN as a masked, protected and hidden variable for your group
Protect your main branch
Create GitLab pipeline file .gitlab-ci.yml:

include:
- component: $CI_SERVER_FQDN/xrow-public/ci-tools/common@stable
- component: $CI_SERVER_FQDN/xrow-public/ci-tools/workflow@stable
- component: $CI_SERVER_FQDN/xrow-public/ci-tools/semantic-release@stable

Use validation inputs when a project needs a local convention:

include:
- component: $CI_SERVER_FQDN/xrow-public/ci-tools/semantic-release@stable
  inputs:
    validate-enabled: true
    validate-pattern: '^(feat|fix|docs|chore)(\([[:alnum:]_.\/-]+\))?!?: .+$'
    validate-allow-failure: false
    validate-rules:
      - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
        when: on_success
      - when: never

Create a new commit with a formatted message:

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Inputs

Name	Description	Default	Type
---	---	---	---
changelog-path		docs/CHANGELOG.md	string
config-file	The contents of the semantic release configuration file, if none exists.	{ "branches": [ "main" ], "tagFormat": "$${version}", "plugins": [ [ "@semantic-release/commit-analyzer", { "preset": "conventionalcommits" } ], "@semantic-release/release-notes-generator", [ "@semantic-release/changelog", { "changelogFile": "${CI_SEMANTIC_RELEASE_CHANGELOG}" } ], [ "@semantic-release/gitlab", {} ], [ "@semantic-release/exec", { "successCmd": "mkdir -p $CI_PROJECT_DIR/release \\|\\| true; echo \"${nextRelease.version}\" > \"$CI_PROJECT_DIR/release/version\"" } ] ] }	string
config-file-path	The path to the semantic release configuration file.	.releaserc.json	string
options	Additional options for the semantic release job.	--debug	string
rules	The rules that this job depends on.	[{"if":"$CI_PIPELINE_SOURCE == \"schedule\"","when":"never"},{"if":"$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH","when":"on_success"},{"when":"never"}]	array
stage		.post	string
validate-allow-failure	Should the pipeline continue if conventional commit validation fails?	false	boolean
validate-enabled	Enable merge request validation of conventional commit subjects.	true	boolean
validate-pattern	The extended regular expression used to validate conventional commit subjects.	^(feat\\|fix\\|docs\\|style\\|refactor\\|perf\\|test\\|build\\|ci\\|chore\\|revert)($[[:alnum:]_.\/-]+$)?!?: .+$	string
validate-rules	Rules controlling when conventional commit validation runs.	[{"if":"$CI_PIPELINE_SOURCE == \"merge_request_event\"","when":"on_success"},{"when":"never"}]	array

Variables​

Access Token Permissions and Security​

Usage​

Inputs​

Variables

Access Token Permissions and Security

Usage

Inputs