Java/Vue automatically integrates according to the architecture project gitlab configuration (CI/CD)

1. Install gitlab
   reference documentation: linux installation GitLab tutorial

2. The basic environment required for installation:
   git ( the version of git that comes with cenOS7 is relatively low and needs to be upgraded to the latest version, otherwise an error will be reported when performing automatic build )
   jdk1.8
   maven
   node.js

3. Install gitlab-runner
   3.1 Add GitLab official warehouse

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

3.2 Install GitLab Runner
Run the following command to install GitLab Runner:

sudo yum install -y gitlab-runner

After the installation is successful, a gitlab-runner user will be created, and the /home/gitlab-runner directory will be used as the working target by default, and the configuration file will be located at /etc/gitlab-runner/config.toml by default.
3.3 Register Runner

sudo gitlab-runner register

Run this command on the server, and follow the prompts to enter the URL of GitLab and the Token of the Runner, which will link the Runner to GitLab.

3.4 Start the GitLab Runner service
After completing the registration, you need to start the GitLab Runner service. Run the following command to start the service:

sudo systemctl enable gitlab-runner
sudo systemctl start gitlab-runner
// 查看状态
sudo systemctl status gitlab-runner

Now that you have successfully installed GitLab Runner, it is ready to perform CI/CD tasks for your project.
3.5 Check whether the project on gitlab is successfully associated with gitlab-runner

4. Configure ssh public and private key password-free login
4.1 Execute the following command on the server where GitLab Runner is located to generate an SSH key pair:

ssh-keygen -t rsa

This will generate a .ssh folder in the current user's home directory and contain the public key (id_rsa.pub) and private key (id_rsa) in it.
4.2 Add the public key to the remote server
To add the public key to the authorized_keys file of the remote server, you can use the following command to add the public key to the remote server (enter the server password after pressing Enter):

ssh-copy-id root@192.168.1.88

4.3 After executing the command, you can use ssh [email protected]it to test whether you can log in without password

5. Write the .gitlab-ci.yml script,
   5.1 Refer to the figure below to open the configuration in gitlab
   

5.2 Refer to the following scripts to write a script that suits you. I have a script called boot.sh in the deployment server that can restart the jar package with one click. You can Baidu it yourself.

image: maven:3.6.3-jdk-8

stages:
  - build
  - deploy

cache:
  key: gitlab-ci-cache
  paths:
    - ./ltp-admin/target
    - ./ui-admin/dist

build:
  stage: build
  script:
    - echo "开始打包部署"
    - mvn package
    - echo "打包部署结束"
    - cd ./ui-admin
    - pwd
    - echo "前端-管理端开始打包"
    - npm install ---registry=http://registry.npm.taobao.org
    - npm run build:prod
    - echo "前端-管理端打包结束"
    - cd ../


deploy:
  stage: deploy
  script:
    - scp ltp-admin/target/ltp-admin.jar [email protected]:/usr/local/learn-training-platform/jarProject
    - scp -r ui-admin/dist [email protected]:/usr/local/learn-training-platform/vueProject/dist
    # 此处直接用ssh命令，并且将后面要重启jar包的命令放在和ssh同一行执行
    - ssh [email protected] "cd /usr/local/learn-training-platform/jarProject/;./boot.sh stop;"
    - ssh -tt [email protected] "cd /usr/local/learn-training-platform/jarProject/;./boot.sh start"
    - ssh -tt [email protected] "cd /usr/local/learn-training-platform/vueProject; rm -rf admin; mv dist admin;"

6. At this point, all the configurations are over, and everyone needs to pay attention to the permissions of the execution user. If the deployment is not root user, it may cause many permissions-related problems. It is also best to upgrade the version of git to a new version directly to avoid gitlab-runner execution. Will report an error. The following is a collection of stepping pits. There are many problems that are similar to those encountered by other people when deploying jenkins. If you can't solve them, you can check jenkins.

---

Stepping on the pit highlights:

1. The version of git
   The following error was reported when the build was first executed. In fact, it was caused by a lower version of git. Just update to the latest version.

fatal: git fetch-pack: expected shallow list
fatal: The remote end hung up unexpectedly

2. Encountered the following error when starting to package:

[INFO] Scanning for projects...
Downloading from public: https://maven.aliyun.com/repository/public/org/springframework/boot/spring-boot-dependencies/2.5.14/spring-boot-dependencies-2.5.14.pom
[WARNING] Failed to create parent directories for tracking file /opt/maven/repo/org/springframework/boot/spring-boot-dependencies/2.5.14/spring-boot-dependencies-2.5.14.pom.lastUpdated
Downloading from nexus-aliyun: http://maven.aliyun.com/nexus/content/groups/public/org/springframework/boot/spring-boot-dependencies/2.5.14/spring-boot-dependencies-2.5.14.pom
[WARNING] Failed to create parent directories for tracking file /opt/maven/repo/org/springframework/boot/spring-boot-dependencies/2.5.14/spring-boot-dependencies-2.5.14.pom.lastUpdated
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Non-resolvable import POM: Could not transfer artifact org.springframework.boot:spring-boot-dependencies:pom:2.5.14 from/to public (https://maven.aliyun.com/repository/public): /opt/maven/repo/org/springframework/boot/spring-boot-dependencies/2.5.14/spring-boot-dependencies-2.5.14.pom.part.lock (No such file or directory) @ line 40, column 25
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project com.xxx:ltp:1.0.0 (/home/gitlab-runner/builds/V2ymxA7-/0/xxx/learn-training-platform/pom.xml) has 1 error
[ERROR]     Non-resolvable import POM: Could not transfer artifact org.springframework.boot:spring-boot-dependencies:pom:2.5.14 from/to public (https://maven.aliyun.com/repository/public): /opt/maven/repo/org/springframework/boot/spring-boot-dependencies/2.5.14/spring-boot-dependencies-2.5.14.pom.part.lock (No such file or directory) @ line 40, column 25 -> [Help 2]

In fact, it is because there is no maven warehouse permission. Just configure the directory corresponding to the localRepositor configured in maven/conf/setting.xml with 777 permissions.

Reference document:
Jenkins fails to build maven project
3. After the packaging job is successfully executed, the following problem is reported when executing the deployment job.

It is clear that gitlab-runner has succeeded when executing the build task, and there is a ready jar in the corresponding target The package is completed. Now when executing the deploy task, remove is performed again, and all the previously packaged packages are deleted. After a Baidu meal, I found that this is the default mechanism of gitlab-runner. If multiple tasks need to be associated (used before The file after the task is packaged), the corresponding file needs to be cached (cache), so the following content is added to the .gutlab-ci.yml file, where the key can be named at will, representing the uniqueness of the cache. It can be written on the outermost part, or it can be written in the job. If the key is the same, the one inside will overwrite the one outside.

cache:
  key: gitlab-ci-cache
  paths:
    - ./ltp-admin/target
    - ./ui-admin/dist

4. The .gitlab-ci.yml file is related to ssh
   At first, I used ssh to connect to the server. After the connection was successful, I executed cd to enter the directory (in .gitlab-ci.yml, it is a multi-line script), but after this execution, an error message showed that it could not be found directory, but my directory really exists. Later, I found out that the terminal (remote server) exited directly after the ssh command was executed, and then queried the information. It said that in the ssh command, use the -tt parameter to represent a pseudo Terminal, and forced command interactive mode, so I changed to use Ssh -tt, found that I can enter the directory normally and execute the script to restart the jar package, but found that the jar package failed to start after the execution, and checked the relevant information and found, ssh -tt The command will cause the normal execution of the background operation after the end of the nohup command, and finally changed to the Ssh command and execute the cd directory and restart command on the same line, and! To set BUILD_ID in the script that starts the jar package! Reference document: The problem of killing the child process after jenkins exits