1 – Principle

The main idea is to interconnect the GITLAB (SCM) and the CI (continous integration) services, in order to:

  • automatically run jobs on CI, then some events occur on the GITLAB side, such as: new push to branches, merge request on feature branches…
  • automatically publish the CI build status on the GITLAB server.

To achieve these features, we need to create shared authentication token on each side, and configure each service to use these token.


  • the "merge request" configuration assumes that we use the gitflow paradigm (
  • the name of the CI platform is, you may replace it by your own CI URL
  • the name of the GITLAB platform is, you may…
  • in the rest of the document PROJECT is the name of your software project.

2 – Prerequisite on

Firstly, we need to install the gitlab plugin on

  • log on (
  • scoll to your project section (PROJECT )
  • select Jenkins (green button)
  • you must authenticate yourself on this new page, use the same credentials as for
  • select Manage Jenkins (left menu)
  • select Manage Plugins (right window)
  • select the Available tab
  • search and install the gitlab plugin
  • follow the instructions (install the dependancies, restart jenkins…)

In some case, you may nee to upgrade the jenkins version.

  • log on (
  • scoll to your project section (PROJECT )
  • select Manage project (orange button)
  • you may need to authnticate on the new page
  • select Manage Jenkins (blue button)
  • select a new jenkins version on your qualification session (we advice you to use the last LTS version)
  • push the qualification session to the produc tion session
  • restart the production jenkins service.

3 – Configure the link from ci to gitlab

3.1 – on the side

On the gitlab side, we must create an access token and register it on

You have two options to create this token here:

  • use your own account
  • create a specific account on, and use it to create the token.

Depending on the project status, we advice:

  • in case of a "personal" project, use your own account,
  • in case of a "shared" project, create a dedicated account.

3.1.1 – create a dedicated account on gitlab (for a shared project)

(this section must be skipped if you use your personal account to create the token)

  • create a mailist on with the name (or whatever name which suits you)
  • add you own login in the list of this maillist subscribers
  • WARNING: this maillist should be public to receive emails from the gitlab server

  • connect to (do not log on with your account)
  • create a new user with the email
  • choose a password (you may share this password with the rest of the team)
  • the mailist will receive a confirmation email (as a subscribers, you will receive it also)
  • click on the link provided by this email
  • the new account is now fully declared

  • log off
  • and log back on with an administrator account (aka your own account)
  • add the user PROJECT-gitlab as member of the project
  • give the developper privileges to this account

3.1.2 – create an access token

  • log on with the proper identity (your account or the PROJECT-gitlab account)
  • select Settings (the menu is on the extreme right of the topbar, just below your gravatar)
  • select Access Token (5th item on the left menu)
  • create anew token with the following attributes:

    • name: PROJET-token
    • Expires at: leave empty (no end date)
    • Scopes: api
    • Click on Create personal access token
    • WARNING: you must immediately save the token value (eg: 9kUp5GGq7chCK8DmessB) because this token cannot be available later.

3.2 – on the side

We will now declare the above token on

  • log on (using your personal account)
  • go to the dashboard (
  • scroll to the PROJECT
  • select Jenkins (green button)
  • you must land to
  • authenticate if necessary (same email/password that on
  • to add the token, you need to:

    • select Credentials (left menu), which will expand this menu
    • select System (left menu, just below the previous one)
    • select Global credentials (first field on the right of the page)
    • select Add credential (left menu)
    • fill the form with:
      • Type: Gitlab API Token
      • Scope: Global (Jenkins, nodes,…) (default value)
      • API token: copy here the previous authentication token (eg: 9kUp5GGq7chCK8DmessB)
      • ID: Gitlab API token (or anything you like, this field is mandatory)
      • Description: any description you like
    • click on OK

We will now configure Jenkins to use this token.

  • got back to

    • select Manage Jenkins (left menu)
    • select Configure System (1st item of the right part of the page)
    • scroll to Gitlab
    • configure:

      • Connection name: gitlab-inria
      • Gitlab Host URL:
      • Credential: Gitlab API token (the previous ID)
    • select Save
    • select Test Connection (a success message should appear).

4 – Jobs configuration

Remark: the next two chapters should be repeated for all jobs that you want to automatize.

4.1 – Jobs configuration on

This step will configure the jobs, and allow them to receive signals from

In order to achieve this, you should:

  • log on (using your personal account)
  • scroll to your projet, and select Jenkins
  • select the job you want to trigger with gitlab
  • select Configure (left menu)
  • Tab: General (in the tab list)
    • Item Gitlab Connection: select gitlab-inria in the menu (in fact, the name is the "Connection Name" above)
  • Tab: Source Code Management
    • Select: git
      • Item Branch Specifier (blank for ‘any’): origin/${gitlabSourceBranch}
    • Tab: Build Triggers
      • select Build when a change is pushed to GitLab
      • WARNING: you must memorize the GitLab CI Service URL of the job (ex: ) which will be reported on the next section
      • select Advanced
      • go to the end of this section, until the Secret token item
      • select Generate
      • this will generate the token associated to the GitLab CI Service URL (eg: 3d28ce2e9df42fb44d994752ce142b57)
      • item Filter branches by name: Include develop,master
    • Tab: Post-build actions
      • add a new action by clicking Add post-build action
      • action: Publish status to Gitlab commit

4.2 – webhook configuration on

The last action is to configure to send signals to for each job it want to schedule. This is done be usinf webhooks and configure then to use the GitLab CI Service URL and token.

  • log on to (use an administrator account, yours for example)
  • select Settings/Integrations (left menu)
  • copy the GitLab CI Service URL (ex:
  • copy the token (ex: 3d28ce2e9df42fb44d994752ce142b57)
  • select the following triggers:

    • Push events
    • Merge Request events
  • select Add webhook
  • select Test (Push events)
  • this should display a pale blue banner with the Hook executed successfully HTTP 200 message
  • if you are quick enough, you can go back to and verify that a build process is in action

That’s all folks

Leave a Reply

Your email address will not be published. Required fields are marked *