05 GitHub Repo通过Jenkinsfile接入到Je
目前完成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 "<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】创建不同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
- 请按照“先决条件”章节来编写新Repo的Jenkinsfile文件，并且确保此文件是放在Repo的根目录下
- 打开jenkinsUrl，并进入到对应team的目录，以下以node-team1为例。
- 进入
node-team1那个目录，然后点击配置
image.png
- 把repo的名字依次写入到
Filter by name的输入框
jenkins-test|jenkins-test2|jenkins-tes3
image.png
- 点击保存项目即可，稍后我们会发现在
node-team1的目录下会多出jenkins-test的新项目
image.png
当一个repo接入到Jenkins中，发生了什么
-
GitHub organization会自动的扫描组织(当前测试的是george-sre)下的所有repo，扫描所有
Filter by name (with regular expression)的配置部分的repo，如果任何的branch或者PR中有Jenkinsfile，那么会为其配置相应的任务并自动触发，其他为出现在配置中的repo都自动ignore -
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
- 后续的repo发生任何的变化都会通过webhook传送到jenkins中并触发相应的动作，包括及不限以下几种：
- git push触发build
- 新branch会自动创建branch类型的job
- 新PR会自动创建PR类型的job
- [optional]配置git tag触发的job
- [optional]配置按照名字正则表达式来决定是否处罚的job
查看Jenkins Job的结果
- 可以在Jenkins主页找到具体项目的job查看
- 可以通过如下位置的github
commit status状态链接查看
commit status
-
详细结果界面（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
更多
云平台开发运维解决方案@george.sre
GitHub: https://github.com/george-sre
欢迎交流～
