What should I know before reading the article?

Jenkins will be introduced in the first paragraph of most articles on deployment automation, but the focus of this article is not on the basics of Jenkins, so you should know before reading this article:

  1. You know what Jenkins does for a living?
  2. Know why you hired Jenkins, what it brought to the team, what problems it solved?
  3. How do I install Jenkins?

Configure Jenkins global variables

It is mainly to configure the environment variables and related tools needed in Jenkins package operation tool. As we know, automatic packaging actually means that Jenkins, instead of manual, automatically runs some operations such as downloading, compiling, signing, packaging and copying the project code to a specified directory or starting web service. In order to perform these operations, it is necessary to ensure that relevant SDK or environment variables are available at the system level. Otherwise, Jenkins will definitely report an error if tools or environment variables are missing when performing automated operations.

At present, THE environment variables and tools in my project mainly use Maven, JDK, Git and NodeJS. Please see screenshots for details:

Maven’s repository configuration is in settings. XML, which is usually configured in Idea.

I won’t say much more about the Jdk, the foundation of the foundation.

Git is configured to synchronize the latest code for a given branch from the repository, which might be different if you’re using SVN.

Maven execution procedures, I directly use idea own.

NodeJS is the environment for front-end packaging

Once these tools or environments are in place, you are ready to deploy your automated projects

The Springboot project builds automatically

First click the “New Item” button on the DashBoard and then select” Build a Maven project “. If you do not have the Project, you are missing the Jenkins Maven plugin. Please go to Manage Jenkins -> Manage Plugins to download the relevant components.

The input task name is the folder name generated during the automatic construction of this project, it is best to have unique, I will name according to the format of “project name – front/back – name”, personally feel more intuitive.

This will bring you to the project’s Settings screen, where all the secrets are contained

Each step needs to be set up according to the specific situation of the project. Now I just talk about how my project is set up:

In General I mainly set Discard old Builds, which periodically delete old Builds based on the Settings, mainly to save disk space:

Source code management is mainly used to set the git address of the project to be compiled, the git username and password, and the branch to which the code belongs.

The build trigger is mainly used to set the ability of remote build, which enables users of the same LAN to trigger the code build of remote server by accessing the URL path. The main setting is a token value, that is, the value of id card token. After setting, The remote user can through the task name https://JenkinsIP:Port//job/ / build in the browser? Token = ‘ID token value’ this path is built remotely.

In the build environment I just set Add timestamps to the Console Output so that I can print with timestamps on the Console

Pre Steps are some common operations before construction, which should be based on the actual project situation. Currently, there is no such operation in my project. For specific operation types, you can see the drop-down selection box. Execute Windows Batch Command in Windows and Execute shell in Linux are commonly used. The former is the CMD command and the latter is the shell command.

Build is an in-build operation, mainly to set up the POM file so that Jenkins can find the project’s dependencies during the Build process, and to set the compile time in such a way that test cases are not executed and test case classes are not compiled.

Post Steps refers to Jenkins’ operation after compiling. The main setting is to copy the WAR package to the specified directory by using batch command after compiling successfully.

The build setup is primarily to set up the receiving address that will automatically send mail if a build fails

The post-build operation is essentially the same as the pre-build operation, which is what we should do after the project is built. The operation I do is Delete workspace when build is done, and Delete the workspace after the build is completed, in order to save space.

Once set up, save and click Build Now under the task to Build the project

If you want to see log output during project compilation, go to this task and select Console Data

After the project is successfully built, the compiled WAR package will be copied to the specified directory of Tomcat and the workspace will be deleted. At this point, the automatic construction of the Springboot project is basically complete.

The automatic build of the Springboot project was relatively smooth and basically did not encounter too complex problems. However, the vue.js project was not so easy to build and encountered several difficult problems. See the next chapter for details.

Vue project builds automatically

Projects that build the Node.js class are different from Springboot projects. First, the new project of the Node.js class is selected as a FreeStyle project type instead of a Maven project.

The second is that free type projects have fewer setups than Maven projects and have a special node.js configuration, but the overall idea of building remains the same.

Special node.js configuration items are listed here

First, build the environment

In addition to timestamp, the Provide Node & NPM bin/ Folder to PATH option should also be set in the build environment, because each build needs to perform the environment build first, and after the environment build is completed, the real build project will start. So the option to configure Node.js is to add Node to the environment variable Path to support Node and NPM.

The properties here are all drop-down selections, and are the node.js information previously configured in the global variable.

Second, build,

Different projects have different construction methods due to different environments, tools, etc., so the specific construction basically needs to be set according to the actual situation of the project. The Settings here only represent the actual situation of my project:

First use CMD command, first move to the root directory of the project, and then set the NPM warehouse as the warehouse of the parallel wing platform since the scaffolding is used, see the command for details

NPM config set registry repo.ctbiyi.com: 6442 / repository /…

The NPM config get Registry command is used to determine whether the repository has been set up successfully

Then run NPM install && NPM run build to add dependencies and build the Node.JS project. If the build is successful, a dist folder will be added to the root directory of the project.

I encountered a difficult problem when dealing with vue. JS project, that is, I executed NPM install and NPM run build commands on the project in CMD window, the project compilation and construction were normal, but if the project was compiled with Jenkins, ERROR:Callback was already called The main source of the error is in line 2818 of neo-async async.js in node_modules, but this is a dependency package error, there is no way to fix it from the code side, so this problem stuck with me for a whole day, until my colleague said that I seemed to read a post that said, A similar problem occurs when a dependency package is too late:

Vue project with webpack error, want to know how to solve?

So the colleagues on the front end will rely on the unified upgrade to execute the build without the ERROR:Callback was already called ERROR

The code for the unified dependent upgrade is as follows:

1.• Install NPM install -g npm-check-update to check for new versions of dependency packages in Commend2.Detect the NCU in the project (run the following command in terminal)3.Upgrade version NCU-U4.Install the version dependent NPM installCopy the code

Specific tutorials are as follows:

Vue updates dependencies in package.json to the latest version

Jenkins linked with IDEA

At present, Jenkins has the ability to automatically build projects, but it is still too complicated for developers to visit Jenkins’ website every time to build projects, so we should combine IDEA with Jenkins, so that we can directly build the latest projects on the server in the development tool, isn’t it beautiful?

Specific tutorial reference:

IntelliJ configures Jenkins service’s Crumb Data

However, if you simply follow this approach, you will definitely run into a problem. When configuring parameters in Jenkins plugin of IDEA, [Fail] CSRF enabled -> Missing or bad crumb data [Fail] CSRF enabled -> Missing or bad crumb data [Fail] CSRF enabled -> Missing or bad crumb data You should write the token generated by your account in the password field. For details, please refer to:

Jenkins+ Tomcat automatically publishes hot deployment/restart and encountered pit fixes