jenkins的制品管理

制品是什么？

也叫产出物或工件。制品是软件开发过程中产生的多种有形副产品之一。广义的制品包括用例、uml图、设计文档等。而狭义的制品就可以简单地理解为二进制包。虽然有些代码是不需要编译就可以执行的，但是我们还是习惯于将这些可执行文件的集合称为二进制包。

制品管理仓库

最简单的制品管理仓库就是将制品统一放在一个系统目录结构下。但是很少有人这样做，更多的做法是使用现成的制品库。

制品管理涉及两件事情：一是如何将制品放到制品库中；二是如何从制品库中取出制品。

目前现成的制品库有：nexus、artifactory。（nexus经常被用来搭建maven私有仓库）

docker安装nexus

查找镜像

$ docker search nexus

下载镜像

$ docker pull sonatype/nexus3

启动容器

docker run -d --name nexus3 \
 --restart=always \
-p 8081:8081 \
-p 8082:8082  \
-p 8083:8083  \
-p 8084:8084  \
-p 8085:8085   \
-v /opt/nexus-data:/nexus-data \
sonatype/nexus3

archiveartifacts制品管理

archiveartifacts步骤能对制品进行归档，然后你就可以从jenkins页面上下载制品了，如图

jenkinsfile内容如下：

archiveartifacts的参数

• artifacts（必填）：字符串类型，需要归档的文件路径，使用的是ant风格路径表达式。

• fingerprint（可选）：布尔类型，是否对归档的文件进行签名。

• excludes（可选）：字符串类型，需要排除的文件路径，使用的也是ant风格路径表达式。

• casesensitive（可选）：布尔类型，对路径大小写是否敏感。

• onlyifsuccessful（可选）：布尔类型，只在构建成功时进行归档。

archiveartifacts步骤并不只用于归档jar包，事实上，它能归档所有类型的制品。

管理java栈制品

1. 使用maven发布制品到nexus中

   maven deploy插件能将jar包及pom文件发布到nexus中

   

   使用deploy插件发布需要以下几个步骤。

   （1）配置发布地址。在maven项目的pom文件中加入：

   

   deploy插件会根据maven项目中定义的version值决定是使用nexus-snapshot仓库还是nexus-release仓库。当version值是以-snapshot后缀结尾时，则发布到nexus-snapshot仓库。

   （2）配置访问nexus的用户名和密码。在nexus中，我们配置了只有授权的用户名和密码才能发布制品。这时需要在maven的settings.xml中加入配置：

   

2. 使用nexus插件发布制品

   安装nexus platform插件

   （1）进入manage jenkins→configure system→sonatype nexus页，设置nexus 3.x的服务器地址，如图

   

   • 在“credentials”选项处，增加了一个具有发布制品到nexus中的权限的用户名和密码凭证。

   • server id字段的值，在jenkinsfile中会引用。

   设置完成后，单击“test connection”按钮测试设置是否正确。

   （2）在jenkinsfile中加入nexuspublisher步骤。

   

   ​ nexuspublisher的参数介绍：

   ​ • nexusinstanceid：在jenkins中配置nexus 3.x时的server id。

   ​ • nexusrepositoryid：发布到nexus服务器的哪个仓库。

   ​ • mavencoordinate：maven包的坐标，packaging值与maven中的packaging值一致，可以是jar、war、pom、hpi等。

   ​ • mavenassetlist：要发布的文件，如果是pom.xml，则extension必须填“xml”。

   此插件的缺点：

   ​ • 每个maven项目都可能不同，必须为每个maven项目写nexuspublisher方法。

   ​ • 对于多模块的maven项目，nexuspublisher的参数写起来十分啰唆。

使用nexus管理docker镜像

1. nexus：创建docker私有仓库

   进入nexus的仓库列表页：administration→repository→repositories，单击“docker（hosted）”

   

   指定docker私有仓库提供http服务的端口为8595。私有仓库的地址为：http：//＜ip>：8595。

   

2. 创建docker私有仓库凭证

   将镜像推送到docker私有仓库是需要用户名和密码的。我们不能将密码明文写在jenkinsfile中，所以需要创建一个“username with password”凭证。

3. 构建并发布docker镜像

   当私有仓库创建好后，我们就可以构建docker镜像并发布到仓库中了。假设dockerfile与jenkinsfile在同一个目录下，我们看一下jenkinsfile的内容。

   

   ​ withdockerregistry步骤做的事情实际上就是先执行命令：docker login-u admin-p********http：：8595。其间，所生成的config.json文件会存储在工作空间中。然后再执行闭包内的命令。

   将镜像推送到nexus中后，在nexus中可以看到如图

   

   注：由于是私有的非安全（http）的仓库，所以需要配置docker的daemon.json。

   

nexus raw制品管理

​ raw仓库可以被理解为一个文件系统，我们可以在该仓库中创建目录。

1. 创建raw仓库

   进入administration→repository→repositories页

   

   单击“raw（hosted）”，进入raw仓库创建页。

   输入仓库名称“raw-example”，单击“create repository”按钮，确认后创建成功。该仓库的地址是：＜你的nexus地址>/repository/raw-example/。

   

2. 上传制品，获取制品

使用http客户端就可以将制品上传到raw仓库中。我们使用linux curl命令。

（1）在jenkins上添加“username with password”凭证，如图所示。

（2）在jenkinsfile中加入上传制品的步骤。

curl命令的格式为：

如果目录不存在，nexus将会自动创建

3. 在jenkins pipeline中获取原始制品时，我们同样使用curl命令。

   

从其他pipeline中拷贝制品

1. 安装copy artifact插件

2. 代码：从core项目中拿到最后一次构建成功的制品。

copyartifacts步骤的参数详解：

​ • projectname（必填）：字符串类型，jenkins job或pipeline名称。

​ • selector：buildselector类型，从另一个pipeline中拷贝制品的选择器，默认拷贝最后一个制品。

​ • parameters：字符串类型，使用逗号分隔的键值对字符串（name1=value1，name2=value2），用于过滤从哪些构建中拷贝制品。

​ • filter：字符串类型，ant风格路径表达式，用于过滤需要拷贝的文件。

​ • excludes：字符串类型，ant风格路径表达式，用于排除不需要拷贝的文件。

​ • target：字符串类型，拷贝制品的目标路径，默认为当前pipeline的工作目录。

​ • optional：布尔类型，如果为true，则拷贝失败，但不影响本次构建结果。

​ • fingerprintartifacts：布尔类型，是否对制品进行签名，默认值为true。

​ • resultvariablesuffix：上例中，无法得知我们到底拿的是core项目的哪次构建的制品。copyartifact 插件的设计是将其构建次数放到一个环境变量中。这个环境变量名就是在copyartifact build number 后拼上resultvariablesuffix，比如resultvariablesuf fix值为corejob，那么就在pipeline中通过变量copyartifact build number corejob拿到源pipeline的构建次数了。

​ 几种常用的获取选择器：

• lastsuccessful：最后一次构建成功的制品。方法签名为lastsuccessful（boolean stable）。stable为true表示只取构建成功的制品，为false表示只要构建结果比unstable好就行。

• specific：指定某一次构建的制品。方法签名为specific（string buildnumber）。buildnum ber表示指定取第n次构建的制品。

• lastcompleted：最后一次完成构建的制品，不论构建的最终状态如何。方法签名为lastcompleted（）。

• latestsavedbuild：最后一次被标记为keep forever的构建的制品。方法签名为latestsavedbu ild（）。

版本号管理

语义化版本格式为：主版本号.次版本号.修订号。版本号递增规则如下：

• 主版本号：当作了不兼容的api修改时。

• 次版本号：当作了向下兼容的功能性新增时。

• 修订号：当作了向下兼容的问题修正时。

先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。以下是常用的修饰词。

• alpha：内部版本。

• beta：测试版本。

• rc：即将作为正式版本发布。

• lts：长期维护。

方便生成版本号的version number插件

versionnumber步骤支持以下参数。

• versionnumberstring：字符串类型，版本号格式，用于生成版本号。只能使用单引号，以防格式中的占位符被转义。版本号格式支持多种占位符，稍后介绍。

• versionprefix：字符串类型，版本号的前缀。

• projectstartdate：字符串类型，项目开始时间，格式为yyyy-mm-dd，用于计算项目开始后的月数和年数。

• worstresultforincrement：字符串类型，如果本次构建状态比上一次构建状态更糟糕，则builds_today、builds_this_week、builds_this_month、builds_this_year占位符的值不会增加。worstresultforincrement可以设置的值有success、unstable、failure、aborted、not_built（默认）。此参数较少使用。versionnumberstring参数使用占位符生成版本号。部分占位符本身支持参数化。接下来分别介绍它们。

• build date formatted：格式化的构建日期，支持参数化，如${build dateformatted，"yyyy-mm-dd"}。

• build day：构建日期，支持x和xx参数。比如是12月2日，${build day}将返回2，${build day，x}将返回2，${build day，xx}将返回03。

• build week：今年构建的星期数，支持x和xx参数。

• build month：今年构建的月数，支持x和xx参数。

• build year：今年构建的年份。

比如构建的时间为2018-12-02，那么build_day的值为2，build_week的值为49，build_month的值为12，build_year的值为2018。

接下来是一组和构建数相关的占位符：builds today、builds this week、builds thismonth、builds this year，它们分别表示当天、本星期、本月、本年完成的构建数。

builds all time表示自从项目开始后完成的总构建数。months since project start和years since project start分别表示自项目开始日期起已过去的日历月数和年数。