【持续集成】[Jenkins]Job中如何传递自定义变量

时间 2019-12-12

原文原文链接

[Jenkins]Job中如何传递自定义变量

来自dweiwei 2015-06-27 18:37:19| 分类：自动化测试 |举报 |字号大中小订阅 html

最近在使用jenkins中踩了很多雷。Jenkins做为CI第一大神器，拥有庞大的1058个扩展插件。也许你要的答案就在里面，可是若是没有好好学习，她也可能把你搞的生活没法自理~~理想是丰满的现实是骨干的，因为楼主没有好好学习，本文中用到的一些费劲和曲折方法确定不是正道！都说真理每每是简捷的，还请路过的大神指点。

场景一: Job构建步骤间的变量传递

Jenkins提供了数十种构建方式，咱们以最经常使用的『Execute shell』为例。有时为了使Job中的复杂的构建流程更加清晰咱们配置多个构建步骤像下面这样。图中包含两个构建步骤，步骤2须要根据步骤1中的返回值来判断是否执行操做:

[Jenkins]Job中如何传递自定义变量 - 网易杭州QA - 网易杭州 QA Team

执行时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插件