GitHub多依赖仓库Jenkins差异化构建顺序与去重配置方案咨询

第一步：建立标准化的依赖元数据存储 #

• 先给所有20个仓库录入两份独立的依赖关系：
  • 第一份是编译依赖链：记录当前仓库编译阶段直接引入的依赖对应下游仓库，对应你提到的深蓝色依赖线，这类依赖变更会直接触发当前仓库+当前仓库所有编译下游的构建
  • 第二份是provided依赖校验链：记录对当前仓库为provided scope的依赖对应下游仓库，对应浅蓝色依赖线，这类依赖变更仅需要触发当前仓库本身的构建校验，不需要继续向下传递
• 依赖关系可以直接存在Jenkins全局变量中，或者存为JSON配置文件托管在专用配置仓库，每次构建前拉取最新配置即可，参考格式如下：

{
  "repoA": {
    "compile_downstream": ["B"],
    "provided_downstream": []
  },
  "repoB": {
    "compile_downstream": ["D"],
    "provided_downstream": []
  },
  "repoE": {
    "compile_downstream": [],
    "provided_downstream": ["B"]
  }
}

第二步：配置批量变更的聚合触发逻辑 #

• 用GitHub Organization Folders插件批量对接所有仓库，开启推送事件触发，设置5分钟的合并窗口期：同一窗口期内收到的所有仓库推送变更，会合并为一个构建批次处理，避免零散触发
• 批次处理第一步先根据变更仓库列表，结合依赖元数据，计算完整的待构建列表和依赖顺序：
  1. 遍历所有变更仓库，先收集所有provided依赖的下游：这些仓库仅加入待构建列表，不需要再遍历它们的下游
  2. 再遍历所有变更仓库，收集所有编译依赖的下游：这些仓库加入待构建列表，同时递归遍历它们的编译下游直到末端
  3. 对待构建列表去重，避免重复构建
• 最后用有向无环图（DAG）排序工具算出构建顺序，保证所有上游仓库构建完成后再启动下游构建

你提到的两个场景均可通过该逻辑实现：

例1：同时变更E和C
待构建列表：E的provided下游是B，C的编译下游是D，加上变更的E、C本身，去重后为[E,C,B,D]
排序后构建顺序：E、C并行构建 → B构建 → D构建
例2：同时变更A和C
待构建列表：A的编译下游是B，B的编译下游是D，C的编译下游是D，加上变更的A、C本身，去重后为[A,C,B,D]
排序后构建顺序：A、C并行构建 → B构建 → D构建，D仅会执行一次

第三步：在Jenkins中实现DAG构建调度 #

• 可以用Pipeline Utility Steps插件加载依赖配置，用Flow Plugin或者直接在声明式Pipeline中用parallel和dependsOn配置依赖关系
• 如果不想编写复杂的Pipeline逻辑，也可以直接用Jenkins Build Flow Plugin或者Pipeline Graph Analysis Plugin自动处理DAG调度
• 每个仓库的构建任务完成后自动上传最新的SNAPSHOT包到私有Maven仓库，下游构建直接拉取最新版本即可

可选优化项 #

• 给每个仓库配置构建缓存，比如Maven本地仓库缓存，减少重复依赖下载时间
• 计算待构建列表时可以对比对应依赖的版本号，如果变更仓库的版本号未发生变化，可以跳过对应下游的构建，进一步减少冗余构建

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