Managing source code changes in GitLab while triggering application builds using Jenkins can be challenging. Developers need to switch between the GitLab dashboard for code changes and the Jenkins dashboard for build status. When fixing bugs or resolving build issues, having a single platform that consolidates both code changes and build insights is essential. Azure DevOps provides an integrated solution, enabling seamless source code management, CI/CD automation, and real-time build monitoring, improving efficiency and reducing workflow complexity.
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 (CI) server, written in Java, designed to automate and orchestrate the software development lifecycle (SDLC). It streamlines processes such as building, testing, documenting, and deploying applications in an efficient and automated manner. As a key tool in DevOps, Jenkins accelerates software delivery by enabling seamless CI/CD pipelines. A DevOps cloud consulting company can leverage Jenkins to optimize cloud-based deployments, enhance scalability, and integrate with modern cloud-native tools, ensuring a faster and more reliable 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
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.
CloudifyOps Pvt Ltd, Ground Floor, Block C, DSR Techno Cube, Survey No.68, Varthur Rd, Thubarahalli, Bengaluru, Karnataka 560037
Indiqube Vantage, 3rd Phase, No.1, OMR Service Road, Santhosh Nagar, Kandhanchavadi, Perungudi, Chennai, Tamil Nadu 600096.
CloudifyOps Inc.,
200, Continental Dr Suite 401,
Newark, Delaware 19713,
United States of America
Copyright 2024 CloudifyOps. All Rights Reserved