There are situations when you would like to create a commit during continuous integration (CI) of your merge request (MR). For example:
- apply automatic fixes from a linter
- extracting translations from the code
In this article, I'll show how to set it up with GitLab.
I will job to be triggered manually. In the real-world examples listed above, you would like to automatically trigger them and just let the git ignore empty commits. As I'm always doing some change in my simplified example, doing it manually saves us from an infinite loop of an ever-changing branch.
I want the changes to be done only on the non-main (non-master) branches. There could be cases where changing master directly makes sense, but I'm used to MR-heavy workflow & I find direct commits to main a bit icky.
This approach is only achievable with Personal Access Tokens. You will need somebody on your team to set it up via their account and pretty much make them share the key with the whole team. And it will stop working as soon as you remove the credentials from the person - which is likely to complicate stuff even further when your CI maintainer leaves the company.
Creating s token
Go to Personal Access Tokens page, and create a token with at least write_repository permission:
Adding the token
Once created, you need to add it as a variable in your project's CI/CD setting page. The variable name I use further in the code is
GITLAB_PUSH_TOKEN. With the above assumptions, you need to set the variable not to be protected - it has to be available on non-main branches. I recommend you make it masked - it will still be available for people who have access to this setting page, but at least your key will not appear in the job logs.
In the following configuration, I use a lot of predefined GitLab variables. You can find the complete list of them in the doc.
stages: - test
Stages definition, I called it
test following what would make sense in the lint changes use case.
add-commit: stage: test
Creates a job & sets the stage.
rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH when: never - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH when: manual
I make it never run on main/master & manually run on all the other branches.
script: - echo 'test' >> $CI_COMMIT_BRANCH - git add .
My dummy changes. I put
test into the file named after the branch.
- git status
Sanity check. Helped me when I was developing the example and will be useful in troubleshooting if needed later on.
- git -c user.email="$GITLAB_USER_EMAIL" -c user.name="$GITLAB_USER_NAME" commit -m "add change in $CI_PIPELINE_ID"
The meaning is as follows:
-c user. ...- sets git configuration for the command alone. Feels cleaner to me than calling
git config --global ..., even though the context in which it would be run is discarded immediately after the job is done.
commit ...is already a standard commit call, but it has to be after the configuration was set
- git push "https://gitlab-ci-token:$GITLAB_PUSH_TOKEN@gitlab.com/marcin-wosinek/automated-commit.git" HEAD:$CI_COMMIT_BRANCH
git push https://gitlab-ci-token:$GITLAB_PUSH_TOKENpushes with the token read from
$GITLAB_PUSH_TOKENwe defined earlier. Any configuration mismatch will fail here.
gitlab.com/marcin-wosinek/automated-commit.git- of course, you will need to replace
marcin-wosinekwith your username/organization & `automated-commit with your project name. If you use a different GitLab server, it should be set here as well.
HEAD:$CI_COMMIT_BRANCH- the CI is in the detached HEAD state - there is no current branch. To work around it, I'm explicitly setting what branch I'm pushing to.
stages: - test add-commit: stage: test rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH when: never - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH when: manual script: - echo 'test' >> $CI_COMMIT_BRANCH - git add . - git status - git -c user.email="$GITLAB_USER_EMAIL" -c user.name="$GITLAB_USER_NAME" commit -m "add change in $CI_PIPELINE_ID" - git push "https://gitlab-ci-token:$GITLAB_PUSH_TOKEN@gitlab.com/marcin-wosinek/automated-commit.git" HEAD:$CI_COMMIT_BRANCH
In this article, we have seen how to make automated commits in GitLab CI. Would you mind sharing in a comment what use case you want to use this for?