05 GitHub Repo通过Jenkinsfile接入到Jenkins

目前完成02-04的jenkins及其配置后，我们现在可以通过Jenkinsfile来接入到我们的Jenkins中了，此文档简单介绍如何接入Jenkins。

先决条件

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

• 顺利的跑完所有node的可用性测试

  
  
  

  node可用性测试

• 确保你的Github Repo的根目录有Jenkinsfile，并且你的agent { label "node-team-n" }的label为开发团队指定的label，并了解Jenkinsfile的编写，更多Jenkinsfile参考以下链接：
  Jenkinsfile参考Jenkinsfile
  Pipeline语法参考：syntax
  Docker handling in Jenkinsfile: https://jenkins.io/doc/book/pipeline/docker/

• 当前此测试已有的有label如下：

TEAM	LABEL	NAMESPACE	NOTE
test team1	node-team1	node-team1	apk add --upgrade docker sudo shadow git python py-pip curl libcurl nss
test team2	node-team2	node-team2	apk add --upgrade docker sudo shadow git python py-pip curl libcurl nss maven
test team3	node-team3	node-team3	apk add --upgrade docker sudo shadow git python py-pip curl libcurl nss
test team4	node-team4	node-team4	apk add --upgrade docker sudo shadow git python py-pip curl libcurl nss perl

引用label的语法如下：

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

【SRE】创建不同team的Github Organization文件夹

以node-team1为例

node-team1-github-org-folder.gif

最终我们是有不同的folder，然后每个开发组都应该在自己的folder内配置或者接入自己组内的GitHub Repos

image.png

【开发者】新Repo接入到Jenkins中

Jenkins 地址: 请从03 Jenkins master安装（在Kubernetes平台上）获取
以node-team1为例，我们向其中添加新repo，名为jenkins-test

1. 请按照“先决条件”章节来编写新Repo的Jenkinsfile文件，并且确保此文件是放在Repo的根目录下
2. 打开jenkinsUrl，并进入到对应team的目录，以下以node-team1为例。
3. 进入node-team1那个目录，然后点击配置
   
   

   image.png
4. 把repo的名字依次写入到Filter by name的输入框
   jenkins-test|jenkins-test2|jenkins-tes3

image.png

5. 点击保存项目即可，稍后我们会发现在node-team1的目录下会多出jenkins-test的新项目
   
   

   image.png

当一个repo接入到Jenkins中，发生了什么

1. GitHub organization会自动的扫描组织(当前测试的是george-sre)下的所有repo，扫描所有Filter by name (with regular expression)的配置部分的repo，如果任何的branch或者PR中有Jenkinsfile，那么会为其配置相应的任务并自动触发，其他为出现在配置中的repo都自动ignore

2. Jenkins会通过webhook插件https://github.com/george-sre/jenkins-master/blob/master/script/init.groovy.override#L29配置repo的webhook，为后续自动trigger配置好webhook功能

可以通过查看repo的settings->Webhooks查看

image.png

3. 后续的repo发生任何的变化都会通过webhook传送到jenkins中并触发相应的动作，包括及不限以下几种：

• git push触发build
• 新branch会自动创建branch类型的job
• 新PR会自动创建PR类型的job
• [optional]配置git tag触发的job
• [optional]配置按照名字正则表达式来决定是否处罚的job

查看Jenkins Job的结果

1. 可以在Jenkins主页找到具体项目的job查看
2. 可以通过如下位置的github commit status状态链接查看
   
   

   commit status

3. 详细结果界面（Ocean blue）

   
   
   

   Ocean Blue

关于Jenkins Pipeline和GitHub交互的几点说明

• 目前我们尽量保持Jenkins和GitHub交互的模式和CircleCI一致
  默认GitHub organization配置
  Discover branches: Exclude branches that are filed as PRs (当前分支test-branch-1, test-branch-2如果已经开了PR, PR-20, PR-21，那么当前分支的job test-branch-1, test-branch-2会被disable掉)

  
  
  

  branch job disabled when PR created

如果删除“Discover branches”配置，那么默认不会有“Pull Requests”分类的Job出现。

• 第一次PR的时候有可能出现两个Build Checks, branch那个直接引用之前的job build result，continuous-integration/jenkins/pr-merge 会起一个新的Job build。如果我们有后续的提交到这个PR，后面branch类型的job会被disable掉，所有的build都只会在continuous-integration/jenkins/pr-merge中build，不会出现重复build。

pr-merge or branch build

• 极端情况：如果我们的PR开了以后并没有后续的commit，那么我们PR中确实会有两个build check。并且branch的build因为种种原因没有通过build，只有continuous-integration/jenkins/pr-merge通过build check
  我们应该保证continuous-integration/jenkins/pr-merge是OK的，而且可以在GitHub设置中设置merge条件

  
  
  

  merge条件

问题

• 如果新接入的repo没有出现在node-team的文件夹中，可以通过查看Scan Organization Log来看一下是扫描的结果

参考

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

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

更多

• 回到Jenkins系列目录

云平台开发运维解决方案@george.sre

个人主页：https://geekgoogle.com

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

Mail: [email protected]

: georgesre -

欢迎交流～