Publishing Jenkins Job build status to GitLab

Publishing Jenkins Job build status to GitLab

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 server
  • GitLab Server
  • Integrate GitLab with Jenkins server.

Jenkins and GitLab Servers are already installed and integrated for this setup. The server version used for this setup is shared below.

Jenkins Version:

No alt text provided for this image

GitLab CE Version:

No alt text provided for this image

 

Integrating GitLab with Jenkins server

  • GitLab integration is already completed & Plugins are required for integration.
No alt text provided for this image
  • Jenkins credentials
No alt text provided for this image
  • Configuration of GitLab API settings
No alt text provided for this image

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.

  1. Create a user in Jenkins which has, at a minimum, Job/Build permissions.
  2. Log in as that user, then click on the user’s name in the top right corner of the page.
  3. Click ‘Configure,’ then ‘API Token’ -> Token Name and Click on ‘Generate’. Note/copy the user ID and API token.
  4. In GitLab, when you create webhooks to trigger Jenkins jobs, use this format for the URL. Do not enter anything for ‘Secret Token’:
    “https://USERID:APITOKEN@JENKINS_URL/project/YOUR_JOB”
  5. After you add the webhook, click the ‘Test‘ button, and it should succeed.

Create a new API Token. Refer the below image:

No alt text provided for this 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:

  1. Create a new user in GitLab
  2. Give this user ‘Maintainer‘ permissions on each repo you want Jenkins to send build status
  3. Log in or ‘Impersonate’ that user in GitLab, click the user’s icon/avatar and choose Settings
  4. Click on ‘Access Tokens’
  5. Create a token named e.g. ‘Jenkins’ with ‘api’ scope; expiration is optional
  6. Copy the token immediately, it cannot be accessed after you leave this page
  7. On the Global Configuration page in Jenkins, in the GitLab configuration section, supply the GitLab host URL, e.g. https://gitlab.jenkins.com
  8. Click the ‘Add’ button to add a credential, choose ‘GitLab API token’ as the kind of credential, and paste your GitLab user’s API key into the ‘API token’ field
  9. Click the ‘Test Connection’ button; it should succeed.

For example, we have created a user with admin access.

No alt text provided for this image

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:

  1. Click Git.
  2. Enter your Repository URL, such as git@your.gitlab.server:gitlab_group/gitlab_project.git. In the Advanced settings, set Name to origin and Refspec to +refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
  3. In Branch Specifier enter:
  • For single-repository workflows: origin/${gitlabSourceBranch}
  • For forked repository workflows: merge-requests/${gitlabMergeRequestIid}

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}

No alt text provided for this image

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

  1. In the Build Triggers section:
  • Select Build when a change is pushed to GitLab
  • Copy the GitLab webhook URL shown in the UI (see here for guidance)
  • Use the check boxes to trigger builds on Push Events and/or Created Merge Request Events and/or Accepted Merge Request Events and/or Closed Merge Request Events
  • Optionally, use Rebuild open Merge Requests to enable re-building open merge requests after a push to the source branch
  • If you selected Rebuild open Merge Requests other than None, check Comments, and specify the Comment for triggering a build. A new build will be triggered when this phrase appears in a commit comment. In addition to a literal phrase, you can also specify a Java regular expression
  • You can use Build on successful pipeline events to trigger on a successful pipeline run in GitLab. Note that this build trigger will only trigger a build if the commit is not already built and does not set the GitLab status. Otherwise you might end up in a loop
  1. Configure any other pre build, build or post build actions as necessary.
  2. Click Save to preserve your changes in Jenkins.
  3. Create a webhook in the relevant GitLab projects (consult the GitLab documentation for instructions on this), and use the URL you copied from the Jenkins job configuration UI. It should look something like https://JENKINS_URL/project/yourbuildname
No alt text provided for this image

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”

}

}

}

}

No alt text provided for this image
No alt text provided for this image
No alt text provided for this image

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.

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from - Youtube
Vimeo
Consent to display content from - Vimeo
Google Maps
Consent to display content from - Google
Spotify
Consent to display content from - Spotify
Sound Cloud
Consent to display content from - Sound