Replace this template with your information
The main reason I want to do is, I’d like to manage the release tags when doing the deployment. I only find some samples with bash scripts, which looks ugly.
image: ubuntu:focal
stages:
- tag
before_script:
- DEBIAN_FRONTEND=noninteractive apt-get update
- DEBIAN_FRONTEND=noninteractive apt-get -y install php php-json git openssh-client curl
Tag Release:
stage: tag
only:
- master
script:
- VERSION="$(php -r "echo json_decode(file_get_contents('./composer.json'), true)['version'];")";
- MESSAGE="$(php -r "echo json_encode(['name' => 'Version $VERSION', 'tag_name' => '$VERSION', 'description' => file_get_contents('./changelog/$VERSION.md')]);")";
- git config --global user.email "your_email"
- git config --global user.name "username"
- git remote add api-origin https://oauth2:${OAUTH2_TOKEN}@gitlab.com/PROJECT_PATH
- >
if [ $(git tag -l "$VERSION") ]; then
echo "Version $VERSION already exists"
else
git tag -a $VERSION -m "Version $VERSION"
git push api-origin $VERSION
curl --header 'Content-Type: application/json' --header "PRIVATE-TOKEN: $OAUTH2_TOKEN" \
--data "$MESSAGE" \
--request POST https://gitlab.com/api/v4/projects/PROJECT_PATH/releases
fi
But in Gitlab Action, it is easy and neat
name: Bump version
on:
push:
branches:
- master
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
- name: Bump version and push tag
uses: hennejg/github-tag-action@v4.1.jh1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
Are there any similar features in Gitlab? I did search, but don’t see anything close to this feature.
looks promise, let me test it.
@dnsmichi
I tried the release feature in Gitlab. Here is my udnerstanding.
The release feature is only take crae of the release itself. It uses gitlab variable CI_PIPELINE_IID
as tag name, CI_PIPELINE_IID is the pipeline job id, which is not suitable. For example, if my pipeline job is 1000, it will be 0.1000, not that good.
Are there any processes to create tags following sementic versioning? only have proper tag name, then I can use that release feature.
In github action, the release task will take care of the tagging:
For example, the latest tag is 0.2.1
- if default is minor, next tag would be 0.3.0
- if mark as beta, it will be 0.3.0-beta.1
3, or others, follow with Semantic Versioning 2.0.0 (https://semver.org/)
Thanks for adding more context. $CI_PIPELINE_IID
is a predefined CI/CD variable, you can use others such as CI_COMMIT_TAG
or CI_COMMIT_REF_NAME
to customize the release name/tag and description. An example is in Automation of releases with gitlab CI - Pavel Tishkov - Medium
An if-then-else workflow will need customization based on an (inline) shell script, or any other method which for example wraps the release-cli binary, passing in all required parameters. I’ve inspected the actions source, it reads as different conditions and actions to ensure that a version is bumped automatically based on a specific commit history or push on the main branch.
Started a research, as I am not familiar with automated tagging (I do manual tagging in my projects). A similar approach is implemented in Java/Gradle, maybe helpful to read and learn. Does not directly solve the question.
Continued searching for gitlab ci bump release
, this article uses semantic-release as a NodeJS tool which allows to analyse the tagged versions, and bump the releases accordingly.
Also in
This script looks promising for printing the next version based on the Git history, its value can be used to create the next release using the CLI, or manually.
https://juhani.gitlab.io/go-semrel-gitlab/cli/v0.19.1/next-version/
TL;DR - if there is a script/library which determines the next release value in CI/CD, you can combine it with the release CLI. Finding the script will take some time; though the problem has come up often and wider community members looked into creating their solutions and blog articles to help.
2 Likes
thanks for the details, let me work with them
Hi, @ozbillwang! To utilize predefined CI/CD tasks, you can include
existing .gitlab-ci.yml
templates from projects you have access to. For the specific use case you mentioned, the semantic-release template may be an option to consider in addition to the ones mentioned previously.
2 Likes