It is challenging to view and manage the source code changes in GitLab and build the application using Jenkins auto trigger mechanism at the same time. To view code changes, we need to use the Gitlab dashboard and to view the build status, we need to use the Jenkins dashboard. When we are fixing bugs or trying to resolve build issues, it is comprehensive to have a single source for both build status and information regarding code changes.
The recommendation from the CloudifyOps team was to implement a pipeline to publish the Jenkins build status to GitLab dashboard.
Jenkins is an open-source Continuous Integration server written in Java for orchestrating a chain of actions to achieve the Continuous Integration process in an automated fashion. Jenkins supports the complete software development lifecycle from building, testing, documenting the software to deploying and other stages of the life cycle. Jenkins helps to accelerate the software development process.
GitLab is a web-based DevOps lifecycle tool that provides a Git repository manager providing wiki, issue-tracking and continuous integration and deployment pipeline features, using an open-source license, developed by GitLab Inc.
In this blog, we will see the steps to configure the Jenkins server to publish the build status to the GitLab Server.
Requirements:
Jenkins and GitLab Servers are already installed and integrated for this setup. The server version used for this setup is shared below.
Jenkins Version:
GitLab CE Version:
Integrating GitLab with Jenkins server
Jenkins credentials
Configuration of GitLab API settings
Configure Jenkins server to publish the build status to GitLab:
GitLab plugin allows GitLab to trigger builds in Jenkins when code is committed or merge requests are opened/updated. It can also send build status back to GitLab.
Follow the steps for the configuration:
Step 1: GitLab-to-Jenkins Authentication:
By default, the GitLab plugin will require authentication to be set up for the connection from GitLab to Jenkins. This will prevent unauthorized persons from triggering jobs.
Authentication security, APITOKENS and other secrets must not be sent over insecure connections. All connections should use HTTPS.
Step 2: Configuring Global Authentication:
We will use global authentication instead of per-project authentication.
Create a new API Token. Refer the below image:
Step 3: Jenkins-to-GitLab Authentication:
Please Note: This auth configuration is only used for accessing the GitLab API for sending build status to GitLab. It is not used for cloning Git Repos.
This plugin can be configured to send build status messages to GitLab, which show up in the GitLab Merge Request UI. To enable this functionality:
For example, we have created a user with admin access.
Step 4: Jenkins Job Configuration:
There are two aspects of your Jenkins job that you may want to modify when using GitLab to trigger jobs.
The first is the Git configuration, where Jenkins clones your git repo. The GitLab Plugin will set some environment variables when GitLab triggers a build, and you can use those to control the code that is cloned from Git.
The second is the configuration for sending the build status back to GitLab, where it will be visible in the commit and/or merge request UI.
Git Configuration:
Freestyle Jobs
In the Source Code Management section:
In Additional Behaviors:
Click the Add drop-down button.
Select Merge before building from the drop-down.
Set Name of repository to origin
Set Branch to merge as ${gitlabTargetBranch}
Job trigger Configuration
Webhook URL
When you configure the plugin to trigger your Jenkins job, by following the instructions below depending on job type, it will listen to a dedicated URL for JSON POSTs from GitLab’s webhooks.
That URL always takes the form https://JENKINS_URL/project/PROJECT_NAME , or https://JENKINS_URL/project/FOLDER/PROJECT_NAME if the project is inside a folder in Jenkins.
You should not be using https://JENKINS_URL/job/PROJECT_NAME/build or https://JENKINS_URL/job/gitlab-plugin/buildWithParameters, as this will bypass the plugin completely.
Freestyle and Pipeline jobs
Step 5: Build status Configuration:
Configure Jenkins jobs to send their build status back to GitLab, where it will be displayed in the commit or merge request UI as appropriate.
Declarative Pipeline Jobs
The example below configures the GitLab connection and job triggers. It also sends build status back to GitLab.
NOTE: You will need to run this job manually once, in order for Jenkins to read and set up the trigger configuration. If not, webhooks will fail to trigger the job.
pipeline {
agent any
post {
failure {
updateGitlabCommitStatus name: ‘build’, state: ‘failed’
}
success {
updateGitlabCommitStatus name: ‘build’, state: ‘success’
}
}
options {
gitLabConnection(‘your-gitlab-connection-name’)
}
triggers {
gitlab(triggerOnPush: true, triggerOnMergeRequest: true, branchFilterType: ‘All’)
}
stages {
stage(“build”) {
steps {
echo “hello world”
}
}
}
}
To learn more about these cutting edge technologies & real time industry applied best practices, follow our LinkedIn Page. To explore our services, visit our website.
References: