我遇到的情况是,所有开发人员都在dev分支中工作,并且仅将所有提交推送到该dev分支。一位网守将查看这些更改并将其合并到master分支。
在詹金斯,我有一份工作是由推送到master分支触发的。我想设置一个构建后操作,检查构建是否失败,然后将电子邮件发送给开发者,该开发者的推入dev分支导致构建失败,而不是将电子邮件发送给合并了开发者的电子邮件的关守更改为master分支并触发了构建。我该怎么做?
答案 0 :(得分:2)
这是我们遵循的以下过程,建议使用与此类似的过程:
1)仅允许从PR合并到Develop分支
所有开发人员更改仅应通过PR-Pull请求推送到dev分支。配置方式应使通过的检查最少,以允许PR合并进行开发。
这样,将验证将要在开发分支中合并的所有更改,并且开发人员有责任确保清除支票以进行合并,而不必再为网守感到头疼。
添加快照以供参考。
更新:Git流策略
来源:https://nvie.com/posts/a-successful-git-branching-model/?
2)定义管道和多分支
如果您已经在CI / CD中使用管道和Multibranch插件,那么上述步骤将很容易。如果不是,那么这些都是应该是CI / CD的理想插件。
一些参考资料:
https://jenkins.io/doc/book/pipeline/
https://wiki.jenkins.io/display/JENKINS/Pipeline+Multibranch+Plugin
https://jenkins.io/doc/tutorials/build-a-multibranch-pipeline-project/
更新:通过多分支管道项目类型,您可以为同一项目的不同分支实现不同的Jenkins文件。在多分支管道项目中,詹金斯自动发现,管理和执行分支代码的管道,这些分支的源代码管理中包含Jenkinsfile
。
有关创建多分支管道的信息,请参见此处:https://jenkins.io/doc/book/pipeline/multibranch/
GitHub Organization Folder使Jenkins能够监视整个GitHub组织,并自动为包含分支的存储库创建新的Multibranch Pipelines和包含Jenkinsfile的拉取请求。
3)启用emailext
此处的示例代码片段将向提交代码的开发人员触发通知。
emailext(
subject: "Build ${env.JOB_NAME} - ${currentBuild.displayName} ${currentBuild.result}",
body: """Build ${currentBuild.result}
${env.JOB_URL}
""",
recipientProviders: [[$class: 'DevelopersRecipientProvider']]
)
此处描述了变量currentBuild
的更多选项:https://qa.nuxeo.org/jenkins/pipeline-syntax/globals#currentBuild
Emailext插件:https://wiki.jenkins.io/display/JENKINS/Email-ext+plugin
https://jenkins.io/doc/pipeline/steps/email-ext/
希望这在一定程度上有所帮助。