CI/CD与Jenkins
1. CI/CD 与 DevOps
1.1 CI/CD 简介

从plan开始看
CI,Continuous Integration,持续集成。即将持续不断更新的代码经构建、测试后也持续不断的集成到项目主干分支。
CD,包含两层含义:Continuous Delivery,持续交付,和 Continuous Deployment,持续部署。
- 持续交付:是持续集成的后续步骤,持续频繁地将软件的新版本交付到类生产环境预发,即交付给测试、产品部门进行集成测试、API 测试等验收,确保交付的产物可直接部署
- 持续部署:是持续交付的后续步骤,将持续交付的产物部署到生产环境
1.2 DevOps简介

百度百科中是这样介绍 DevOps 的:
DevOps(Development 和 Operations 的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。
它是一种重视“软件开发人员(Dev)”和“IT 运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps 是一种思想,是一种管理模式,是一种执行规范与标准。
1.3 CI/CD与DevOps关系
CI/CD 是目标,DevOps 为 CI/CD 目标的实现提供了前提与保障。
2. 系统架构图
最终要搭建出如下图所示架构的系统。

说明:
- 首先再
idea中写好源码,推送源码到GitLab上去- 搭建
Jenkins环境,在Jenkins环境中,会先把GitLab上的代码拉取(git pull)下来,之后安装maven构建工具,用于将源码构建为jar包,之后再使用Sonar Scanner(SonarQube:用于检查写的代码是否有重复,规范等等问题),也就是SonarQube的客户端工具来进行代码质量检查,代码检查通过之后,最后我们就需要将他构建为镜像(docker build)- 构建为镜像之后,通过
docker push将镜像推送到harbor(镜像中心)Jenkins将SSH:cmd命令传输给目标服务器(Target Server),目标服务器来进行相关操作(docker pull、docker run等)- 最后将构建结果发送到钉钉中
3. Idea 中 Git 配置
3.1 Git简介
百度百科中是这样介绍 Git 的:
Git(读音为/gɪt/)是一个开源的分布式版本控制系统,可以有效、高速地处理从很小到非常大的项目版本管理。也是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
3.2 Git的工作流程

3.3 Git的下载与安装
从 Git 的官网下载 Git。其官网为:https://git-scm.com 。根据安装向导“下一步”式安装即可(或者查看我git快速入门文章:https://blog.cqwulyj.cn/posts/4a382a13.html)


3.4 Idea中配置Git

4. GitLab 安装与配置
这里我新建了一个主机,然后修改
/etc/hostname为ccgitlab
4.1 简介
GitLab 是一个源码托管开源工具,其使用 Git 作为代码管理工具,并在此基础上搭建起来的 Web 服务。GitLab 由乌克兰程序员使用 Ruby 语言开发,后来一部分使用 Go 语言重写。生产中通常使用 GitLab 搭建私有源码托管平台。
4.2 GitLab的安装
4.2.1 主机要求
这里要使用 docker 方式来安装 GitLab,所以需要一台安装有 docker 及 docker-compose的主机,且该主机内存至少 4G。

4.2.2 拉取镜像
这里使用由 gitlab 官网发布的社区版镜像 gitlab/gitlab-ce:latest。该镜像最好是先拉取到本地后再使用,因为该镜像比较大。

4.2.3 定义 compose.yml
由于启动 GitLab 容器时需要设置的内容较多,为了方便,这里使用 docker-compose 方式启动。
在任意目录 mkdir 一个子目录,例如在/usr/local 下新建一个 glab 目录。在该目录中新建compose.yml文件。文件内容如下:
services:
gitlab:
image: gitlab/gitlab-ce
container_name: gitlab
restart: always
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'http://192.168.254.136:9999' #这个地址是关联远程仓库的地址
gitlab_rails['gitlab_shell_ssh_port']=2222
ports:
- 9999:9999
- 2222:2222
volumes:
- ./config:/etc/gitlab
- ./logs:/var/log/gitlab
- ./data:/var/opt/gitlab
4.2.4 启动 gitLab
使用 docker-compose up -d 命令启动容器服务。不过,其启动过程时间较长些。
docker-compose up -d

4.3 GitLab的密码配置
4.3.1 浏览器访问
在浏览器中直接键入 http://192.168.254.136:9999 即可打开登录页面。不过,这个过程一般需要的时间较长。这里需要登录的用户名与密码。默认的用户名为 root,而默认密码需要进入容器中查看

上图我写的是131:9999,其实后面我自己更改了,要访问136:9999才可以,你只需要记住你输入你gitlab服务器的IP即可
4.3.2 查看登录密码
gitLab 平台的登录用户名默认为 root,初始密码在容器中/etc/gitlab/initial_root_password文件中。所以需要首先进入容器,然后查看该文件内容。然后再将 root 用户名与复制来的密码填写到登录页面的相应位置即可登录成功。

/otjslB+LqziV0KfZUjvtSwqvJ31XQYC4HWd5SirVpo=

4.3.3 修改密码
登录后,首先要修改初始密码。新密码要求长度不能少于 8 位。为了方便,这里将新密码设置为 8 个 1。

5. SonarQube 安装与配置
这里我新建(克隆)了一个主机,然后修改
/etc/hostname为sonarqube
5.1 简介
SonarQube 是一个开源的代码扫描与分析平台,用来持续扫描、分析和评测项目源代码的质量与安全。 通过 SonarQube 可以检测项目中代码量、安全隐患、编写规范隐患、重复度、复杂度、代码增量、测试覆盖率等多个维度,并通过 SonarQube web UI 展示出来。
SonarQube 支持 30+种编程语言代码的扫描与分析,并能够方便的与代码 IDE、CI/CD 平台完美集成。
SonarQube 的官网地址:https://www.sonarsource.com/
5.2 主机要求
这里要使用 docker 方式来安装,所以需要一台安装有 docker 及 docker-compose 的主机。
5.3 安装与配置
5.3.1 下载两个镜像
由于 SonarQube 需要 Postgres 数据库的支持,所以安装 SonarQube 之前需要先安装Postgres 数据库。所以需要下载 Postgres 与 SonarQube 两个镜像。
在下载之前,要先查看
SonarQube官网的版本
所以我们使用docker来安装,也要按照和它一样的版本。
docker pull postgres
docker pull sonarqube:9.9-community

5.3.2 定义 compose.yml
由于需要启动两个容器,所以这里使用 docker-compose 方式。
在/usr/local 下 mkdir 一个 sonar 目录,在其中定义 compose.yml 文件。
services:
postgres:
image: postgres
container_name: pgdb
restart: always
ports:
- 5432:5432
environment:
POSTGRES_USER: sonar
POSTGRES_PASSWORD: sonar
sonarqube:
image: sonarqube:9.9-community
container_name: sonarqb
restart: always
depends_on:
- postgres
ports:
- 9000:9000
environment:
SONAR_JDBC_URL: jdbc:postgresql://pgdb:5432/sonar
SONAR_JDBC_USERNAME: sonar
SONAR_JDBC_PASSWORD: sonar
5.3.3 修改虚拟内存大小
这一步不是必须做,如果你启动
SonarQube没有成功,可以考虑设置这个
在/etc/sysctl.conf 文件中指定vm.max_map_count虚拟内存大小。

修改保存后再运行 sysctl –p 命令使 Linux 内核加载文件中的配置。
sysctl -p

5.3.4 启动 SonarQube
通过 docker-compose up –d 命令启动容器,并 docker ps 查看是否启动成功。
docker-compose up -d
docker ps

5.3.5 登录 SonarQube
在浏览器键入 SonarQube 服务器的 IP 与端口号 9000,即可打开登录页面。默认用户名与密码都是 admin。

Log in 后即可跳转到更新密码页面。这里更新密码为 8 个 1。

Update 后即可看到首页。

5.3.6 安装汉化插件


重启后,页面会自动跳转到具有中文的登录页面。登录进入后,页面已经变为了中文

6. harbor 安装与配置
这里我新建(克隆)了一个主机,然后修改
/etc/hostname为ccharbor这部分的内容在docker 11章有详细说明
6.1 Harbor安装系统要求
Harbor 要安装的主机需要满足硬件与软件上的要求。
6.1.1 硬件要求

6.1.2 软件要求

6.2 安装Harbor
6.2.1 下载安装包
在官网复制 Latest 最新版的离线安装包的下载链接地址,在 Linux 系统中通过 wget 命令下载,将其下载到某目录中(我放在了/opt/tools/中)。
wget https://github.com/goharbor/harbor/releases/download/v2.8.1/harbor-offline-installer-v2.8.1.tgz
因为这个下载比较慢,所以我是在window上下载好了,在上传到Linux中

6.2.2 解压安装包
将下载好的包解压到某目录(我这里解压到了/usr/local/)中。解压后其就是一个独立的目录 harbor。
tar -zxvf harbor-offline-installer-v2.8.1.tgz -C /usr/local/


6.2.3 修改 harbor.yml
复制一份 harbor 解压包中的 harbor.yml.tmpl,并重命名为 harbor.yml。


6.2.4 运行 prepare
运行 harbor 解压目录中的 prepare 命令。该命令会先拉取 prepare 镜像,然后再生成很多的其后期要用到的配置文件。

6.2.5 运行 install.sh
运行 harbor 解压目录中的 install.sh 命令,其会自动完成五步的安装过程,并在最终启动很多的容器。这些容器本质上就是通过 docker-compose 进行编排管理的。

6.2.6 新建仓库
在浏览器地址栏中输入 http://192.168.192.131 即可看到登录页面,在其中输入用户名admin,密码为默认的 8 个 1,即可登录。
登录后点击“新建项目”,新建一个镜像仓库



7. 目标服务器安装与配置
这里我新建(克隆)了一个主机,然后修改
/etc/hostname为target
7.1 docker引擎
由于目标服务器需要从镜像中心 Harbor 中 docker pull 镜像,然后使用 docker run 来运行容器,所以目标服务器中需要安装 Docker 引擎。
7.2 docker-compose
由于目标服务器需要通过 docker-compose 运行 compose.yml 文件来启动容器,所以目标服务器中需要安装 docker-compose。
7.3 接收目录
Jenkins 通过 SSH 将命令发送到目标服务器,以使目标服务器可以从 Harbor 拉取镜像、运行容器等。所以在目标服务器中需要具有一个用户接收 Jenkins 发送数据的目录。本例将该接收目录创建在/usr/local/jenkins 中。
mkdir /usr/local/jenkins
8. Jenkins 安装与配置
这里我新建(克隆)了一个主机,然后修改
/etc/hostname为ccjenkins
8.1 Jenkins简介
8.1.1 百度百科
以下是百度百科中关于 Jenkins 的词条:
Jenkins 是一个开源软件项目,是基于 Java 开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件项目可以进行持续集成。
8.1.2 主机要求
这里要使用 docker 方式来安装,所以需要一台安装有 docker 及 docker-compose 的主机。
8.2 安装JDK
由于 Jenkins 通过调用 Maven 来实现对项目的构建,所以需要在 Jenkins 主机中安装Maven。由于 Maven 的运行需要 JDK 的环境,所以需要首安装 JDK。
对于 JDK 的安装非常简单,只需要从官网下载相应版本的 JDK 到 Linux 系统后,直接解压即可。无需配置。这里下载的是 jdk-8u201-linux-x64.tar.gz,将其解压到了/opt/apps 目录下(没有这个目录的自己创建一个即可),并重命名为了 jdk。
tar -zxvf jdk-8u202-linux-x64.tar.gz -C /opt/apps/


8.3 安装Maven
8.3.1 下载解压 maven
首先需要从官网下载最新版本的 Maven 到 Linux 系统后,直接解压。这里下载的是apache-maven-3.9.2-bin.tar.gz,将其解压到/opt/apps 目录下,并重命名为 maven。

tar -zxvf apache-maven-3.9.2-bin.tar.gz -C /opt/apps/


8.3.2 配置 maven 镜像仓库
maven 解压后需要修改解压目录中 conf/settings.xml 文件中的两处配置。这里配置 maven的镜像源为 aliyun。
<mirror>
<id>alimaven</id>
<mirrorOf>central</mirrorOf>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
</mirror>

注意:我这里注释的有问题,仔细查看
<mirror>标签应该再</mirror>之前
8.3.3 配置 maven 编译器版本
maven 默认的编译器版本为 JDK1.4,这里需要指定为 JDK1.8。配置了该<profile>后,在文件最后的<activeProfiles>中再激活一下即可。
<profile>
<id>jdk-8</id>
<activation>
<jdk>1.8</jdk>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
</profile>
<activeProfiles>
<activeProfile>jdk-8</activeProfile>
</activeProfiles>

8.4 安装启动Jenkins
8.4.1 下载镜像
这里要使用 docker 方式来安装 Jenkins,所以需要先下载 Jenkins 的镜像。
官网:Jenkins
同样的,下载Jenkins镜像之前,也要先去官网看看目前最新的长期支持的版本
之后再去
docker hub上拉取与之一样版本的镜像


docker pull jenkins/jenkins:2.387.3-lts

8.4.2 启动 jenkins
使用 docker run 命令启动 Jenkins。
docker run --name jenkins \
--restart always \
-p 8080:8080 \
-p 50000:50000 \
-v /var/jenkins_home:/var/jenkins_home \
-d jenkins/jenkins:2.387.3-lts

8.4.3 修改数据卷权限
当 Jenkins 启动后,通过 docker logs jenkins 命令查看 jenkins 的日志可以看到出错了。
docker logs jenkins

原因是,jenkins 需向数据卷挂载点的文件/var/jenkins_home/copy_reference_file.log 中写入日志时,由于写入操作的用户不是 root 用户,而非 root 用户对数据卷没有写操作权限。

此时需要修改数据卷操作权限,为非 root 用户添加写操作权限。

8.4.4 重启 jenkins
docker restart jenkins
8.4.5 修改插件下载源
由于 jenkins 在后期运行时需要下载很多的插件,而这些插件默认都是从国外的 Jenkins官方服务器上下载的,下载速度很慢,且下载失败的比例很高。所以,一般会先将这些插件的下载源更新为国内的服务器。
该更新文件是数据卷目录中的 hudson.model.UpdateCenter.xml。

查看该文件内容:

将该默认的<url>更换为清华大学的下载源地址:https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/current/update-center.json
8.4.6 查看 admin 默认密码
通过 docker logs jenkins 命令查看日志,可以看到已经正常了。并且在最后还可以看到Jenkins 的 admin 用户及其初始化密码。
docker logs jenkins

5817e25ee3d2449e8fa29822241620ce
8.4.7 插件下载
在浏览器中键入 jenkins 的地址后进行访问,可看到 Jenkins 解锁页面。在管理员密码中输入前面 docker logs jenkins 中看到的初始化密码后继续。


选择插件来安装。

这里保持默认的选择即可。

该页面需要的时间可能会较长。
8.4.8 创建管理员用户
当插件下载完毕后,会自动跳转到该页面。填写上第一个管理员信息后保存并完成。这里填写的用户名为 zhangsan,密码为 8 个 1。




8.5 配置Jenkins
8.5.1 安装两个插件
点击 Manage Jenkins 中的 Manage Plugins 页面,在 Available plugins 选项卡页面的搜索栏中分别键入 Git Parameter 与 Publish Over SSH,选中它们后,Install without restart。


然后就可看到下载过程显示“等待”,直到看到下面的“完成”“Success”后,即可返回首页了。

8.5.2 移动 JDK 与 Maven
首先要将 Jenkins 主机中的 JDK 与 Maven 解压目录移动到数据卷/var/jenkins_home 中。

8.5.3 配置 JDK 与 Maven
在 Manage Jenkins 的 Global Tool Configuration 页面中配置 Maven 与 JDK。



这里填写的是容器中挂载点目录中的路径。


这里填写的也是容器中挂载点目录中的路径。最后再应用并保存。
9. Jenkins 集成 SonarQube
9.1 Jenkins中安装SonarScanner
9.1.1 SonarScanner 简介
SonarScanner 是一种代码扫描工具,专门用来扫描和分析项目代码质量。扫描和分析完成之后,会将结果写入到 SonarQube 服务器的数据库中,并在 SonarQube 平台显示这些数据。
9.1.2 下载
在 SonarQube 官网的帮助文档中可以下载 SonarScanner。这里下载一个 Linux 系统下使用的版本。

9.1.3 安装 unzip
由于下载的 SonarScannner 是 zip 压缩类型的,所以需要在 Linux 系统中安装 unzip 命令,以解压该压缩包。
yum install -y unzip

9.1.4 解压/移动
解压 zip 压缩包。
unzip sonar-scanner-cli-4.8.0.2856-linux.zip

由于后期要在 Jenkins 中集成 SonarScanner,需要 SonarScanner 存在于 Jenkins 服务器中的数据卷目录中。所以将解压后的目录移动到数据卷 jenkins_home 下并更名为 sonar_scanner。

9.1.5 修改配置文件
在 sonar-scanner 目录的 conf 目录下有其配置文件 sonar-scanner.properties。修改该配置文件。

9.2 Jenkins配置SonarQube
9.2.1 安装插件
在 Jenkins 页面的系统管理 –>插件管理 –> Available plugins 中搜索 sonarqube scanner,安装该插件。该插件用于连接 SonarScanner。

安装完毕后,点选“安装完成后重启 Jenkins”,进行重启。
9.2.2 添加 Sonarqube
打开 Jenkins 的 Manage Jenkins –>Configure System 页面,找到 SonarQube servers,添加 SonarQube 服务器。

点击 Add SonarQube 按钮后即可看到以下配置框。



9.2.3 添加 SonarScanner
这里要将前面安装在 Jenkins 数据卷中的 SonarScanner 配置到 Jenkins 中。
在 Jenkins 页面的 Manage Jenkins –> 全局工具配置 中找到 SonarQube Scanner。


10. Jenkins 集成目标服务器
这里要配置连接到目标服务器的连接方式。打开 Manage Jenkins 中的 Configure System页面。

将页面拉到最下面,可以看到 Publish over SSH。这里可以设置非对称加密的身份验证方式,也可设置对称加密的身份验证方式。这里采用对称加密身份验证方式。点击新增按钮。



填写完毕后,页面拉到最下面,点击 Test Configuration 进行测试。如果可以看到 Success,说明连接成功。然后再应用并保存。
11. 自由风格的 CI 操作(中间架构)
11.1 中间架构图

11.2 创建web项目
创建一个 web 项目,就使用最简单的 spring boot 工程,例如工程名为 hellojks。仅需导入 spring web 依赖即可。
11.2.1 创建工程
创建一个 Spring Boot 工程,其仅包含一个 spring web 依赖。
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.5.4</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.jks</groupId>
<artifactId>hellojks</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>hellojks</name>
<description>hellojks</description>
<properties>
<java.version>1.8</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
11.2.2 定义 Controller
只需定义一个简单的 Controller 即可。
package com.jks.controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
/**
* @author 念心卓
* @version 1.0
* @description: TODO
* @date 2023/5/21 15:14
*/
@RestController
public class SomeController {
@GetMapping("/some")
public String someHandle(){
return "hello Jenkins world";
}
}
11.2.3 访问效果

11.3 Idea提交项目到远程仓库
这一部分内容其实就是Git的操作 ,GitLab、GitHub、Gitee操作基本上都差不多
11.3.1 在 GitLab 中创建远程仓库
首先在 GitLab 中创建一个远程仓库,用于管理前面 Idea 中创建的工程。



点击 Create project 后就可进入下个页面,可以看到当前仓库的信息及相关的操作命令。客户端通过这些命令可完成对该仓库的操作。

11.3.2 创建用户
仿照远程仓库页面中的 Git global stetup 中的命令,在项目的 Terminal 窗口中创建一个全局用户。
因为我电脑之前已经创建过了全局的用户和账号,这里我就不再演示。
11.3.3 初始化本地仓库
将当前的项目目录 hellojks 初始化为本地仓库。



可以看见里面的文件变红了,其实这就是未提交到本地仓库的信号。
11.3.4 提交代码到本地库
在项目上右击,选择 Git –>Commit Directory。

此时会弹出一个 Commit to master 的窗口。在其中选择要提交的文件,并在文本区填写提交日志。然后 Commit。

然后会看到警告,不影响提交,直接再 Commit Anyway 即可。

这样代码就提交带了本地库,并且里面所有的文件也不再是红色了

11.3.5 提交到远程库
首先要从远程仓库中获取仓库地址。选择复制 Clone with HTTP 的地址。

然后在项目上右键,选择 Git –> Push。

在新窗口中点击 Define remote,在弹出的窗口中粘贴进复制来的远程仓库地址。


Push 后会弹出访问 GitLab 的登录窗口,输入用户名 root,密码为前面修改过的 8 个 1。
也就是你自己的gitlab账号密码
推送成功后,在 idea 右下角即可看到成功提示。

此时刷新 GitLab 页面,即可看到推送来的项目。

11.4 从GitLab拉取代码
11.4.1 新建任务


11.4.2 Jenkins 集成 GitLab
在点击确定后即可立即配置 Jenkins 中 GitLab 服务器的信息。

对于
public的GitLab仓库,直接指定仓库地址,应用保存即可。但对于private仓库,则需要指定访问GitLab的用户名与密码。点击添加按钮,即可打开下面的窗口。

在其中填写用户名与密码后“添加”即可返回之前的页面,此时在 Credentials 下拉框中即可找到新添加的用户信息,选择即可。

11.4.3 立即构建
任务创建成功后即可看到如下页面。在该页面中点击“立即构建”,Jenkins 即可开始从GitLab 上拉取项目。此时左下角就会发生变化。

点击左下角的日期时间,选择控制台输出,可看到这个拉取过程的日志。


从以上日志的 git init /var/jenkins_home/workspace/my_hellojks 命令可以看出,Jenkins将其容器内的/var/jenkins_home/workspace/my_hellojks 目录作为项目的本地仓库。也就是将数据卷目录。进入 jenkins 数据卷可以看到该项目已经存在了。

11.5 将项目打为Jar包
在 Jenkins 能够通过配置,调用本地的 maven 的 mvn 命令,将拉取来的项目打为 Jar 包。
11.5.1 Jenkins 配置 mvn 命令

点击配置后,打开配置页面。然后点击 Build Steps,跳转到以下位置。


选择调用顶层 Maven 目标,即可使用前面配置的 Maven 来完成打包任务。
在 Maven 版本下拉框中选择前面配置好的 maven,目标中写入需要 maven 去执行的maven 命令,应用保存后,自动跳转回任务首页。

clean package -DskipTests
表示先清理,然后打包,打包的时候跳过测试
11.5.2 重新构建
在配置好 maven 的构建命令后,再次执行“立即构建”。


构建成功后进入 jenkins 数据卷目录/var/jenkins_home/workspace/my_hellojks 中可以看到新增了 target 目录。打开 target 目录,可以看到打出的 jar 包。


11.6 代码质量检查
11.6.1 sonar-scanner 手动检测
在 Jenkins 中数据卷目录/var/Jenkins_home 中已经安装过了 sonar-scanner。该目录下的bin 目录中有 sonar-scanner 命令。Jenkins 就是通过调用该命令完成代码质量检测的。

这里先通过手工执行命令方式来体验一下 sonar-scanner 命令完成代码检测的过程。由于配置文件中使用的相对路径都是相对路径,所以若要运行 sonar-scanner 命令对项目进行手工质量检测,就需要在 workspace 的需要检测的项目目录中执行。所以,要么配置全局变量 path,要么直接使用 sonar-scanner 命令的绝对路径。为了简单,采用命令绝对路径方式。
/var/jenkins_home/sonar-scanner/bin/sonar-scanner \
-Dsonar.login=admin \
-Dsonar.password=11111111 \
-Dsonar.projectKey=my_hello_jks
/var/jenkins_home/sonar-scanner/bin/sonar-scanner: 这是SonarScanner可执行文件的路径,用于执行代码质量分析任务。-Dsonar.login=admin: 这是SonarQube服务器的登录凭证,其中”admin”是用户名。-Dsonar.password=11111111: 这是SonarQube服务器的登录凭证,其中”11111111”是密码。请注意,明文存储密码是不安全的,这里只是为了示例目的。-Dsonar.projectKey=my_hello_jks: 这是指定要分析的项目在SonarQube服务器上的唯一标识符。在这里,项目的键(key)被设置为”my_hello_jks”。


看到以下日志,说明检测成功。

此时,在 sonarqube 首页就可看到多出了一个检测项目。

11.6.2 任务中配置 SonarScanner
现在要在 Jenkins 的 my_hellojks 项目中应用 SonarScanner 对其代码进行质量检测。所以需要在该项目中配置 SonarScanner。



11.6.3 重新构建
再重新构建之前,要删除之前手工构建的内容:
如果不删除这个文件,可能自动构建会出错。
再次执行“立即构建”,构建成功后,刷新 SonarQube 页面,便可看到新增了一个项目。

11.7 将jar包推送到目标服务器
11.7.1 配置 SSH
Jenkins 通过 SSH 方式连接上目标服务器,并将 jar 包推送到目标服务器。

点击配置后,打开配置页面。将页面拉到最下面,找到“增加构建后操作步骤”。


target/*.jar表示将当前target下面的所有jar包传入进去
11.7.2 重新构建
在返回的任务首页中,再次执行立即构建。查看日志可以看到连接目标服务器,推送 1个文件的日志。

查看目标服务器的目标目录/usr/local/jenkins(也就是你前面设置的接收目录——7.3节),可以看到 jar 包已经推送了过来

11.8 构建镜像启动容器
通过在 Jenkins 中配置在目标服务器中将要执行的相关命令,使得 Jenkins 将 jar 包推送到目标服务器后,立即自动执行配置的命令,将 jar 包构建为一个镜像,并启动其相应的容器,使项目启动运行。
11.8.1 定义 Dockerfile
若要构建镜像,就需要定义其 Dockerfile。现在 Idea 的工程中新建一个 Directory,例如docker,然后在其中新建一个 file。
FROM openjdk:8u102
LABEL auth="zhangsan" email="zhangsan@163.com"
COPY hellojks-0.0.1-SNAPSHOT.jar /root/hjks/hellojks.jar
WORKDIR /root/hjks
ENTRYPOINT ["java","-jar","hellojks.jar"]
注意:
再进行上传代码之前,要先打包,因为
COPY命令表示将hellojks-0.0.1-SNAPSHOT.jar复制到容器内的/root/hjks/hellojks.jar里面,如果不先打包,就会导致hellojks-0.0.1-SNAPSHOT.jar没有,导致后面会出错

11.8.2 定义 compose.yml
在 idea 的新建目录中再新建一个 compose.yml,用于构建镜像和启动容器。
services:
hellojks:
build: ./
image: hellojks
container_name: myhellojks
ports:
- 8080:8080

11.8.3 推送到 GitLab



11.8.4 再配置构建后操作
重新返回到任务首页,再次对“构建后操作”进行配置。

cd /usr/local/jenkins/docker
mv ../target/*.jar ./
docker-compose down
docker-compose up -d --build
docker image prune -f
docker-compose down:表示停止所有正在运行的容器docker-compose up -d --build:表示先构建镜像,再运行所有容器docker image prune -f:表示删除所有悬虚镜像
这里命令的目的就是要将jar包放到Dockerfile一个目录,然后构建镜像,启动服务。

11.8.5 重新构建
Jenkins 中在返回的任务首页中,再次执行立即构建。构建成功后,查看目标服务器中的 /usr/local/jenkins/ 目录,发现 docker 目录及其下的两个 docker 文件已经存在了,且 jar 包也复制了进来。

在目标服务器中 docker images,可以看到 hellojks 镜像已经生成。

在目标服务器中 docker ps,可以看到容器已经启动了。在浏览器中访问目标服务器中的应用,已经可以访问了。

在浏览器中访问目标服务器中的应用,已经可以访问了。

12. 自由风格的 CI 操作(最终架构)
前面的架构存在的问题是,若有多个目标服务器都需要使用该镜像,那么每个目标服务器都需要在本地构建镜像,形成系统资源浪费。若能够在 Jenkins 中将镜像构建好并推送到 Harbor 镜像中心,那么无论有多少目标服务器需要该镜像,都只需要从 Harbor 拉取即可。
12.1 Jenkins容器化实现
12.1.1 Jenkins 容器化实现方案
有两种方案:
DioD:要容器内部安装Docker引擎DooD:与宿主机共享Docker引擎
12.1.2 修改 docker.sock 权限
/var/run/docker.sock 文件是 docker client 和 docker daemon 在本地进行通信的 socket文件。默认的组为 docker,且 other 用户不具有读写权限,这样 Jenkins 是无法来操作该文件的。

所以这里需要将其组调整为 root,且为其分配读写权限。
chown root:root docker.sock
chmod o+rw docker.sock

12.1.3 修改 Jenkins 启动命令后重启
首先强制删除正在运行的 Jenkins 容器。
docker rm -f jenkins
然后在 Jenkins 启动命令中新增/var/run/docker.sock,docker 命令文件/usr/bin/docker,及/etc/docker/daemon.json 文件为数据卷。重启 Jenkins 容器。
docker run --name jenkins \
--restart always \
-p 8080:8080 \
-p 50000:50000 \
-v /var/jenkins_home:/var/jenkins_home \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/bin/docker:/usr/bin/docker \
-v /etc/docker/daemon.json:/etc/docker/daemon.json \
-d jenkins/jenkins:2.387.3-lts

12.2 构建并推送镜像到Harbor
这里要实现 Jenkins 将来自 GitLab 的 jar 包构建为镜像,并推送到 Harbor。
12.2.1 修改 daemon.json 文件
Jenkins 是 Harbor 的客户端,需要修改/etc/docker/daemon.json 文件。修改后重启 Docker。

12.2.2 Jenkins 删除构建后操作
原来的 Jenkins 中配置的“构建后操作”完成的是将代码推送到目标服务器后,让目标服务器通过 docker compose 完成镜像的构建与启动。但现在不需要了,因为镜像构建任务要由 Jenkins 自己完成了。在 Jenkins 当前任务下的“配置”中删除。


12.2.3 Jenkins 添加 shell 命令
在 sonarqube 对代码质量检测完毕后,再添加一个“构建步骤”。这个构建步骤通过 shell命令方式完成。

mv target/*.jar docker/
docker build -t hellojks docker/
docker login -u admin -p 11111111 192.168.254.131
docker tag hellojks 192.168.254.131/jks/hellojks
docker image prune -f
docker push 192.168.254.131/jks/hellojks
mv target/*.jar docker/: 这个命令假设你当前的工作目录是包含了target和docker目录的位置。它将target目录下的所有 JAR 文件移动到docker目录中。这个命令假设在构建过程中生成的 JAR 文件位于target目录中。docker build -t hellojks docker/: 这个命令告诉 Docker 使用位于docker/目录中的 Dockerfile 来构建一个名为hellojks的镜像。-t参数用于为镜像指定一个标签(tag),即镜像的名称。在这里,我们将镜像命名为hellojks。docker login -u admin -p 11111111 192.168.254.131: 这个命令用于登录到 Docker 远程仓库,以便能够将镜像推送到该仓库。-u参数指定用户名为admin,-p参数指定密码为11111111。192.168.254.131是远程仓库的地址。docker tag hellojks 192.168.254.131/jks/hellojks: 这个命令用于为镜像重新标记一个名称,以便将其与远程仓库中的指定路径关联起来。这里将本地的hellojks镜像标记为192.168.254.131/jks/hellojks。这个操作是为了在推送镜像到远程仓库时,能够将镜像正确定位到远程仓库的位置。docker image prune -f: 这个命令将删除本地无用的镜像,以释放磁盘空间。使用-f参数可以避免在删除时需要确认操作。docker push 192.168.254.131/jks/hellojks: 这个命令将推送标记为192.168.254.131/jks/hellojks的镜像到远程仓库。它会将本地构建的hellojks镜像上传到指定的远程仓库地址

12.2.4 重新构建
Jenkins 中在返回的任务首页中,再次执行立即构建。构建成功后,在 Jenkins 主机中可以查看到构建好的镜像与重 tag 过的镜像。
构建出现以下问题:
表示你刚刚修改了
daemon文件没有重启docker,所以你要重启以下docker,注意,如果你关机了,再开机,那么docker.sock是会被变的

在 harbor 的仓库中也可以看到推送来的镜像。



12.3 通知目标服务器
12.3.1 修改 daemon.json 文件
目标服务器是 Harbor 的客户端,需要修改/etc/docker/daemon.json 文件。修改后重启Docker。


12.3.2 定义脚本文件
在目标服务器 PATH 路径下的任意目录中定义一个脚本文件 deploy.sh。例如,定义在/usr/local/bin 目录下。然后再为其赋予可执行权限。这样该 deploy 命令就可以在任意目录下运行了。
文件内容如下:
harbor_addr=$1
harbor_proj=$2
image_repo=$3
image_tag=$4
app_port=$5
export_port=$6
exist_cont_id=`docker ps -a | grep $image_repo | awk '{print $1}'`
if [ "$exist_cont_id" != "" ] ; then
docker stop $exist_cont_id
docker rm $exist_cont_id
fi
exist_image_tag=`docker images | grep $harbor_addr/$harbor_proj/$image_repo | awk '{print $2}'`
image=$harbor_addr/$harbor_proj/$image_repo:$image_tag
if [[ "$exist_image_tag" =~ "$image_tag" ]] ; then
docker rm -f $image
fi
docker login -u admin -p 11111111 $harbor_addr
docker pull $image
docker run --name $image_repo -dp $export_port:$app_port $image
echo "SUCCESS"
harbor_addr=$1: 将传入的第一个参数赋值给harbor_addr变量,用于指定 Harbor 远程仓库的地址。harbor_proj=$2: 将传入的第二个参数赋值给harbor_proj变量,用于指定 Harbor 仓库的项目。image_repo=$3: 将传入的第三个参数赋值给image_repo变量,用于指定镜像仓库的名称。image_tag=$4: 将传入的第四个参数赋值给image_tag变量,用于指定要拉取的镜像标签。app_port=$5: 将传入的第五个参数赋值给app_port变量,用于指定容器内应用的端口。export_port=$6: 将传入的第六个参数赋值给export_port变量,用于指定要映射到主机的端口。exist_cont_id=$(docker ps -a | grep $image_repo | awk '{print $1}'): 通过docker ps -a命令查找容器的 ID,其中包含了$image_repo的关键词。将结果赋值给exist_cont_id变量。if [ "$exist_cont_id" != "" ]; then ... fi: 如果exist_cont_id变量不为空,则表示已存在具有相同名称的容器。在这种情况下,执行下面的命令来停止和删除已存在的容器。docker stop $exist_cont_id: 停止具有$exist_cont_idID 的容器。docker rm $exist_cont_id: 删除具有$exist_cont_idID 的容器。exist_image_tag=$(docker images | grep $harbor_addr/$harbor_proj/$image_repo | awk '{print $2}'): 通过docker images命令查找具有$harbor_addr/$harbor_proj/$image_repo名称的镜像,并提取镜像的标签。将结果赋值给exist_image_tag变量。image=$harbor_addr/$harbor_proj/$image_repo:$image_tag: 构建一个完整的镜像名称,包括远程仓库地址、项目名称、镜像仓库名称和标签。if [[ "$exist_image_tag" =~ "$image_tag" ]]; then ... fi: 如果exist_image_tag变量中包含了$image_tag,则表示已存在具有相同标签的镜像。在这种情况下,执行下面的命令来删除已存在的镜像。docker rm -f $image: 强制删除具有$image名称的镜像。docker login -u admin -p 11111111 $harbor_addr: 使用用户名 `admin

12.3.3 Jenkins 添加端口号参数
为了使用户可以随时指定容器对外暴露的参数,这里在 Jenkins 当前任务下的“配置”中“参数化构建过程”中添加一个字符参数。



12.3.4 Jenkins 添加构建后操作
还是在 Jenkins 当前任务下的“配置”中,为任务添加构建后操作


这里面的参数,其实就是:
harbor_addr=$1 192.168.254.131 harbor_proj=$2 jks image_repo=$3 hellojks image_tag=$4 latest app_port=$5 8080 export_port=$6 $export_port
12.3.5 重新构建工程
这次重新构建,可以看到出现了 export_port 的文本框。在这里可以修改容器对外暴露的端口号。

构建成功后可以看到,目标服务器中增加了新的镜像,该镜像是从 harbor 拉取的。

还可以看到,该镜像的容器也已经启动。

通过浏览器访问目标服务器的应用,是没有问题的。

13. 自由风格的 CD 操作
现在要为 GitLab 中当前的项目主干分支 origin/master 上的代码打上一个 Tag,例如 v1.0.0。然后修改代码后仍提交到 GitLab 的主干分支 origin/master 上,此时再给项目打上一个 Tag,例如 v2.0.0。这样, hellojenkins 项目的主干分支 origin/master 上就打上了两个 Tag。而 Jenkins 可以根据主干分支 origin/master 上代码的不同 Tag 对项目进行分别构建。实现项目的持续交付与持续部署。
13.1 发布V1.0.0版本
13.1.1 修改代码并推送
简单修改一个 Controller 中方法的返回值。修改代码后,将其推送到 GitLab。

13.1.2 GitLab 中项目打 Tag




13.2 发布V2.0.0版本
13.2.1 修改代码
简单修改一个 Controller 中方法的返回值。将修改后的项目源码提交到 GitLab。

13.2.2 GitLab 中再打 Tag
在 GitLab 中再次为刚提交到主干分支 origin/master 上的代码再打上一个新的 Tag。


13.3 Jenkins配置tag参数
由于 GitLab 中的项目具有 tag 标签,那么 Jenkins 在进行项目构建时就需要让用户选择准备构建哪个 tag 的项目。所以,需要在 Jenkins 中配置一个 Git 参数 tag 作为用户选项。
13.3.1 添加 Git 参数


这里选择的 Git 参数,即为前面下载的 Git Parameter 插件。

13.3.2 添加 checkout 命令
然后当前页面继续下拉,找到 Build Steps。


13.3.3 修改构建命令配置
然后当前页面继续下拉,找到Build Steps中原来添加的构建命令。在所有涉及镜像的命令中添加上$hjtag 变量引用。然后应用保存。

13.3.4 修改 SSH 配置
然后当前页面继续下拉,找到“构建后操作”中的 Send build artifacts over SSH 中的 Exec command,将原来写死的版本 latest 修改为$hjtag。

13.4 部署v1.0.0
13.4.1 重新构建工程
任务首页中再次点击 Build with Parameters 构建项目,发现增加了 hjtag 选项。这里选择v1.0.0 进行构建。

13.4.2 构建结果
构建成功后,在 Jenkins 中可以看到增加了新的镜像。

Harbor 中新增了 v1.0.0 的镜像。

在目标服务器上新增了v1.0.0的镜像,且该容器也运行了起来。

在浏览器上访问到的页面内容也是 v1.0.0 的内容了。

13.5部署v2.0.0


具体步骤和部署v1.0.0一致
14. 流水线任务
注意:
在实际的生产环境下,自由风格的使用的其实并不多,因为它的整个流程太麻烦了,反而是流水线的方式使用的较多
14.1 流水线简介
流水线是 Jenkins 对项目构建过程的一种管理方式。其将项目的构建过程按照构建阶段进行非常清晰的划分显示。用户可以通过可视化操作方式来轻松查看、管理构建过程中的各个阶段。
14.2 HelloWorld
14.2.1 新建流水线任务


14.2.2 Hello World 项目创建与构建


点击立即构建后,就会看到“阶段视图”。

将鼠标放到各个阶段上会显示出 logs,点击 logs 可看到相关的日志。

14.2.3 修改项目脚本
为了更好的理解脚本,这里对 hello workd 项目的脚本进行修改


14.2.4 再次构建
应用保存后,再次立即构建。阶段视图发生较大变化。每个阶段上均可看到相应的日志。

14.3 SCM方式维护脚本
Jenkins 流水线任务提供了两种维护脚本的方式。本地方式与*SCM 方式。在 Jenkins 中维护的方式称为本地方式。
14.3.1 代码中追加 Jenkinsfile
每个要构建的项目采用 piple 方式进行构建管理,要求必须要有一个构建脚本,而采用SCM 脚本维护方式时,默认该脚本文件名为 Jenkinsfile。对于本例,在 Idea 中的项目根目录下追加一个名为 Jenkinsfile 的文件。然后再将原来的脚本内容复制到该文件中。为了显示区别,这里对脚本内容进行了简单修改。

14.3.2 提交修改到 GitLab
将项目的修改追加到 GitLab 中。

然后在 GitLab 的项目首页中就可看到多了一个 Jenkinsfile 文件。然后再复制该项目的http 地址。

14.3.3 Jenkins 配置
在 Jenkins 中流水线任务的“配置”中,流水线选择 SCM 方式,SCM 选择 Git,然后再将刚才复制的 GitLab 仓库地址粘贴到这里。


这里可以看到,文件名默认为 Jenkinsfile。当然,可以更换。应用保存
14.3.4 重新构建
重新立即构建后会发现,除了这些阶段名称更新为了修改过的外,还新增了一个新的阶段 Checkout SCM。即从 SCM 中检出脚本。

14.4 流水线管理hellojks
14.4.1 更新 Jenkinsfile
现要将之前的 hellojks 项目通过流水线方式进行构建管理。所以,首先需要修改 Idea 中的 Jenkinsfile 文件内容,然后再提交到 GitLab。
pipeline {
agent any
stages {
stage('从 GitLab 拉取代码') {
steps {
echo '从 GitLab 拉取代码,成功'
}
}
stage('将项目打为 jar 包') {
steps {
echo '将项目打为 jar 包,成功'
}
}
stage('代码质量检测') {
steps {
echo '代码质量检测,成功'
}
}
stage('构建并推送镜像到 Harbor') {
steps {
echo '构建并推送镜像到 Harbor,成功'
}
}
stage('通知目标服务器') {
steps {
echo '通知目标服务器,成功'
}
}
}
}

14.4.2 重新构建
在 Jenkins 中对 hello_pipeline 任务重新构建。

14.5 从GitLab拉取代码
14.5.1 定义 Git 参数
在 Jenkins 中的 pipeline 任务中定义一个 Git 参数,该参数仍为发布的 tag。


14.5.2 流水线语法
在 pipeline 脚本文件中如何定义具体的命令语句来实现“从 GitLab 位取代码”“将项目打为 jar 包”等任务?pipeline 脚本文件是具有其特殊的语法的。不过,通过当前 pipeline 任务中的流水线语法,可自动生成符合 pipeline 脚本语法的脚本语句。

14.5.3 生成脚本命令
下面要通过流水线语法生成“从 GitLab 拉取代码”的语句。
首先从 GitLab 的项目中复制项目地址。
然后在 Jenkins 的流水线语法中选择“checkout:Check out from version control”,并将复制来的 GitLab 的项目地址粘贴到 Repository URL 中。

点击“生成流水线脚本”,便可以下面的文本框中自动生成相应脚本语句。

14.5.4 更新 Jenkinsfile
复制生成的流水线脚本,并将其写入到 Idea 中的 Jenkinsfile 的相应 stage{}中,并提交到GitLab。

14.5.5 重新构建
对任务进行重新构建,发现可以对构建的版本进行选择了。

构建成功后便可看到,在阶段视图中新增了一层的构建过程。在最上层的“从 GitLab拉取代码”阶段中点击 Logs,便可看到拉取的日志。

14.6 将项目打为jar包
14.6.1 生成脚本命令
在 Jenkins 中通过流水线脚本语法生成“将项目打为 jar 包”的脚本语句

14.6.2 更新 Jenkinsfile
复制生成的流水线脚本,并将其写入到 Idea 的 Jenkinsfile 的相应 stage{}中,提交。

14.6.3 重新构建
对任务进行重新构建,然后便可在最上层的“将项目打为 jar 包”阶段中点击 Logs,便可看到 maven 构建的日志。

14.7 代码质量检测
14.7.1 生成脚本命令
在 Jenkins 中通过流水线脚本语法生成“代码质量检测”的脚本语句。

14.7.2 更新 Jenkinsfile
复制生成的流水线脚本,并将其写入到 Idea 的 Jenkinsfile 的相应 stage{}中,提交。

14.7.3 重新构建
对任务进行重新立构建,然后便可在最上层的“通过 SonarQube 进行代码检测”阶段中点击 Logs,便可看到 SonarQube 代码检测的日志。

然后在 SonarQube 管理页面中就可看到新增加了一个 hello_pipeline 的项目了。

14.8 构建镜像并推送到Harbor
14.8.1 Jenkinsfile 中定义环境变量
在 Idea 中的 Jenkinsfile 文件中添加环境变量,这些变量将在后面生成的脚本命令中使用。

14.8.2 生成脚本命令
在 Jenkins 中通过流水线脚本语法生成“推送镜像到 Harbor”的脚本语句。脚本语句中使用的是 Jenkinsfile 中定义的环境变量。

有点小问题,这里的版本不是使用
${ptag},应该写${htag},因为我前面写的就是htag
14.8.3 更新 Jenkinsfile
复制生成的流水线脚本,并将其写入到 Idea 的 Jenkinsfile 的相应 stage{}中,提交。

14.8.4 重新构建
对任务进行重新立构建,然后便可在最上层的“构建镜像并推送到 Harbor”阶段中点击 Logs,便可看到推送镜像到 Harbor 的日志。

此时在 Jenkins 中就可看到出现了 hello_pipeline 的镜像。

此时查看 harbor 的管理页面,可以看到在 jks 项目中新增加了 hello_pipeline 的仓库,且仓库中具有 v2.0.0 的镜像。

14.9 通知目标服务器执行deploy脚本
14.9.1 添加端口号参数
为了使用户可以随时指定容器对外暴露的参数,这里在 Jenkins 当前任务下的“配置”中“参数化构建过程”中添加一个字符参数。



14.9.2 生成脚本命令
在 Jenkins 中通过流水线脚本语法生成“通知目标服务器执行 deploy 脚本”的脚本语句。选择 sshPublisher:Send build artifacts over SSH,并从中找到目标服务器。

14.9.3 更新 Jenkinsfile
复制生成的流水线脚本,并将其写入到 Idea 的 Jenkinsfile 的相应 stage{}中,提交

原本生成的脚本中的 deploy.sh 命令是使用单引号括起来的,需要将这里的单引号更改为双引号。否则这些变量无法完成引用。

14.9.4 重新构建
对任务进行重新构建,然后便可在最上层的“通知目标服务器”阶段中点击 Logs,便可看到推送镜像到 Harbor 的日志。

查看目标服务器中的镜像,发现相应镜像已经从 harbor 上拉取了下来。

查看正在运行的容器,发现应用已经启动。

到此,通过 pipeline 进行项目构建已经全部完成。现在可以在浏览器上访问应用了。
15. 添加钉钉提醒
这里要为流水线管理方式添加钉钉提醒功能。
15.1 钉钉端操作
15.1.1 创建项目群
首先需要在钉钉中创建一个项目群。



15.1.2 添加机器人
在项目群中添加一个自定义机器人,让该机器人进行项目构建提醒。








复制该 Webhook,后面在 Jenkins 配置时需要使用。

添加完毕后,就可看到机器人在群里发布的加入消息。
15.2 Jenkins系统配置
15.2.1 插件下载
在 Jenkins 中下载 DingTalk 插件。


15.2.2 Jenkins 配置
在 Jenkins 的系统管理中可找到“钉钉”,这是安装过 DingTalk 后出现的。



15.2.3 项目配置
打开项目的“配置”,在 General 中可以看到前面配置的钉钉机器人,点击该机器人的“高级”。



15.3 重新构建
15.3.1 构建成功
对任务进行重新构建。

构建结束后,钉钉的项目群中会看到机器人发出的消息。

15.3.2 构建失败
随便将脚本中的某数据修改错,然后提交到 GitLab。

重新构建后会出错

同时也会在钉钉项目群中看到机器人发出的消息。
