Jenkins+git+webhook automatically triggers deployment and test tasks

Jenkins+git+webhook automatically triggers deployment and test task requirements:

The code that needs to be put on line will be push to release branch before going online, then the task on Jenkins can be triggered by manually filling parameters. Hopefully this process will be automated, as long as someone pushes code on the release, automatically runs the release branch and tests

Solutions and steps:

1. Add the settings in the "Source Management" section of the job that needs to be triggered automatically in Jenkins, such as. Fill in the Git repository url and the name of the branch you want to detect

Precautions:

A. When filling in the URL may be prompted to find the error of the command, the solution to this error is to go to the Jenkins System management system settings, find the Git settings section, in path to git executable git path, This path executes commands on the server which git can get.

B. It is also possible to encounter errors such as reporting permission denied. This is due to the fact that the system user using the Jenkins runtime does not have access to the GIT repository permissions. You need to generate the public and private key for git in the user directory where Jenkins is running, and change the owner to that user.

2. In the job where Jenkins needs to trigger the "Build Trigger" section tick poll SCM, but nothing is filled in.

If you fill in a command that crontab that format. Fill out the words is to let it every once in a while to check the source control set in the GIT repository branch has been updated, there is an update to trigger the job, no update will not be triggered. The disadvantage of this setting is that if the check is too frequent, it is a waste of network resources, but the check interval is too long to trigger and not timely.

And the use of the process has a problem, that is, such as 5 minutes to check, the first check when the update was detected, so the job execution time is longer than the check time of 5 minutes, the next check, because the job is still running, It will also assume that the update is not being executed by the job, so it will trigger the job again. Only when the triggered job is finished does it know that the update was executed by the build and no longer triggers.

So the official does not recommend this method, recommended is the way of remote triggering, such as with git post-receive hook trigger, as long as the hook to write this sentence.

Curl Http://yourserver/git/notifycommit?url=[&branches=branch1[,branch2]*][&sha1=]

Since our project is using Gitlab, then Gitlab has a webhook to use. The principle is similar to the post-receive hook.

3. Install a plugin in Jenkins Https://wiki.jenkins-ci.org/display/JENKINS/Gitlab+Hook+Plugin

Look at the name to know that this plugin is to match the Gitlab

4. Add a web hook to the Gitlab project (Project Settings-WebHooks)

There are many kinds of gitlab web hooks that can meet different needs, because our requirements are triggered by the push code, so the choice is push events.

URL function: This place fills in the URL is Gitlab sends the request to use. The idea is that when a developer triggers the hook on a git operation, Gitlab sends a POST request to the URL. The request takes a bunch of parameters such as who the submitter is, which branch is committed, what the commit number is, and so on. The side that accepts this request can use this information to handle the following things, such as deploying test notifications and so on.

Here, since we installed the Gitlab hook plugin on Jenkins, we just need to fill in the URL with the following link in its use:

Http://your-jenkins-server/gitlab/notify_commit

Effect:

The task on Jenkins is automatically triggered when someone commits the code on the release. Push to another branch is not triggered.

Reference documents:

Http://www.jianshu.com/p/ad018160aff9

http://blog.csdn.net/xinluke/article/details/52921254

Jenkins+git+webhook automatically triggers deployment and test tasks