gitlab-runner集成CI/CD完整项目部署

目录

1.环境安装

2.gitlab代码仓库搭建

3.gitlab-runner-安装以及注册

4..gitlab-ci.yml脚本

 5.脚本说明

6.build.sh

7.test.sh

8. deploy.sh

9.运行流水线

10.选择流水线分支

11.查看运行阶段

12.查看运行日志

13.查看服务器真实日志

1.环境安装

        确保服务器的Java环境、数据库、缓存数据库等应用软件成功安装。

2.gitlab代码仓库搭建

        在服务器搭建安装gitlab应用软件，上传相应的项目代码。

3.gitlab-runner-安装以及注册

        往期博文有提及，我就不再赘述了

4..gitlab-ci.yml脚本

        在项目根目录下编写.gitlab-ci.yml脚本,完成项目CI/CD的集成。

stages:
    - build
    - test
    - deploy

build_job:
    stage: build

    tags:
        - tag
    script:
        - echo "Building the project..."
        - chmod +x build.sh  # 确保在运行脚本前添加执行权限
        - ./build.sh
    artifacts:
        paths:
            - build.log
            - package.log
test_job:
    stage: test
    tags:
        - tag
    script:
        - echo "Running tests..."
        - chmod +x test.sh  # 确保在运行脚本前添加执行权限
#        - ./test.sh

deploy_job:
    stage: deploy
    tags:
        - tag
    script:
        - echo "Deploying application..."
        - chmod +x deploy.sh  # 确保在运行脚本前添加执行权限
        - ./deploy.sh
    only:
        - testmain

 5.脚本说明

        5.1  stages 水线包含三个阶段：构建（build）、测试（test）和部署（deploy）。每个阶段都有一个或多个作业（job），这些作业会按照阶段的顺序执行

        5.2  build_job:
        stage: build: 指定了这个作业属于build阶段。
        tags: - tag: 指定了执行此作业的runner需要匹配的标签。只有带有tag标签的runner才会执行这个作业。
        script: 是一个命令列表，它们会被依次执行。在这个例子中，脚本打印了一条消息表示正在构建项目，然后给build.sh脚本添加了执行权限，并运行了它。
        artifacts: 指定了当作业成功完成后要保存的文件。这里指定了build.log和package.log两个文件将会被保留下来，可以在后续阶段使用或者作为构建结果查看。
        test_job:
        stage: test: 表示这是test阶段的一个作业。
        tags: - tag: 同样地，指定了执行此作业所需的runner标签。
        script: 打印一条消息表示正在运行测试，给test.sh脚本添加执行权限，但注释掉了实际运行test.sh脚本的那一行（# - ./test.sh）。如果这一行没有被注释掉，那么就会执行test.sh脚本来运行测试。
        deploy_job:
        stage: deploy: 这是一个deploy阶段的作业。
        tags: - tag: 和上面一样，指定runner标签。
        script: 打印一条消息表示正在部署应用，给deploy.sh脚本添加执行权限，并运行它来进行部署。
        only: - testmain: 这个关键字限制了deploy_job只会在特定条件下运行。这里的意思是，只有当推送的是testmain分支时，才会触发这个部署作业。
请注意，如果你希望在test_job中实际运行测试脚本，你需要移除那一行前面的#号。同样，only关键字现在已经被更灵活的rules关键字所取代，因此在较新的GitLab版本中可能推荐使用rules来替代only

6.build.sh

#!/bin/sh
# 尝试更改 Maven 本地仓库的权限
echo '尝试更改 Maven 本地仓库的权限...'
chown -R gitlab-runner:gitlab-runner /home/software/maven/rep || {
  echo '更改所有者和所属组失败！请检查错误信息。'
  exit 1
}

# 设置适当的权限
chmod -R 775 /home/software/maven/rep || {
  echo '更改权限失败！请检查错误信息。'
  exit 1
}

#cd  jetlinks-standalone
# 编译项目并打包，将详细日志输出到文件
echo '开始清理并打包...'
mvn clean install -DskipTests > /home/logs/build.log 2>&1 || {
  echo '打包失败！请检查错误信息。'
  cat build.log
  exit 1
}
echo '完成clean且打包'

echo '开始编译'
mvn compile


echo '开始打包...'
mvn clean package -DskipTests > /home/logs/package.log 2>&1
if [ $? -ne 0 ]; then
  echo '打包失败！请检查错误信息。'
  cat package.log
  exit 1
fi
echo '完成打包!'

echo '查找路径：'
cd   jetlinks-standalone/target/
echo '赋予执行权限'
chmod +x jetlinks-standalone.jar
echo '展示文件'
ls
echo '拷贝到项目目录下'
cp jetlinks-standalone.jar    /home/gitProjects/
echo '开始执行jar包'
#nohup java -jar /home/gitProjects/jetlinks-standalone.jar > /home/logs/jetlinks.log 2>&1 &
#nohup java  -Xmx4G -jar /home/gitProjects/jetlinks-standalone.jar  --env=test > /home/logs/jetlinks.log 2>&1 &

chmod 777 /home/logs/jetlinks.log

7.test.sh

#!/bin/sh
# 运行单元测试
mvn test
chmod +x test.sh

8. deploy.sh

#!/bin/sh
# 定义变量
JAR_FILE="/home/gitProjects/jetlinks-standalone.jar"
LOG_FILE="/home/logs/jetlinks.log"
ENV="test"

## 确保日志目录存在
#mkdir -p /home/logs
#chmod 755 /home/logs

# 查找并终止正在运行的 jetlinks-standalone.jar 进程
pids=$(jps -l | grep "$JAR_FILE" | awk '{print $1}')
if [ -n "$pids" ]; then
  for pid in $pids; do
    echo "Stopping process with PID: $pid"
    kill -9 $pid
  done
fi
echo '正在停止 JetLinks standalone 相关程序....'

# 启动新的 JAR 文件实例
nohup java -Xmx4G -jar $JAR_FILE --env=$ENV > $LOG_FILE 2>&1 &
echo '项目重启成功！'

echo "JetLinks standalone application started."

9.运行流水线

10.选择流水线分支

11.查看运行阶段

12.查看运行日志

13.查看服务器真实日志