Use jenkins to automatically pull code cloud code to achieve automated deployment

Immediately after the above, let's complete the automated deployment based on jenkins this time, that is, when a new code is pushed, it will trigger an automatic build.

In the previous section, we have implemented manual deployment. Most of the basic configuration has been completed. If you don’t know, you can review it first. . . . [Based on jenkins to manually pull the code cloud code to achieve semi-automatic deployment] (http://mp.weixin.qq.com/s?__biz=MzU3MDAyNDgwNA==&mid=2247487530&idx=1&sn=cd5b9edcd866a1fcc3800e5f29981f7a&chksm=fcf4e621cb836f377679af5bbe8bd469c27125c6b45f41a027b47d6d4dbcbbfb2c529aee3be5&scene=21#wechat_redirect)

To achieve automated deployment, this part of the operation is actually very simple, you only need to configure the build trigger and the triggered event.

The specific goal of this article: use jenkins to achieve automated deployment

ps: My server: CentOs8 Linux

Planned several goals to achieve

• Run on your own machine done
• Use jenkins to pull the git warehouse on the code cloud to the server done
• After pulling the code to the server, you can manually trigger the build and deploy done
• Complete automated deployment done
• Develop your own plug-in, and I haven’t figured out what to do
• To be determined...

Trigger configuration

Open a project we have created, and open the trigger build option of task configuration: Configure -> Build Triggers tab

Enabled Gitee triggers Check the build trigger rules you need, such as Push Event, Opened Merge Request Events. The checked events will accept WebHook and trigger the build.

Currently supported trigger events are:

• Push Events: Push code events
• Opened Merge Request Events: Submit PR events
• Updated Merge Request Events: Update PR events
• Accepted Merge Request Events: Accept/merge PR events
• Closed Merge Request Events: Closed PR events
• Approved Pull Requests: Review of PR events
• Tested Pull Requests: Test passed PR events

Enable [ci-skip] This option can enable support for the [ci-skip] command. As long as the commit message contains [ci-skip], the current commit can skip the build trigger.

At present, I only choose Push Events and submit PR events.

In addition, you can also set the webHook authentication token. The Secret Token for Gitee WebHook option can configure the password of the WebHook. The password must be consistent with the password configured by the Gitee WebHook to trigger the construction.

Get the trigger URL

In the previous step, you can actually get the gitee WebHook URL, here is the focus.

Open the Configure -> Build Triggers tab, the address has been generated.

Warehouse association

We need to associate the above WEBHOOK URL with the corresponding warehouse.

Open the warehouse in the code cloud, enter settings (settings) -> WebHooks

• Add WebHook, URL fill in the WEBHOOK URL we got in the previous step
• Password: If the WebHook password is configured in Jenkins, you can leave it without a password
• Check PUSH, Pull Request event
• Test push to trigger build
  In the WebHook of the Gitee warehouse, select the WebHook with PUSH ticked and click test to observe the construction status of the Jenkins task
  Edit a file in the Gitee warehouse and submit it to observe the build status of the Jenkins task