Finishing gitflow release from Gitlab runners

Gitflow is a great old way to manage project releases. It is a Git branching model that involves the use of feature branches and multiple primary branches. By using this model, developers create a feature branch and delay merging it to the primary branch until the feature is complete. Finally, this is really just an abstract idea of a Git workflow. This means it dictates what kind of branches to set up and how to merge them together.

Usually, it leads to too much manual work, therefore it is really great to have this process automated. We are going to use AVH Edition of the git extensions to provide high-level repository operations and a repository hosted in the Gitlab environment.

TL;DR:

1. Generate Gitlab access token to use it for automation process
2. Make a fork of gitflow-avh
3. Set up job script
4. Create a finishing release job

First, it needs to prepare a git access token to make the writing and the reading repository available.

Fig. 1. Creation of access token

Copy the generated access token and add it to the global variable of the Project CI/CD to make it available for the jobs scripts:

Fig. 2. Adding the access token to the CI/CD Variables

Then we need to expose the created access token, email, and name to your GitLab runner:

# .gitlab-ci.yml
variables:
 GIT_AUTHOR_EMAIL: ${GITLAB_USER_EMAIL}
 GIT_AUTHOR_NAME: ${GITLAB_USER_NAME}
 GIT_ACCESS_TOKEN: ${GIT_ACCESS_TOKEN}

We want to make the process fully automated without user interaction and this requires setting GIT_MERGE_AUDO_EDIT=no to disable the explanation of the resulting merge commits. To avoid any conflicts further do not forget to unset this value.

Also we need to be sure that all repository branches are up to date.

gitlab-avh needs specific configuration for the branches when the initialization step is going which leads to user interaction as well. We can make it automatic as well by running git flow init -d.

According to this information, let’s make a job script and name it bin/finish-release.sh:

#!/bin/sh
export GIT_MERGE_AUTOEDIT=no
git config --global user.email "$GIT_AUTHOR_EMAIL"
git config --global user.name "$GIT_AUTHOR_NAME"
curl -sL https://github.com/<Your Fork>/gitflow-avh/raw/master/contrib/gitflow-installer.sh | bash -s install stable
git flow version
git remote set-url origin https://gitlab-ci-token:${GIT_ACCESS_TOKEN}@gitlab.<your organization>.com/product/mobile-app.git
git remote -v
git fetch origin
git checkout master
git reset --hard origin/master
git checkout develop
git reset --hard origin/develop
git checkout ${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}
git reset --hard origin/${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}
git status
git rev-parse --abbrev-ref HEAD
git flow init -d
git flow release finish -m "$1" $1 -p
unset GIT_MERGE_AUTOEDIT

The simplest way to make things secure is using the own fork or specific commit of the original gitflow-avh. By this action, we can guarantee that 3rd party bash script doesn't have write/read access to the repository via a provided access token.

When the all things are done we need to configure the job:

finish-git-flow-release:
...
script:
- bash ./bin/finish-release.sh 1.0.0

Finally, if everything is correct the following message will be logged in the Gitlab’s runner:

Summary of actions:
- Release branch 'release/1.0.0' has been merged into 'master'
- The release was tagged '1.0.0'
- Release tag '1.0.0' has been back-merged into 'develop'
- Release branch 'release/1.0.0' is still locally available; it is still remotely available on 'origin'
- 'develop', 'master' and tags have been pushed to 'origin'
- You are now on branch 'develop'

Useful links:

1. Gitflow workflow
2. gitflow-avh

That’s it, I hope you found that article useful. Happy coding! 🎉

I’m a Software Engineer at PandaDoc and we are hiring!