In the last post, I showed how to integrate Jenkins with Gilab, to trigger a pipeline. Everything is working, but the declarative pipeline script is fixed in the Pipeline configuration, every time we need to change it, it has to be through Jenkins. Besides being a bad idea, no versioning, no possibility of validations, approvals, nothing, the chance of having problems with a basic error is huge.
So in this post I will show how to make Jenkins read the source file (Groovy) of the pipeline from a project in GitLab. With this we have all the security of an SCM in control of the pipeline script.
Groups and Projects in Gitlab.
First point, I will create a project in our GitLab: infrastructure/pipelines/dns:
Next, our simple script that we used in the previous post, we will create with the name pipeline_tst.groovy, push and merge it to master.
pipeline {
agent any
stages {
stage('gitlab') {
steps {
echo 'Notify GitLab'
updateGitlabCommitStatus name: 'build', state: 'pending'
updateGitlabCommitStatus name: 'build', state: 'success'
}
}
}
}
Jenkins Settings.
Now let’s start configuring Jenkins, first step, enter Jenkins Bash and add the Git Safe Directory information.
su jenkins
vi /var/lib/jenkins/.gitconfig
[safe]
directory = *
su jenkins
vi /var/jenkins_home/.gitconfig
[safe]
directory = *
Now, with an administrator user in Jenkins, open the Pipeline we created and click Configure.
In the Pipeline option, let’s change the options:
1) Definition = Pipeline script from SCM
2) SCM = Git
2.1) Repository URL = This is the URL of your GIT project where the pipeline source script is located:
2.2) Credentials: Use a credential that you have created, UserName, Token, SSL, etc.
3) Script Path = pipeline_tst.groovy
- Definition = Pipeline script from SCM
- SCM = Git
- Repository URL = This is the URL of your GIT project where the pipeline source script is located: http://gitlab.devops-db.internal/infrastructure/pipelines/dns
- Credentials: Use a credential that you have created, UserName, Token, SSL, etc.
- Branch Specifier: */master
- Script Path = pipeline_tst.groovy
Apply and Save the settings.
Pipeline Testing.
This is all very simple, now, if everything is OK, make any commit and create a Merge Request in the project we created for this pipeline in the previous post.
git add .
git commit -m "[FEAT] merge request test"
[branch02 314e357] [FEAT] merge request test
1 file changed, 1 insertion(+)
git push origin branch02
Username for 'http://gitlab.devops-db.internal': faustobranco
Password for 'http://faustobranco@gitlab.devops-db.internal':
warning: redirecting to http://gitlab.devops-db.internal/infrastructure/blueprints/dns.git/
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 323 bytes | 323.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote:
remote: View merge request for branch02:
remote: http://gitlab.devops-db.internal/infrastructure/blueprints/dns/-/merge_requests/3
remote:
To http://gitlab.devops-db.internal/infrastructure/blueprints/dns
2a45b1d..314e357 branch02 -> branch02
Open the project in Jenkins and check the progress of the pipeline, notice the Fetch and Checkout lines in the image below, this indicates exactly that the script used was from GitLab.
Let’s change the script a little and see what we have inside this pipeline Workspace.
Make a new commit/push with the code below, it only prints the environment variables and an ls in the path declares the WORKSPACE variable.
pipeline {
agent any
options { timestamps () }
stages {
stage('Build') {
when { not { changeRequest() } }
steps {
updateGitlabCommitStatus name: 'Finish', state: 'pending'
sh 'printenv'
sh 'ls -lah ${WORKSPACE}'
updateGitlabCommitStatus name: 'Finish', state: 'success'
}
}
stage('Finish') {
when { branch 'master' }
steps {
updateGitlabCommitStatus name: 'Finish', state: 'pending'
sh 'printenv'
updateGitlabCommitStatus name: 'Finish', state: 'success'
}
}
}
}
After that, commit/push that test Merge Request again and then open the new Pipeline Job. See how much information is automatically loaded during the pipeline, also note that the “options { timestamps () }” option in the pipeline script added the time for each execution (We will configure it better in the next post). But the most important thing, and what we will explore a lot in the next posts, is the Branches / Merges information.
But it doesn’t matter now, I really wanted to show that a change in GitLab actually changes the pipeline script.