Jenkins制品管理（下）

四.拷贝制品

在某些场景下，我们需要从另一个pipeline中拷贝制品，Copy Artifact插件 可以帮助我们实现

1. steps {
2. copyArtifacts(
3. projectName: "core",
4. selector: lastSuccessful(true)
5. )
6. }

从core项目中拿到最后一次构建成功的制品 参数：

• projectname :字符串类型，Jenkins job或pipeline名称
• selector : BuildSelector类型，从另一个pipeline中拷贝制品的选择器，默认拷贝最后一个制品
• parameters :字符串类型，使用逗号分隔的键值对字符串( name1=value1 , name2=value2 )，用于过滤从哪些构建中拷贝制品
• filter:字符串类型，Ant风格路径表达式，用于过滤需要拷贝的文件
• excludes:字符串类型，Ant风格路径表达式，用于排除不需要拷贝的文件
• target:字符串类型，拷贝制品的目标路径，默认为当前pipeline的工作目录
• optional:布尔类型，如果为true，则拷贝失败，但不影响本次构建结果
• fingerprintArtifacts:布尔类型，是否对制品进行签名，默认值为true
• resultVariableSuffix :上例中，无法得知我们到底拿的是core项目的哪次构建的制品。Copy Artifact插件的设计是将其构建次数放到一个环境变量中。这个环境变量名就是在COPYARTIFACT BUILDNUMBER后拼上resultVariableSuffix，比如resultVariableSuf fix值为corejob，那么就在pipeline 中通过变量COPYARTIFACT BUILDNUMBER corejob拿到源pipeline的构建次数了。

除projectname参数是必填的外，其他参数都是可选的。

常用的获取选择器的方法

• lastSuccessful:最后―次构建成功的制品。方法签名为lastSuccessful ( boolean stable )。stable为true表示只取构建成功的制品，为false表示只要构建结果比UNSTABLE好就行。
• specific:指定某一次构建的制品。方法签名为specific(StringbuildNumber)。buildNum ber表示指定取第n次构建的制品
• lastCompleted:最后一次完成构建的制品，不论构建的最终状态如何。方法签名为lastCompleted()
• latestSavedBuild:最后一次被标记为keep forever的构建的制品。方法签名为latestSavedBuild()

五.版本号

谈到制品，就必须谈到版本号的管理。版本号的制定并没有所谓的行业标准。比如谷歌浏览器当前版本号为70.0.3538.110 ; Ubuntu操作系统当前版本号为18.10;由美国计算机教授高德纳(DonaldErvin Knuth )编写的功能强大的排版软件TEX系统的版本号不断趋近于T，类似于这样:3.1415926。

GitHub提出了一种具有指导意义、统一的版本号表示规则，称为Semantic Versioning (语义化版本表示)。这也被人们称为三段式版本号。有了这套规则，用户一看版本号，就大概能猜到一个软件两个版本之间的可能变化。

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

• 主版本号:当作了不兼容的API修改时。
• 次版本号:当作了向下兼容的功能性新增时。·修订号:当作了向下兼容的问题修正时。
• 修订号：当作了向下兼容的问题修正时

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

• alpha :内部版本
• beta :测试版本
• rc:即将作为正式版本发布
• lts :长期维护

语义化版本号的好处是除了方便人类识别，也方便软件识别。比如Ansible提供的版本比较器的使用:{{ansible distribution version isversion ( ‘12.04’,’>=’)}。这也是很多开源软件使用语义化版本号的原因。

但是，语义化版本号真的适用于所有的场景吗?不一定。我们需要根据版本号的作用来确定软件版本号的格式。说白了，你希望别人一眼从版本号里看出什么，你就怎么确定版本号。

那么，谁看这个版本号?软件的真正使用者根本不关心软件版本号。不过，现实中各种App强制大版本，对于市场营销的确有好处。企业软件的销售人员是要看版本号的。他必须知道不同版本之间的功能区别，以更好地完成其工作。

移动端App的产品经理是要看版本号的。他必须知道当前最新版本与上一个版本的区别，以及市面上都运行了哪些版本。当用户提交Bug时，产品经理可以根据用户所装的版本进行决策。

程序员是要看版本号的。版本号意味着软件运行时的源码版本。有了这个对应关系，对于查Bug、了解线上业务逻辑的运行都是非常有用的。

对于版本号的不同诉求，决定了它的作用。笔者总结，可以从以 下两个角度来设计版本号。 1.方便表达。对于更接近使用者的软件，更倾向于这个角度，比如三段式版本号。所以，推荐前端应用使用三段式版本号。 2.方便找出制品与源码的关系。对于更接近软件源码的人，更倾向于这个角度，比如Go CD的版本号:18.10.0( 7703-42d1cbe661161b5400289ead86c0447c84af8cOa )。除了三段式版本号，还会有构建次数及相应的代码提交ID。推荐后端服务使用Go CD的这种版本号格式。

现实中，如何设计版本号才能做到既方便表达，又方便找出制品与源码的关系呢?采用内外部版本号策略就可以了。对外部，可以使用1.0.1这样的版本号;对内部，可以使用1.0.1.20180911.12.42d1cbe66116这样的版本号。最后要做的事情就是，想办法将内外部版本对应上就可以了。

Version Number

Version Number ( https”//plugins.jenkins.io/versionnumber )是一款用于生成版本号的插件，它提供了VersionNumber步骤。

具体使用方法如下:

script {   
 def version = VersionNumber versionPrefix: "${JOB_NANE}-", versionNumberString: 'v1.1.1.${BUILDS_ALL_TIME}'  
 echo "${version}"
 }

注意:BUILDS ALL TIME只是占位符，并不是Jenkins或VersionNumber插件提供的环境变量。

VersionNumber步骤支持以下参数。

• versionNumberString :字符串类型，版本号格式，用于生成版本号。只能使用单引号，以防格式中的占位符被转义。版本号格式支持多种占位符。
• versionPrefix:字符串类型，版本号的前缀
• projectStartDate :字符串类型，项目开始时间，格式为yyyy-MM-dd，用于计算项目开始后的月数和年数
• worstResultForlncrement :字符串类型，如果本次构建状态比上一次构建状态更糟糕，则BUILDS_TODAY、BUILDS_THIS_WEEK、BUILDS_THIS_MONTH、BUILDS_THIS_YEAR占位符的值不会增加。worstResultForlncrement可以设置的值有sUCCESs.UNSTABLE、FAILURE、ABORTED、NOT_BUILT(默认)。此参数较少使用

versionNumberString参数使用占位符生成版本号。部分占位符本身支持参数化。接下来分别介绍它们

• BUILD DATEFORMATTED∶格式化的构建日期，支持参数化，如${BUILD DATE FORMATTED , “yyyy-MM-dd”}
• BUILD DAY:构建日期，支持×和XX参数。比如是12月2日，${BUILD DAY}将返回2，${BUILD DAY，X}将返回2，${BUILDDAY，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 THIS MONTH、BUILDS THISYEAR，它们分别表示当天、本星期、本月、本年完成的构建数。BUILDS ALL TIME表示自从项目开始后完成的总构建数。

MONTHS SINCE PROJECT START和YEARS SINCE PROJECT START分别表示自项目开始日期起已过去的日历月数和年数。