如何实现多团队代码仓库共用单份中心化Jenkinsfile

完全可行，不需要各业务团队在自有仓库存放Jenkinsfile，有两种成熟的原生实现方式：

方案1：任务配置直接指定公共仓库为Jenkinsfile源 #

这是改造成本最低的方式，不需要额外开发插件或封装逻辑：

• 在Jenkins上为各业务团队创建流水线（含多分支流水线）任务时，流水线定义选择Pipeline script from SCM
• SCM地址填写你存放通用配置的Common公共仓库地址，指定脚本路径为根目录下的jenkinsfile
• 任务的代码触发源、分支发现规则仍然配置为对应业务团队的仓库地址，保证业务代码提交、MR发起时能正常触发构建

执行逻辑上，你只需要在公共仓库的Jenkinsfile里提前写好配置合并规则：

1. 构建启动后先加载Common仓库内的config.json、x.json作为通用默认配置
2. 自动拉取触发本次构建的业务仓库代码到工作目录
3. 按业务仓库的实际目录结构，读取对应路径下的同名差异化配置文件，覆盖默认配置的同名字段
4. 用合并完成的最终配置执行后续CI步骤

这种模式下业务仓库只需要按约定结构存放业务代码和自己的配置文件即可，完全不需要放Jenkinsfile相关内容，只需要给Jenkins服务账号开通仓库读权限就行。

方案2：搭配Jenkins共享库做能力沉淀 #

如果后续通用CI逻辑会持续迭代、场景越来越复杂，推荐把通用逻辑封装为Jenkins共享库：

• 把Common仓库注册为Jenkins全局可信共享库，将通用CI步骤、配置加载逻辑、标准化流程都封装到共享库中
• 公共仓库可以只保留一个极简的入口Jenkinsfile，甚至可以把入口逻辑也内置到共享库中
• 配置流水线任务时可以直接调用共享库封装好的标准流水线模板，连指定远程Jenkinsfile路径的步骤都可以简化

配置合并的逻辑可以直接内置在共享库中，对所有业务线统一生效，后续要调整通用CI流程只需要更新公共仓库/共享库的代码，不需要通知所有业务团队改自己仓库的配置。

落地注意事项 #

• 公共仓库的Jenkinsfile和通用配置一定要做版本管控，不要让所有业务线默认拉取主分支最新版本，建议通过tag做版本标记，业务团队可以按需选择适配自己的版本，避免通用逻辑变更意外影响线上构建
• 配置合并逻辑要做好容错，如果业务仓库对应路径下没有自定义配置，直接使用默认配置即可，不要因为缺配置文件导致构建失败
• 提前给Jenkins服务账号配置好所有仓库的拉取权限，避免出现拉取公共仓库或业务仓库代码时报权限错误

简单的配置合并逻辑伪代码参考（写在Jenkinsfile里即可）：

// 加载公共默认配置
def finalConfig = readJSON file: "${commonRepoPath}/config.json"
def defaultXConfig = readJSON file: "${commonRepoPath}/x.json"
finalConfig.xConfig = defaultXConfig

// 遍历业务仓库下的所有服务目录，加载对应差异化配置
def serviceDirs = findFiles(glob: "**/config.json")
serviceDirs.each { dir ->
  if (fileExists("${dir.path}/x.json")) {
    def customX = readJSON file: "${dir.path}/x.json"
    // 合并自定义配置，覆盖默认值
    finalConfig.xConfig.putAll(customX)
  }
  def customConfig = readJSON file: dir.path
  finalConfig.putAll(customConfig)
}

内容的提问来源于stack exchange，提问作者kain666