Semantic release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification.
Also with the addition of commit validation with commitllint in order to avoid wrong commit messages.
You can check my repo commitlint-usage to see several ways of commitlint usage.
- 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:
GL_TOKENorGITLAB_TOKENA GitLab personal access token - Run semantic-release only after all tests succeeded.
- Configure gitlab pipelines taking as an example the .gitlab-ci.yml file.
@semantic-release/changelogand@semantic-release/gitplugins are required to record changes in a file CHANGELOG.md- Configure semantic release taking as an example the .releaserc.js file.
Everything is taken based on the sources mentioned at the bottom of this page except the custom configuration to get the version before creating it in order to use when tagging images with the same version of the tag to be created.
In this project I just log the version to keep it simple echo "Version -> $(cat version)" you can use it for something else or skip the execution of sem-rel in dry-run in case you don't need it.
- Create a GitHub Personal Access Token with the following permissions: repo, read:org, user:email, write:repo_hook
- Add token to repo secrets as
SEMANTIC_RELEASE_GH_TOKEN - Run semantic-release only after all tests succeeded.
- Configure github actions taking as an example the workflow.yml file.
@semantic-release/changelogand@semantic-release/gitplugins are required to record changes in a file CHANGELOG.md- Configure semantic release taking as an example the .releaserc.js file.