I. Related reading

1. Use Jenkins to configure Git+Maven for automated builds

Blog.csdn.net/xlgen157387…

2. Jenkins deployed the parameter setting of Maven multi-environment project (Dev, Beta, PROD)

Jenkins+WebHooks (code cloud) continuous integration using the Generic Webhook Trigger plug-in

Jenkins+WebHooks (code cloud) continuous integration using the Generic Webhook Trigger plugin — specify specific branch integration

Ii. Project structure

This is a SpringBoot project, the code cloud address is: gitee.com/xuliugen/uf…

This assumes that you have configured the Jenkins environment, if not, refer to the relevant reading above to do so.

3. Configure Jenkins

1. Create a Job

Because I have created a new one with the same name, so the report already exists, ignore it!

2. Set specific content

Here you specify the project name and description, as well as the Git address and username password in source control.

Build specifies what needs to be done once the source code is pulled down, and Post Steps specifies what needs to be done once the source code is compiled.

Other no screenshots of the default!

3. Specific analysis:

Since it is a Maven project, we need to specify the command to Build the package. Here is the command:

clean package -Dmaven.test.skip=true
Copy the code

Note that there is no MVN because it is compiled using Maven by default! The full command is:

mvn clean package -Dmaven.test.skip=true
Copy the code

-dmaven.test. skip=true indicates that the test is skipped.

(2) The key is the Post Steps script, which is explained in detail here:

If you specify a Git location for your Maven project and code when creating a project, Jenkins will clone the code locally using Git, and then execute the pom.xml file and command specified in the Build.

Here are the details of Jenkins’ work zone (default location: ~/.Jenkins) :

The workspace here is the work interval for the task we created:

You can see the ufind-server we created above, as follows:

The last location of the compiled JAR is:

/home/xuliugen/.jenkins/workspace/ufind-server/ufind-web/target
Copy the code

We can then move the compiled JAR to another location as needed and start it up in the background, otherwise the log will always be displayed in Jenkins’ task screen (check it out if you’re interested!) The background startup process ID needs to be recorded in a file: ufind-web.pid

Thus, the full explanation of the script above is as follows:

Set export BUILD_ID=dontKillMe, and kill the previous process before starting it, otherwise an error will be reported.

It can be seen that as long as we understand the working mechanism of Jenkins, although there is no plug-in related to SpringBoot on Jenkins at present, we can run it step by step by script!

4. Operation results

Through the visitor access service can be correctly run!

5. Upload the compiled JAR file to another server

In the above example, we are simply using the cp command to move the compiled JAR to another location on the same server. This is definitely not the case, it should be the location specified on other servers, and there may be more than one server. So, let’s take a look!

Moving a file from one server to another uses the SCP command, for example:

SCP is a great tool for transferring files in SSH-based Linux environments, but a problem with using shell scripts to call SCP is that it forces the password to be entered interactively, unlike, say, mysql, which has the -u-p option.

Here are two ways to help shell scripts get over the password-entering hurdle!

1. Establish a complete trust relationship between machines

Suppose you need to transfer files from machine A to machine B

(1) Run on machine A

ssh-keygen -t rsa
Copy the code

The preceding command generates private key certificates id_rsa and public key certificates id_rsa.pub in ~/. SSH /.

(2) Copy the public key certificate id_rsa.pub to the. SSH subdirectory of the user root directory on machine B, and append the file content to the authorized_keys file.

Step 2 could have been done with a single line command, which was voted one of the 10 coolest Linux single-line commands by the users of Commandlinefu.com:

ssh-copy-id [-i [identity_file]] [user@]machine
Copy the code

Identity_file is the path of the public key certificate, which is ~/.ssh/id_rsa.pub by default.

If you want to establish complete trust between both parties, you have to go from machine B to machine A again.

However, this method is not perfect. On the one hand, the operation and maintenance cost is too high; on the other hand, the safety barrier between machines completely disappears, so the safety cost is too high. Therefore, I strongly recommend the second method.

2. Expect scripts

Expect scripting, a scripting language built on TCL, is a little-known but gay friend of shell scripting. Born for interaction, Expect scripts are designed as tools specifically for interactive programs, often in conjunction with Telnet, FTP, FSCK, rlogin, TIP, SCP, and so on. Install Expect before using Ubuntu Server:

The four most critical commands in Expect are send, Expect, spawn, and interact.

Send: used to send strings to a process Expect: Used to receive strings from a process spawn: starts a new process Interact: allows users to interactCopy the code

Example code such as:

Running results:

You can find that the file has been uploaded successfully!

Above is a separate Expect script file, which you use if you want to embed it in other shell scripts

After a simple test, our script should look like this:

The script startup.sh on remote host 192.168.1.241 is executed as follows:

Why, instead of executing this remote script directly through Expect? Ha ha, you may not have thought that this is because OF my limited ability to use Expect execution many times without success, so I have no choice but to use such a stupid way! Ha ha, don’t hit me!

See the results of the execution: