GITLAB automatically triggers Jenkins build

GitLab is the most widely used Git Hosting tool, and Jenkins is a great tool for continuous integration. Although GitLab has built-in GitLab CI, it is far less powerful and usable than Jenkins. Both Jenkins and GitLab provide a very handy tool for the combination of both. When we push the code to GITLAB, or perform some other action, GitLab can notify the Jenkins,trigger Jenkins project of the build to execute automatically.

To implement the build action automatically trigger the Jenkins project when moving to the GitLab push code, you need to configure it in several places in GitLab and Jenkins: (1), install the plugin in Jenkins, (2), configure the GitLab user, (3), (4), configure Jenkins Engineering, (5), configure the GitLab project. installing plugins in Jenkins

Select System Management --management plug-in to open the plug-in management page, as shown below:

Select plugins such as Gitlab Hook Plugin and Gitlab Plugin in the optional plugin and click the Direct Install button below to install the plugin:

Create a test project

To facilitate testing, the test works are first created on Jenkins and GitLab respectively. On the Jenkins Dashboard home page, click New Task and go to the new task page:

Enter the project name in the input box, choose to build a free-form software project , then click the OK button in the lower left corner to access the project configuration page.

In the source Management Section of the Project configuration page, enter the URL of GitLab repo, as shown below:

If it is a URL in https form, remember to configure the login GitLab username and password by clicking the Add -and Jenkins button at the back of the Credentials line, in the following dialog box that pops up Enter your user name and password:

After ADD, select this set of user names and passwords in the Credentials drop-down box. Without adding GitLab user password, Jenkins error-Unable to access repo, as shown below:

Then click the Save button in the lower left corner to complete the creation of the Jenkins project and associate it with the GitLab project. Configuring GITLAB Users

Create a user or select an existing user to interact with the Jenkins and GitLab APIs. This user will need to be a global administrator or add into each group/project and act as a member. Developer permissions are required to report the build status. This is because when the ' merge when pipeline succeeds ' feature is used, a successful build state can trigger a merge. Some of the features of GitLab Plugin may require additional permissions. For example, there is an option to accept the merge request when the build succeeds. Using this feature requires Developer,master or owner-level permissions.

Select Settings :

Copy the Private token, which will be used later when configuring the Jenkins server. Configuring the Jenkins server

The Jenkins server needs to be configured to communicate with the GITLAB server.

In Jenkins, select System Management , System settings , and find the GitLab section in the System setup:

Enter the connection name in the input box after Connection name , and enter the URL address of the Gitlab server in the input box after the Gitlab host URL . Click on the Add - Credentials button at the back of the line, and the following dialog box appears, selecting GitLab A in the drop-down list after * kind* PI tokenand paste the Private token from the previous copy into the input box after the API token . Then select GitLab API tokenin the drop-down box in Credentials . Configuring Jenkins Engineering

Open the Configuration page of the Jenkins project, find the part of the build trigger , tick build when a-change is pushed to GitLab line:

You need to make a note of the Build when the pushed to GitLab line,GitLab CI Service URL: The following URL, which is used when configuring GitLab engineering.

Also point to open the lower right corner of the advanced :

Then click on the Generate button in the lower right corner to generate the Secret tokenand save the Secret token generated here, which will also be used for the subsequent GITLAB configuration. Then click the Save button in the lower left corner to save the previous configuration. Configuring GITLAB Engineering

Create a new or select an existing GitLab project. Then select Settings * integrations*, enter the previously saved GitLab CI Service urlin the URL column in the S Enter the previously saved Secret tokenin the Ecret token column and select the event that you want to build trigger the Jenkins project:

Click the green Add webhook button to complete the creation of the Webhook.

After you have created Webhook, click the Push eventsin the Test drop-down box, as shown below:

Events can be generated manually, triggering the Jenkins project. Click Edit, in the Webhook editing page, pull to the bottom of the page, you can also see that the Webhook recent call situation, as shown below:

You can also see the details of this call by opening the View detailsfor a particular call, as shown in the following figure:

It is not difficult to understand, GitLab Trigger Jenkins project, mainly by sending a POST request to the Jenkins server to achieve. Validation Test

Modify the files in our GitLab test project and push to the GITLAB server:

➜test_for_gerrit git: (Master) echo "Hello, World" >> read2.md➜test_for_gerrit git: (master) ✗git status on Bra
NCH Master Your Branch is up-to-date with ' origin/master '. Changes not staged for commit: (use "git add <file> ..." To update what would be committed) (use "Git checkout- <file&gt, ... "to discard changes in working directory) modified:read2.md no changes added to commit (use" Git
Add "and/or" Git commit-a ") ➜test_for_gerrit git: (master) ✗git Add. ➜test_for_gerrit git: (master) ✗git commit-m "ADD test data." ➜test_for_gerrit git: (master) git push warning:push.de Fault is unset; Its implicit value have changed in Git 2.0 from ' matching ' to ' simple '. To squelch this message and maintain the traditional behavior, use:git config--global push.default matching to Squel CH This message and adopt the new behavior now, use:git config--global push.default simple when Push.default is set To ' matching ', git would push local branches to thE remote branches that already exist with the same name. Since git 2.0, git defaults to the more conservative "simple" behavior, which only pushes the current branch to the Corres

ponding remote branch that ' git pull ' uses to update the current branch.
See "git help config" and search for ' push.default ' for further information. (the ' simple ' mode is introduced in Git 1.7.11. 
Use the similar mode ' instead of ' simple ' if you sometimes use older versions of Git) counting Objects:3, done.
Delta compression using up to 4 threads.
Compressing objects:100% (3/3), done. Writing objects:100% (3/3), 312 bytes |
0 bytes/s, done. Total 3 (Delta 1), reused 0 (Delta 0) to Ssh://git@g.hz.netease.com:22222/cloudgame/test_for_gerrit.git 23660c1.  e86152a master, Master➜test_for_gerrit git: (master)

Then quickly in Jenkins, test the bottom left side of the project's main page and see the build task trigger by GitLab push:

Underneath the build task trigger by GitLab Push, it shows who the build task is trigger by who push the code. You can see the detailed process of the build by opening the console output of a specific build task:

Reference Documentation:

Jenkins CI Service
Gitlab automatically triggers Jenkins to build the package

Done.