如何讓git功能分支與jenkins-workflow一起工作？

我正在嘗試安裝jenkins-workflow來執行我們的集成測試。我們的集成測試是這樣工作的：如何讓git功能分支與jenkins-workflow一起工作？

有人在git的功能分支中對LibraryA進行了更改。我們希望jenkins針對功能分支中的代碼運行單元測試，然後我們希望將此功能分支中的代碼安裝到client1和client2（它們是LibraryA的用戶）並運行測試。

我能夠設置一個工作流程來完成除LibraryA的功能分支的正確提交之外的所有操作。相反，我的設置只是從LibraryA的某個（看似隨機）分支中提交一個提交。

我們有很多功能分支，因此在工作流程設置中對特定分支進行硬編碼並不合適。似乎應該有一些方法來獲取觸發工作流作業的提交的散列（即使使用SCM輪詢）。

我的設置是這樣的：

currentBuild.setDisplayName("#" + env.BUILD_NUMBER) 

node { 
    git credentialsId: '033df7f1-7752-46bd-903d-8a70e613eed0', url: '[email protected]:mycompany/myrepo.git' 
    sh ''' 
echo `git rev-parse HEAD` > libraryA_version.txt 
sudo docker run --rm=true -e LANG=en_US.UTF-8 -a stdout -i -t mycompany/libraryA run_tests 
''' 
    archive 'libraryA_version.txt' 
} 

def integration_jobs = [:] 

integration_jobs[0]={ 
    node{ 
    ws { 
     unarchive mapping: ['libraryA_version.txt':'.'] 
     sh 'sudo docker run -t --rm mycompany/client1:v1 bash run_tests.sh "`cat libraryA_version.txt`"' 
    } 
    } 
} 

integration_jobs[1] = { 
    node{ 
    ws { 
     unarchive mapping: ['libraryA_version.txt' : '.'] 
     sh 'sudo docker run -t --rm mycompany/client2 run_tests.sh "`cat libraryA_version.txt`" ' 
    } 
    } 
} 

parallel integration_jobs

所以，我現在的問題是，我怎麼能安裝git的回購/輪詢來得到正確的承諾，在第一次測試運行，這將在libraryA_version.txt使用在隨後的測試中？

另外，我應該以完全不同的方式去了解這個過程嗎？

來源

2015-07-10 Robert

您正在尋找的功能是每分支構建，並且我認爲它應該通過適合目的的插件來實現。

分支在git中完成。
Jenkins必須複製構建或構建管道作業以適應分支並能夠構建和測試分支。
重新集成後，git必須通知詹金斯，詹金斯必須關閉工作。

我發現這個插件：

https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

而且這個插件/教程：

http://entagen.github.io/jenkins-build-per-branch/

的實施在很大程度上取決於您的情況，所以我不能更具體。我只是說挑戰是：

建設詹金斯可以同時獨立運行的工作。
使用Jenkins作業的模板。
處理Jenkins和git之間的事件。

你的情況：

建設的全過程從前面傳遞管道結束。
如果有人分支一個步驟並實現一個功能，然後複製整個管道並運行整個管道。
得到這個工作，然後改進。

來源

2015-07-11 11:48:37 blacklabelops

這就是我害怕的。我們是這樣開始的。我們有一個可以工作的多作業工具鏈，但它具有不可取的特性。它不符合我們的回購協議，因爲我們有太多的工作要管理。失敗通知和肇事者不能很好地工作。跨作業的設置很笨拙。這就是jenkins-workflow插件很好的原因 - 整個集成鏈的設置是一個相當緊湊的工作。 – Robert

然後讓我們回答你原來的問題，這裏是jenkins job env變量的列表：https：//wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project。在你的情況下，GIT_COMMIT和GIT_BRANCH應該是你在構建工作流時需要的信息。 – blacklabelops

我在工作的頂部打印出我的環境變量，這些變量不可用。顯然，jenkins-workflow作業不會設置這些GIT變量。「下面的變量是當前工作流腳本中不可用： EXECUTOR_NUMBER NODE_NAME NODE_LABELS 工作區 SCM-特定變量如SVN_REVISION」 – Robert

由於@maybeg暗示，你最有可能尋找的是一個多分支項目，可通過安裝管道：多枝。這可讓您在Jenkinsfile中定義腳本，該腳本只需在您的構建中調用checkout scm一次或多次，即可避免需要libraryA_version.txt。

與此同時，我還在想你的項目設置。您的git步驟使用的默認值爲branch: 'master'，這意味着它應該只在master分支上開始輪詢，並且只檢查此分支。 Git插件相當複雜，所以這可能會以某種方式破壞。等待正確的多分支支持，你總是可以使用checkout步驟與GitSCM步驟配置爲使用通配符分支規範，在這種情況下，將選擇以前沒有構建的任意分支頭結帳，並且你的git-rev-parse技巧（我想你獨立地重新發現瞭解決方法爲JENKINS-26100）應該按原樣工作。

來源

2015-07-21 14:48:31

好的，所以爲了反思，在工作流作業中，配置scm輪詢在提交時觸發作業，然後使用帶有通配符分支（**）的'checkout'步驟。它會選擇一個頭部尚未構建的分支，理想情況下是觸發作業的提交分支？ – Robert

對，不能保證所選的頭部提交將成爲觸發原因，但很可能。不知道如果在一個輪詢會話中發現多個合格的負責人會發生什麼情況 - 它可能會觸發多個構建，儘管每次使用SCM輪詢（包括'/ git/notifyCommit' webhook）明智的做法是在日程表中添加'@ daily' /'@ hourly'來捕獲任何錯誤的提交。同樣，使用即將推出的多分支工作流程，這一切都變得更加簡單：每個分支都有自己的子項目，並且符號「checkout scm」可能會被使用≥1次以獲得匹配的結賬。 –

我可以在Jenkins ver下使用新的Pipeline作業插件來使用'branch：'production''命名法。 1.634。 – MarkHu

如何讓git功能分支與jenkins-workflow一起工作？

回答

相關問題