如何在Jenkins Pipeline中构建两个GitHub仓库及处理触发与输出协调

针对R1、R2任意仓库的master/branch-A分支有推送时触发整体构建，有以下几种可行方案：

1. 单个Pipeline拉取双仓库，配置多源触发 #

• 在Jenkins Pipeline的SCM配置中，添加两个GitHub仓库的源，分别指定需要监控的分支（master或branch-A）。
• 给R1和R2各自配置GitHub Webhook，推送事件指向该Jenkins实例的触发地址，确保任意仓库的指定分支有代码推送时，能触发Pipeline运行。
• 在Pipeline脚本里，用checkout步骤分别拉取两个仓库的代码到不同目录，避免代码覆盖：

  checkout([$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'https://github.com/xxx/R1.git']]])
  dir('R2') {
      checkout([$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'https://github.com/xxx/R2.git']]])
  }
  

  后续即可基于两个目录的代码执行整体构建逻辑。

2. 用GitHub Organization Folder统一管理触发 #

• 创建一个GitHub Organization类型的Jenkins项目，将R1和R2都纳入其中，配置监控master和branch-A分支。
• 当任意仓库的目标分支有推送时，会触发对应分支的Multibranch Pipeline。如果需要整体构建，可再创建一个聚合Pipeline，设置为依赖R1和R2对应分支的Pipeline完成后自动启动，或者在聚合Pipeline里主动拉取两个仓库的代码进行构建。

3. 双Webhook指向同一个通用Pipeline #

• 给R1和R2分别配置GitHub Webhook，都指向同一个Jenkins Pipeline的触发URL。
• 在Pipeline脚本中，通过解析Webhook传递的参数（比如仓库名称、分支名）确认变动来源，然后拉取该仓库的最新代码，同时拉取另一个仓库的对应分支代码，执行整体构建。

如果为R1、R2分别创建独立Pipeline，可通过以下方式协调两者的输出：

1. Jenkins归档与产物复制 #

• 每个Pipeline构建完成后，用archiveArtifacts步骤将自身的输出产物（比如编译后的二进制文件、配置包等）归档：

  archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
  

• 在需要整合输出的Pipeline中，使用copyArtifacts步骤从另一个Pipeline的构建历史中拉取归档产物，注意匹配对应分支：

  copyArtifacts projectName: 'R1-Pipeline', selector: specific('branch-A'), filter: 'target/*.jar', target: 'R1-output'
  

2. 外部存储共享输出 #

• 两个Pipeline构建完成后，将输出上传到统一的外部存储（比如NFS目录、本地共享磁盘），按分支+仓库名划分存储路径，例如/shared/builds/branch-A/R1/、/shared/builds/branch-A/R2/。
• 负责整体整合的流程（可以是第三个Pipeline，或者其中一个Pipeline的后续步骤）从外部存储的对应路径拉取两个仓库的输出，进行后续处理。

3. Pipeline依赖与触发协调 #

• 创建一个主Pipeline作为整体构建的入口，它会主动触发R1和R2的对应分支Pipeline，等待两者都完成后再处理输出：

  def r1Build = build job: 'R1-Pipeline', parameters: [string(name: 'BRANCH', value: 'branch-A')], wait: true
  def r2Build = build job: 'R2-Pipeline', parameters: [string(name: 'BRANCH', value: 'branch-A')], wait: true
  // 从r1Build、r2Build中获取构建产物信息，进行后续整合
  

• 或者在R1、R2的Pipeline中，构建完成后主动触发主Pipeline，传递自身的分支信息和产物路径，由主Pipeline完成协调。

内容的提问来源于stack exchange，提问作者Paweł Kamiński