如何从多个Gitlab存储库中触发一个Jenkins作业?

时间:2018-02-16 18:02:05

标签: jenkins groovy gitlab pipeline devops

我在gitlab上有10个存储库。通过电子书,我可以触发詹金斯的工作。现在我有一个Jenkins管道作业,它将使用存储库中的jenkinsfile。当另一个存储库将触发此作业时,将始终使用已配置的存储库。我如何以这种方式配置Jenkins,我只有一个或两个Jenkins作业,可以处理多个存储库,但只会构建触发Jenkins作业的存储库。

1 个答案:

答案 0 :(得分:3)

您要求CI / CD反模式。在考虑在多个存储库之间共享相同的Jenkins作业时,您必须注意多个问题,例如。

  • 一次只能构建一次(想象一下,单个作业平均需要5分钟,10个存储库在同一个20分钟的时间窗口内推送更改,第10个存储库推送必须等待直到所有先前的作业都完成,同时推送新的提交并且您的构建队列增长和增长)
  • 您拥有以前版本的单一历史记录(假设您在历史记录中有200个版本,而第5个版本仅在少数版本中使用 - 您将如何找到它?)
  • 你得到虚假的增量开发感觉(想象你的8或9个存储库总是通过所有测试并留下绿色管道,只有少数,1或2个不时失败而离开你的管道红色 - 当您查看以前构建的历史记录时,您如何知道哪个存储库被破坏?您没有看到8或9个存储库始终处于良好状态)
  • 您无法自定义每个存储库的行为(在这种情况下很明显)

相反,最好使用Jenkins' Pipeline as a Code方法,每个存储库都有自己的Jenkinsfile,每个存储库都有一个指向存储库Jenkinsfile的专用作业。您可以并行构建所有存储库,每个存储库都有一个干净的历史记录,如果需要,您可以为每个管道定义自定义步骤。

利用Jenkins图书馆

如果要为所有存储库指定公共基础,并且希望将其放在一个位置,请考虑extending your pipeline with shared libraries。这在实践中意味着什么?您可以按文档中的描述定义库脚本,例如

乏/ standardBuild.groovy

// See https://github.com/jenkinsci/workflow-cps-global-lib-plugin

// The call(body) method in any file in workflowLibs.git/vars is exposed as a
// method with the same name as the file.
def call(body) {
    def config = [:]
    body.resolveStrategy = Closure.DELEGATE_FIRST
    body.delegate = config
    body()
    node {
        stage('checkout') {
            checkout scm
        }
        stage('main') {
            docker.image(config.environment).inside {
                sh config.mainScript
            }
        }
        stage('post') {
            sh config.postScript
        }
    }
}

然后你的Jenkinsfile使用standardBuild函数(它使用相同的名称作为脚本名称):

#!groovy

// Loads the standardBuild function/step from workflowLibs.git/vars/standardBuild.groovy
// and invokes it.
standardBuild {
    environment = 'golang:1.5.0'
    mainScript = '''
go version
go build -v hello-world.go
'''
    postScript = '''
ls -l
./hello-world
'''

来源:https://github.com/jenkinsci/pipeline-examples/tree/master/global-library-examples/global-function

这种方法允许您在所有作业之间共享共同行为,并且在必须在单个管道中实现自定义特定内容时仍然可以自由地使用。

结论 - 不要遵循反模式。这可能听起来像是一个很好的解决方案(在多个存储库中单独工作在理论上需要较少的工作量),但事实并非如此。它会导致多个问题,阻止您进行扩展,并使CI / CD管道在从CI服务器接收快速反馈时无用。