“This article has participated in the good article call order activity, click to see: back end, big front end double track submission, 20,000 yuan prize pool for you to challenge!”

Blog: www.carlblog.site/

See now it is through the combination for automated build this blog, so I can easily manage posts, things are a lot of writing, to the combination, I just need to concentrate on your writing is good, the experience is very good, if you also want to have this kind of experience, then please follow me to understand the principle behind this together. I think it would be ‘rogue’ for a technical article not to talk about specific development environments, so I’ll start by listing the relevant information about the development environment I was in when I set up this blog.

  1. As for the server, I choose the cloud server provided by aliyun, and the operating system is centos8.3 64-bit

  2. Docker version is V2.2.1

  3. Jenkins is through the docker pull a mirror image of the building, and not directly installed on the host machine, the mirror warehouse for registry.hub.docker.com/r/jenkins/j… The version is V2.296

  4. The hexO version is V5.4.0

  5. Github is chosen as the code repository, while other repositories, such as Gitee and GitLab, should have the same process

  6. Since aliyun server has limited access to ports, we have to open the inbound ports in the background as required

Now that the environment is ready, it’s time to set up the automation process in earnest.

Build Jenkins

  • throughdocker pull jenkins/jenkinsPull Jenkins mirror and passdocker container run -p 8080:8080 -d jenkins/jenkinsThe -p argument specifies the mapping between the container and the host port. -D indicates that the container is running in the background as a daemon processdocker container lsTake a look at the Jenkins container that we just started. The information includes, but is not limited to, the container name, the container ID. Now we can go throughOur host IP :8080To visit Jenkins

Configuration Jenkins

Next, we need to configure our Jenkins. Since there are many steps, I will list each step one by one and try not to omit any detail

  • When we enter Jenkins, we first see the Unlock page, where we need to enter the password for confirmation. The password is stored in the Jenkins container, not directly in the host, so the first step is to enter the Jenkins container. The corresponding command is docker exec -it container ID /bin/bash, and the -it parameter represents the execution of the interactive container. Enter the container, according to the page prompted password path, find the password and copy it out, paste it into the input box, you can proceed to the next step

  • In this step, Jenkins will let us choose the plugin we need to install. We can choose both custom and recommendation. Here, we just choose the recommendation, and after confirmation, we can wait for installation

  • Once the plugin is installed, Jenkins needs to set up a username and password, or you can create it as admin, depending on your preference

  • Next up is the BaseurL that needs to be configured for the Jenkins instance, and HERE I’ll just post the instructions that came with Jenkins

Jenkins URL is used to provide the root address of an absolute path link to various Jenkins resources. This means that many Jenkins features need to be set up correctly, such as email notifications, PR status updates, and the BUILD_URL environment variable provided to the build step.

The recommended default values are shown in unsaved, if possible, which are generated based on the current request. The best practice is to set this value, which users may need. This will avoid confusion when sharing or viewing links.

After completing the above steps, we are finally at the Jenkins main screen and are now ready to create a new project for future automated build and release

  • We enter the name of the project and select the project of the custom type. The next step is to configure the project we create

  • We select source management this column in which the configuration items warehouse address, and the corresponding user name and password, it is important to note that if the chain warehouse address is incorrect or the user name and password is not correct, the warehouse address below the input box will have error, this can help us to detect problems early and modified to adjust in time, rather than build times wrong, I think it’s a great place. Another thing to note in the source code management section is the specify branches item, which specifies which branches to listen for and build based on. Here you can set the branches you want to build

  • As the name implies, the trigger is that we need to set the timing to trigger the project construction. Here, we choose GitHub hook trigger for GITScm Polling, so that we can achieve the purpose of triggering Jenkins to automatically build the project after pushing the warehouse code

  • The build environment step is to prepare for the build. In this step, you can select the configuration you need. If our project needed NodeJS to package and build the project, we would need to provide NodeJS for the build environment, but the options in the diagram do not provide NodeJS.

This is because nodeJS needs to be downloaded and installed as an extra. How do you install the NodeJS plug-in in Jenkins

The steps for installing other plugins in Jenkins are the same: Find plugins – download plugins – Install plugins – configure plugins

  • Go to the interface for managing Jenkins, then select the Plugin Management option to go to the Plugin Management page

  • Select the optional plug-in option, search for nodejs and select it. You can choose to install the plug-in immediately after download or after restart. If you select install after restart, you need to replace the path on the page with /restart and restart Jenkins

Now we need to go to the global tools configuration page to manage the Nodejs plug-in we just installed

  • You need to set the nodeJS version required by the build project. There are two installation modes: local installation. In this case, you need to fill in the local nodeJS installation path. The other is to download and install the nodeJS from the nodeJS official website, which requires us to choose the nodeJS version

  • Now back on the project configuration page, we have added the Provide Node & NPM bin/ Folder to PATH line in the build environment column. Now we can select the nodeJS version we configured in the previous step

  • In the build column, we choose to execute the shell, and then we can configure any build script we want to execute. Note that we need to provide the necessary environment for the input script command. For example, for the command in the diagram, we need to provide the nodeJS environment for the script to run successfully

After the steps above, the project is actually configured for the build, but the product of the project build needs to be automatically released to meet our needs. So how does automatic publishing work? Publish Over SSH is implemented using a plugin called Publish Over SSH, so you need to install the plugin. How to install the plugin is described above, and I won’t go into the post build options. Send Build artifacts over SSH. However, before you configure Publish over SSH for a project, you need to do some additional configuration for Publish over SSH globally, as described below

  • Go to the Jenkins system configuration page, go to Publish Over SSH, and fill in the information as shown in the figure below. Note that the password configuration item at the top is global, meaning that any new server will share the password. You are advised to configure a password for each server to avoid unnecessary problems. After filling in the configuration items, we can check the current configuration results to verify whether our configuration is correct in a timely manner.

  • Going back to the Publish Over SSH configuration page of the project, you need to select the SSH server you created in the previous step and configure the following items:
  1. Source Files: This item is used to configure the path where the build artifacts reside. The path context is the project root directory
  2. Remove the prefix: For example, the previous configuration path was build/**/*. If this is left blank, the final release will contain the build directory. If we don’t want the build layer, we just need the build content. So this one we need to put build/
  3. Remote Directory: This specifies the path to Publish to the server. Note that this path is combined with the baseurl configured in Publish Over SSH. The resulting path is the path where the build product will be published
  4. Exec Command: This is used to specify the script to be executed after the build artifacts have all been released. This can be set according to your needs

Here’s an example:

Create githook

After configuring the configuration items described above, we were ready to automate the build and release of our project through Jenkins. But if we had to manually click to publish the project every time, it would be too much trouble. As a programmer, it’s natural to be lazy, so I’m going to show you how to use Githook to automatically trigger builds after pushing code. Github as an example, other code management repositories like Gitee and GitLab are similar. First, select the project that we want to automatically build and publish, then select Settings. In the Settings page, you can find webhooks. In the WebHooks interface, you can manage the hooks that are triggered. Here we need to add a hook and associate this hook with the project we need to build. Here is how to configure this hook.

  • Payload URL: This configuration is used to specify the destination address for hook to send requests. The format of this address should be: Server IP address :8080/ Github-hook
  • Content Type: This configuration is used to set the payload format of hook request. You can choose json or URl-encode format
  • Which events would you like to trigger this webhook? : When to trigger the hook, usually when we select push to trigger the build
  • Active: Used to record the details of each hook trigger

With the above configuration, we can achieve the purpose of triggering the build release project when we push the code.

conclusion

With the Docker + Jenkins + Githook combo, we can easily automate the build and release of a project, greatly reducing the cost of maintenance, and ultimately allowing us to focus on core functionality. Because I really feel the convenience brought by this set of combinational boxing, so I will organize my harvest into this article, which can not only help myself in the future review, but also to help friends who want to understand the knowledge of automatic build release.

Personal blog

www.carlblog.site/ has recently set up a personal blog, which will regularly publish articles about the summary of technical experience. I hope you are interested in it and don’t run away! ~