目前完成02-04的jenkins及其配置后，我們現(xiàn)在可以通過(guò)Jenkinsfile來(lái)接入到我們的Jenkins中了，此文檔簡(jiǎn)單介紹如何接入Jenkins。

先決條件

• 完成02-04的Jenkins及其配置

• 順利的跑完所有node的可用性測(cè)試

  
  
  node可用性測(cè)試

• 確保你的Github Repo的根目錄有Jenkinsfile，并且你的agent { label "node-team-n" }的label為開發(fā)團(tuán)隊(duì)指定的label，并了解Jenkinsfile的編寫，更多Jenkinsfile參考以下鏈接：
  Jenkinsfile參考Jenkinsfile
  Pipeline語(yǔ)法參考：syntax
  Docker handling in Jenkinsfile: https://jenkins.io/doc/book/pipeline/docker/

• 當(dāng)前此測(cè)試已有的有l(wèi)abel如下：

引用label的語(yǔ)法如下：

pipeline {
 
    agent { label "<your-team-label>" } // Change to your own team's node, like "node-team1", "node-team2"
 
    stages {
        stage('Test Stage') {
            steps {
                sh 'printenv'
                sh 'pwd'
            }
        }
.....

【SRE】創(chuàng)建不同team的Github Organization文件夾

以node-team1為例

node-team1-github-org-folder.gif

最終我們是有不同的folder，然后每個(gè)開發(fā)組都應(yīng)該在自己的folder內(nèi)配置或者接入自己組內(nèi)的GitHub Repos

image.png

【開發(fā)者】新Repo接入到Jenkins中

Jenkins 地址: 請(qǐng)從03 Jenkins master安裝（在Kubernetes平臺(tái)上）獲取
以node-team1為例，我們向其中添加新repo，名為jenkins-test

1. 請(qǐng)按照“先決條件”章節(jié)來(lái)編寫新Repo的Jenkinsfile文件，并且確保此文件是放在Repo的根目錄下
2. 打開jenkinsUrl，并進(jìn)入到對(duì)應(yīng)team的目錄，以下以node-team1為例。
3. 進(jìn)入node-team1那個(gè)目錄，然后點(diǎn)擊配置
   
   image.png
4. 把repo的名字依次寫入到Filter by name的輸入框
   jenkins-test|jenkins-test2|jenkins-tes3

image.png

5. 點(diǎn)擊保存項(xiàng)目即可，稍后我們會(huì)發(fā)現(xiàn)在node-team1的目錄下會(huì)多出jenkins-test的新項(xiàng)目
   
   image.png

當(dāng)一個(gè)repo接入到Jenkins中，發(fā)生了什么

1. GitHub organization會(huì)自動(dòng)的掃描組織(當(dāng)前測(cè)試的是george-sre)下的所有repo，掃描所有Filter by name (with regular expression)的配置部分的repo，如果任何的branch或者PR中有Jenkinsfile，那么會(huì)為其配置相應(yīng)的任務(wù)并自動(dòng)觸發(fā)，其他為出現(xiàn)在配置中的repo都自動(dòng)ignore

2. Jenkins會(huì)通過(guò)webhook插件https://github.com/george-sre/jenkins-master/blob/master/script/init.groovy.override#L29配置repo的webhook，為后續(xù)自動(dòng)trigger配置好webhook功能

可以通過(guò)查看repo的settings->Webhooks查看

image.png

3. 后續(xù)的repo發(fā)生任何的變化都會(huì)通過(guò)webhook傳送到j(luò)enkins中并觸發(fā)相應(yīng)的動(dòng)作，包括及不限以下幾種：

• git push觸發(fā)build
• 新branch會(huì)自動(dòng)創(chuàng)建branch類型的job
• 新PR會(huì)自動(dòng)創(chuàng)建PR類型的job
• [optional]配置git tag觸發(fā)的job
• [optional]配置按照名字正則表達(dá)式來(lái)決定是否處罰的job

查看Jenkins Job的結(jié)果

1. 可以在Jenkins主頁(yè)找到具體項(xiàng)目的job查看
2. 可以通過(guò)如下位置的github commit status狀態(tài)鏈接查看
   
   commit status

3. 詳細(xì)結(jié)果界面（Ocean blue）

   
   
   Ocean Blue

關(guān)于Jenkins Pipeline和GitHub交互的幾點(diǎn)說(shuō)明

• 目前我們盡量保持Jenkins和GitHub交互的模式和CircleCI一致
  默認(rèn)GitHub organization配置
  Discover branches: Exclude branches that are filed as PRs (當(dāng)前分支test-branch-1, test-branch-2如果已經(jīng)開了PR, PR-20, PR-21，那么當(dāng)前分支的job test-branch-1, test-branch-2會(huì)被disable掉)

  
  
  branch job disabled when PR created

如果刪除“Discover branches”配置，那么默認(rèn)不會(huì)有“Pull Requests”分類的Job出現(xiàn)。

• 第一次PR的時(shí)候有可能出現(xiàn)兩個(gè)Build Checks, branch那個(gè)直接引用之前的job build result，continuous-integration/jenkins/pr-merge 會(huì)起一個(gè)新的Job build。如果我們有后續(xù)的提交到這個(gè)PR，后面branch類型的job會(huì)被disable掉，所有的build都只會(huì)在continuous-integration/jenkins/pr-merge中build，不會(huì)出現(xiàn)重復(fù)build。

pr-merge or branch build

• 極端情況：如果我們的PR開了以后并沒(méi)有后續(xù)的commit，那么我們PR中確實(shí)會(huì)有兩個(gè)build check。并且branch的build因?yàn)榉N種原因沒(méi)有通過(guò)build，只有continuous-integration/jenkins/pr-merge通過(guò)build check
  我們應(yīng)該保證continuous-integration/jenkins/pr-merge是OK的，而且可以在GitHub設(shè)置中設(shè)置merge條件

  
  
  merge條件

問(wèn)題

• 如果新接入的repo沒(méi)有出現(xiàn)在node-team的文件夾中，可以通過(guò)查看Scan Organization Log來(lái)看一下是掃描的結(jié)果

參考

https://jenkins.io/doc/book/pipeline/syntax/

https://github.com/george-sre/jenkins-test

更多

• 回到Jenkins系列目錄

云平臺(tái)開發(fā)運(yùn)維解決方案@george.sre

個(gè)人主頁(yè)：https://geekgoogle.com

GitHub: https://github.com/george-sre

Mail: george.sre@hotmail.com

簡(jiǎn)書: georgesre - 簡(jiǎn)書

歡迎交流～