【持续集成】[Jenkins]Job中如何传递自定义变量
2023-09-27 14:25:07 时间
[Jenkins]Job中如何传递自定义变量
来自dweiwei 2015-06-27 18:37:19| 分类: 自动化测试 |举报 |字号大中小 订阅
最近在使用jenkins中踩了不少雷。Jenkins作为CI第一大神器,拥有庞大的1058个扩展插件。也许你要的答案就在里面,但是如果没有好好学习,她也可能把你搞的生活无法自理~~理想是丰满的现实是骨干的,由于楼主没有好好学习,本文中用到的一些费劲和曲折方法肯定不是正道!都说真理往往是简捷的,还请路过的大神指点。
本次要分享的内容就这么多。
场景一: Job构建步骤间的变量传递
Jenkins提供了数十种构建方式,我们以最常用的『Execute shell』为例。有时为了使Job中的复杂的构建流程更加清晰我们配置多个构建步骤像下面这样。图中包含两个构建步骤,步骤2需要根据步骤1中的返回值来判断是否执行操作:
执行时jenkins将两个构建步骤生成两个shell文件,然后分别调用。
do_build_step_1
[Jenkins] $ /bin/bash -xe /tmp/hudson1270042613896791809.sh
do_build_step_2
[Jenkins] $ /bin/bash -xe /tmp/hudson5918908417824291692.sh
理论上两个shell之间是无法通信的,step1执行完之后变量$dostep2就会被回收,要注意试图在step1中通过export或者其他脚本方式注入环境变量都是无效的。
解决方案:读写文件
要实现它们之间的变量传递只能通过读写文件的方式。我们有一个真实应用场景是这样的,配置由git push触发编译任务,但是并不是每一次git的提交都需要触发编译,比如说只有前端代码的提交其实并不影响编译的结果,我们只好在step1中加入判断来却确定step2是否真的有必要被执行。
场景二: Job之间的变量传递
现在有两个Project『run_compile』和『run_deploy』,代码编译成功后开始执行环境部署。不需要传递参数的情况下可以选择“Build other projects“的方式。
需要传递参数则需要选择"Trigger parameterized build on other projects"的方式。
Jenkins Parameterized Trigger plugin可以实现Job间参数传递但是有局限性,我们只能选择传递当前build的参数或者环境变量。 (例:$GIT_COMMIT是git plugin提供的一个变量,存着当前build触发时最新的git code.) 如果要传递一个自定义的变量怎么办呢? 构建步骤中的自定义变量在执行结束后都会被回收,我们不可能在"predefined parameters"中取到。
依旧以编译任务为例,前端代码的提交不需要触发编译,没有编译也就不需要执行接下来的『run_ut』单元测试。(泛指后台代码的UT, JS UT这种稀有存在暂不考虑)
如何将编译的状态告诉下游的单元测试呢?
聪明的你想起了场景一的解决办法。对,我们也可以通过读写文件的方式来解决这个问题嘛!
不过这里我不推荐大家采用这种方式,理由有两点:
一,『run_compile』和『run_ut』有可能被部署在不同slave上,如果考虑更加智能的CI配置方式会在构建时动态的选择空闲的slave去执行,这种文件读写的方式就有了很大的局限性;
二,很难确保文件传递的准确性,如果『run_compile』写入文件失败,『run_ut』中读到的就是一个旧值一个不准确的值。
解决方案一:通过properties file的方式传递参数。
首先将变量以"xx=xx"的样式写入到配置文件『propfile.txt』中。
然后在"Trigger parameterized build on other projects"中选择"Parameters from preperties file",在propfile里写入多个变量就可以传递多个值。
建议勾选"Don't trigger if any files are missing"和删除旧文件配合使用。
最后在『run_ut』中可以直接获取这个变量来使用了。
解决方案二: 通过EnvInject Plugin插件
EnvInject Plugin可以支持修改、注入和删除环境变量。
我们在构建中增加步骤"Inject environment variables", 将写在配置文件中的变量${IFUT},注入到环境变量里。
这样在"Trigger parameterized build on other projects"就可以直接选择"predefined parameters"方式直接传递变量了。同样的在Job『run_deploy』里就可以直接访问变量${IFUT}了。
最后有一个槽点:
为什么jenkins不支持根据条件判断来决定是否触发下一个Project呢?
实际上我最希望的是当ifut=false的时候就直接不触发『run_ut』,『run_ut』不被触发也就省去了不少无用功。
参考资料:
相关文章
- python爬虫Jenkins编译失败的日志
- 一文学会jenkins pipline自动化构建
- Jenkins 中 shell 脚本执行失败却不自行退出
- 持续集成:jmeter+ant+jenkins搭建接口自动化测试环境
- 自动化集成:Jenkins管理工具详解
- Jenkins 集成 SonarQube Scanner
- 使用Jenkins来实现内部的持续集成流程(下)
- 使用Jenkins做持续集成,这个知识点必须要掌握
- Python接口测试实战之Git及Jenkins持续集成
- Jenkins学习笔记第九篇pipeline 接口自动化持续集成测试
- jenkins学习笔记第十七篇 -Jenkins·将一个 Github 项目打包后上传到远程服务器
- K8S构建Jenkins持续集成平台
- 【持续集成和交付】Jenkins环境搭建:Jenkins介绍、下载安装
- 05-jenkins与SonarQube代码审查集成
- jenkins权限配置
- jenkins持续集成工具
- Redhat上为java Maven项目构建基于Jenkins + Github的持续集成环境
- Jenkins持续集成实战之解决windows搭建jenkins执行selenium无法启动浏览器
- Jenkins持续集成实战之Jenkins+Ant+Jmeter构建接口自动化持续集成平台
- 浅析持续集成/持续部署(CI/CD)及如何使用 jenkins 自动部署
- jenkins自动化构建流程篇章二 :jenkins任务的创建
- jenkins 集成产品 产品: jira 禅道 测试 :sonaqube 开发:gitllab
- jenkins部署
- Jenkins docker 一键发布 (二)
- jenkins之从0到1利用Git和Ant插件打war包并自动部署到tomcat(第三话):创建一个自由风格的项目(非maven),实现自动打war包