【持續集成】[Jenkins]Job中如何傳遞自定義變量

[Jenkins]Job中如何傳遞自定義變量  

來自dweiwei   2015-06-27 18:37:19|  分類： 自動化測試 |舉報 |字號大中小 訂閱

       

用微信  “掃一掃”

將文章分享到朋友圈。

 

用易信  “掃一掃”

將文章分享到朋友圈。

 

  下載LOFTER 我的照片書  |

 

 

最近在使用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』不被觸發也就省去了不少無用功。

 

參考資料：

http://qa.blog.163.com/blog/static/190147002201552752915399

http://blog.csdn.net/wangmuming/article/details/22925599

http://www.ithao123.cn/content-7153665.html

http://www.ibm.com/developerworks/cn/java/j-lo-jenkinsintegrate/

http://www.360doc.com/content/14/1121/15/10058718_426936481.shtml

http://my.oschina.net/ghm7753/blog/371954?p=1

https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin

http://www.07net01.com/linux/Jenkinsshiyongjingyantan4_chuangjianJob__662274_1382442168.html