Building a trigger

Since you want to automate continuous integration and deployment, “automation” is critical. If you have to click build by hand, it really doesn’t meet our needs. So we use build triggers.

Triggers, as the name suggests, are events that trigger the build of a project. There are many types of Jenkins triggers, among which are the following

  • Trigger remote build
  • Build after other projects are built
  • Build periodically
  • Poll SCM
  • Git hook is automatically triggered

We’ll focus on git hook auto-triggering

Git Hook automatic trigger build

  • The idea behind this trigger is that when the remote repository detects code changes, it sends a build request to Jenkins and then triggers the Build of Jenkisn

  • Two plug-ins need to be installed: Gitlab Hook and Gitlab

  • In the project configuration select Build when a change is pushed to GitLab.

    Copy the link

  • Log in to GitLab as root, check Allow requests to the local network from Web hooks and services, and click Save Changes.

  • Paste the link into GitLab and click the green Add WebHook button.

  • If the following information is displayed, the request can be sent but there is no permission

  • Manage Jenkins->Configure System

  • Test again, success

  • Returning to Jenkins, you can see that the build is complete

  • Modify the code, push

    (Demonstrated here using a JAVA Web project)

  • Successfully triggering the build

  • The page is refreshed. The modified content is displayed successfully

  • Since then, we’ve implemented a basic CI/CD, and instead of having to manually pack, stop, upload, restart the server, and the rest of the integrated deployment process, the project can automatically update the deployment once the developer commits the code changes