在Jenkins的多分支流水线中,是否有办法使用git子模块中的Jenkinsfile?

209次阅读
没有评论

问题描述

项目源代码包含多个长期存在的分支,每个分支都有自己的Jenkins任务(手动创建)。
不幸的是,用户没有使用多分支流水线来组织项目,因为当需要对流水线进行更改时,需要手动将更改添加到每个长期存在的分支的Jenkinsfile中。
用户将Jenkinsfile存储在一个单独的存储库(称为ci-repo)中,并将其作为子模块添加到项目的存储库(称为dev-repo)中。
用户需要手动监视dev-repo的分支并管理作业的创建。多分支流水线支持检出源文件的子模块,但是分支发现需要在父存储库(在我们的例子中是dev-repo)下存在Jenkinsfile。
问题是:Jenkinsfile来自多分支流水线的git子模块 – 有办法做到这一点吗?也许在dev-repo中使用一个初始/模拟的Jenkinsfile,在其中调用子模块的Jenkinsfile?Jenkinsfile是否可以在运行时被覆盖或替换?

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

根据回答1,你可以使用共享库来实现你的需求。共享库可以实现流水线,使得所有的Jenkinsfile看起来都是一样的。你可以参考Jenkins官方文档中关于共享库的介绍。以下是一个示例共享库的代码:

def call(body) {
    // 将配置收集到pipelineParams对象中
    pipelineParams= [:]
    body.resolveStrategy = Closure.DELEGATE_FIRST
    body.delegate = pipelineParams
    body()
    pipeline {
        agent {
            label pipelineParams.nodes
        }
        options {
            buildDiscarder(logRotator(artifactNumToKeepStr: '1', numToKeepStr: '10'))
            disableConcurrentBuilds()
            timestamps()
            timeout(time: pipelineParams.timeout, unit: 'MINUTES')
        }
        stages {
            stage('Build') {
                steps {
                    // 执行构建步骤
                }
            }
        }
    }
}

然后,在你的dev项目中的Jenkinsfile中加载这个共享库,并使用共享库中的pipeline来定义流水线:

import org.apache.commons.io.FileUtils

library identifier: 'shared-pipeline-library@master', retriever: modernSCM(
  [$class: 'GitSCMSource',
   remote: 'https://bitbucket/jenkins/hared-pipeline-library.git',
   credentialsId: 'bitbucket.service.user'
  ])

commonpipeline {
    nodes = 'BUILD' /* jenkins节点的标签 */
    timeout = '60'
}

方案2

根据回答2,你可以将”devops基础设施逻辑”(放在ci-repo中)与触发流水线的Jenkinsfile分离开来。Jenkinsfile中包含”devops基础设施逻辑”作为一个标记的构件。这种方法的优点是你可以在一个集中的地方开发(和测试)devops代码,并且当变更是向后兼容时,可以通过移动标记来更新所有的流水线。当变更不向后兼容时,可以逐步将存储库和特定分支移动到新的标记。如果需要的话,特定的存储库和分支可以创建自己的流程。
这种方法的缺点是,有时人们需要在多个地方更新Jenkinsfile,因为他们接受了新版本。但是,这样做实际上是有好处的。

方案3

根据回答3,使用子模块可能无法实现你的想法。当Jenkins多分支流水线轮询SCM以触发新的构建时,它无法看到子模块。作者最近验证了这一点。在”扫描多分支流水线日志”中的结果是”Communication error for url”的响应。Jenkinsfile未找到,因此没有触发构建。
好消息是,作者发现了一种简单的方法来实现我们的目标,而无需使用子模块。可以使用”Remote Jenkinsfile Provider Plugin”来实现。当流水线轮询存储库以触发新的构建时,它会查找每个分支的两个条件:
1. 被轮询的分支与上次构建时有新的SCM更改(HEAD不同)。
2. 存储库X的分支Y下的路径Z存在Jenkinsfile。
在多分支流水线的”构建配置”部分,通常只有一种模式可用于告诉Jenkins在哪里找到Jenkinsfile:”通过Jenkinsfile”。这种模式允许我们仅指定路径Z;X和Y会隐式地设置为正在轮询的存储库和分支。
“Remote Jenkinsfile Provider Plugin”给我们提供了一种新的构建配置模式:”通过Remote Jenkins File Plugin”。这种模式允许我们显式地设置Jenkinsfile的存储库、分支和路径 – X、Y和Z。在你的例子中,X将是ci-repo,但不需要ci-repo是dev-repo的子模块,只要Jenkinsfile在指定的位置存在即可。
如果需要,”Match branches”选项使用”轮询的分支名称”作为Y,查找同名分支上的”远程”Jenkinsfile。例如,在轮询dev-repo/feature-123时,它将在ci-repo/feature-123上查找Jenkinsfile。
只要Jenkinsfile存在于指定的位置,就会满足触发新构建的第二个条件。在流水线的轮询日志中,你将看到类似下面的内容:

Looking up DR/dev-repo for branches
Checking branch master from DR/dev-repo
No local file defined. Skipping Source Code SCM probe, since Jenkinsfile will be provided by Remote Jenkins File Plugin
Met criteria
Scheduled build for branch: master

有关如何设置的说明,请参见插件页面上的说明
需要注意的是,将更改推送到”远程”Jenkinsfile(ci-repo)不会触发轮询存储库(dev-repo)的任何构建。如果需要此行为,一种解决方案是使用webhook。另一种解决方案是创建一个轮询”远程”Jenkinsfile存储库并使用build step构建其他流水线作业的流水线,例如:

build(job: "dev-repo/${BRANCH_NAME}", wait: false)

以上是三种解决方案,你可以根据你的需求选择适合你的方案。

正文完