Archives : February-2021

问题描述
在 Jenkins Pipeline 中,使用 Groovy 语言进行共享库的开发。从理论上讲,我们可以按照需求,开发我们想要的任何功能。但是,现实中总会遇到一些棘手的问题。比如这次遇到的 Dependency hell – 我们在共享库中,通过 Grape 引入我们需要的模块,这些模块又依赖于其他模块,然而这些模块与 Jenkins 正在使用的模块冲突。
比如,我们需要使用 [[https://github.com/ThStock/docker-java-parser|ThStock/docker-java-parser]] 模块解析 Dockerfile 文件,以检[……]

Read more

问题描述
在 Jenkins Pipeline 中,通过 currentBuild.changeSets 变量,我们可以获取仓库文件的变更记录,比如哪些代码文件发生修改,并进行某些特定操作。
比如,文件 fileA.txt 发生变更时,我们将进行某些特殊测试操作。但是,该方案存在以下场景(问题):
(1)当文件fileA.txt发生变更时,我们将进行某些操作,但是由于环境配置错误而导致构建操作失败。
(2)当我们修改环境配置后,重新触发构建(手动触发或者其他方式)。
(3)此时,由于仓库并未变更,因此已经检测不到文件fileA.txt发生变更。因为变更属于上一次构建。[……]

Read more

问题描述
在 Jenkins Pipeline 中,我们的构建将产生各种新文件,在而后的构建又会使用这些文件。
但是 Jenkins 的构建目录并不总是在同一个目录中、也不能保持不变: 1)当作业被重命名之后,构建目录也会发生变更。它会新建与作业同名的构建目录,而不是重命名旧的构建目录,因此无法读取旧的制品; 2)对于相同作业,有时会创建 JOB_NAME@2、JOB_NAME@3 等形式的构建目录(我们没有深究内部实现),导致新构建无法在当前目录读取之前的制品; 3)多项目之间共享制品时,由于构建是 Jenkins 内部实现,未来有可能发生变更,因此我们不能“直接地”读取主机中[……]

Read more

问题描述
我们希望在本次构建中存储状态(变量),以用于下次构建。
该笔记将记录:在 Jenkins Pipeline 中,如何持久化变量,以在下次构建时取回。
解决方案
在本地构建中,直接将变量存储到 env(环境变量中):

this.env[“key”] = “value”

在构建结束时,Jenkins 会自动存储。
在新一轮的构建中,我们可以从前一轮的环境变量中取回该值:

def env = this.currentBuild.previousBuild.getBuildVariables()
println en[……]

Read more