爲什麼Jenkins Git插件在被SCM工具觸發時使用舊參數值

Question

我們在推送到幾個Git存儲庫後使用Jenkins構建服務器來構建我們的軟件。

因爲我們去了一些代碼的重組最近，我試圖建立一個更復雜的構建流水線，建設我們的每個產品（一個Git倉庫的每個）在它們的依賴性的順序。

每個作業觸發後續項目的建設工作經過$GIT_BRANCH下一個作業的執行。

整個管道工作得很好，我開始了第一個項目的建設origin/master和項目2，3和4得到建立主。我從另一個分支開始，隨後的項目切換到這個分支。

我使用Git的參數插件做科選擇並將其傳遞到Git的分支裁判。默認值是一個空字符串。

不幸的是，這整個設置打破了Gitblit的推送鉤。雖然詹金斯仍然報告說具體項目被觸發來檢查SCM，但只有在提交被選擇用於上一次手動構建的分支中時，構建纔會開始。

檢查Git輪詢日誌我看到只有先前選擇的分支檢查了更改。

從我這一切我猜的還是基本的瞭解，使SCM調查觸發使用最後一個「已知」值，參數不將默認值。這是Jenkins，插件還是我的配置中的一個錯誤。其他人是否已經完成了這種兩用管道？

編輯：我想 「**」 爲默認值，同樣的結局。

Answer 1

我發現一個不太乾淨的問題解決方案。我增加了進一步的構建工作，除了坐在SCM上並且之後觸發真正的項目外，什麼都不做。他們將「構建」的GIT提交ID傳遞給下一個作業。

下面是一個例子：

projectA_trigger 
    Freestyle Project 
    GIT Repository configured 
    Build triggert by SCM 
    Post-Build-Action Trigger parameterized build of projectA, submit built GIT commit ID 
projectA 
    Maven-Project 
    GIT repository configured 
    Build NOT triggered by SCM 
    Post-Build-Action Trigger parameterized build of projectB... 

我創建了一個觸發項目，每前主體工程，現在SCM改變觸發建立在正確的樹枝和使用管道。

雖然有效，但感覺有點冒險，所以如果你有更好的解決方案，請讓我知道。