Jenkins Pipeline本身不内置循环依赖检测能力，需借助第三方插件Pipeline Graph Analysis，通过解析FlowNode执行图谱识别运行时实际存在的跨流水线或内部自调用闭环，但无法静态扫描Jenkinsfile源码或分析外部触发关系。

Jenkins Pipeline 本身不内置循环依赖检测能力，Pipeline-Graph-Analysis 是一个第三方开源工具（GitHub 项目：jenkinsci/pipeline-graph-analysis-plugin），它通过解析 Jenkins 的 FlowNode 执行图谱，将 Pipeline 的 stage、step、parallel 分支、input 等节点构建成有向图，从而识别潜在的逻辑循环调用关系——比如 A 流水线触发 B，B 又反过来触发 A；或某 Pipeline 内部通过 build 步骤递归调用自身（未设终止条件）。

但要注意：
✅ 它分析的是 运行时实际执行的流水线调用链路（基于 Jenkins 内部 FlowGraph 数据）
❌ 它不能静态扫描 Jenkinsfile 源码发现“可能存在的”循环逻辑（如 Groovy for 循环里误写 build currentBuild.projectName）
❌ 它不分析 Git SCM 触发、Webhook、定时任务等外部调度关系，只聚焦于 build 步骤引发的 Pipeline 间调用

---

一、前提：安装并启用 Pipeline Graph Analysis 插件

1. 进入 Jenkins 管理界面 → 插件管理 → 可选插件
2. 搜索 Pipeline Graph Analysis，勾选安装（需重启或热加载，取决于 Jenkins 版本）
3. 安装后无需额外配置，插件自动为每个 Pipeline 构建任务注入图谱分析能力

✅ 验证是否生效：打开任一已完成的 Pipeline 构建页 → 左侧菜单应出现 "Pipeline Graph" 和 "Dependency Graph" 两个新链接

---

二、识别部署链路中的循环依赖（实操步骤）

▪ 查看「Dependency Graph」发现跨流水线循环

• 点击构建页左侧的 Dependency Graph
• 图中每个节点代表一个被 build 调用的 Pipeline（含参数）
• 若出现 A → B → A 或 A → B → C → A 等闭环路径，即存在循环依赖
• 示例场景：
  • deploy-prod 在 post 阶段调用 notify-slack
  • notify-slack 因配置错误又调用了 deploy-prod --rollback=true
    → 图中将显示 deploy-prod ⇄ notify-slack 双向边（或带标签的环）

▪ 结合「Pipeline Graph」定位内部逻辑循环

• 点击 Pipeline Graph，查看当前 Pipeline 的完整执行拓扑
• 关注 build 类型节点（图标为齿轮+箭头），检查：
  • 是否调用自身（build 'this-pipeline-name'）且无 parameters: [string(name: 'RECURSION_DEPTH', value: '3')] 等防护
  • 是否在 parallel 块中多个分支都调用同一下游 Pipeline，而该 Pipeline 又反向触发上游（形成隐式反馈环）

▪ 导出图谱数据做深度分析（可选）

• Dependency Graph 页面右上角有 "Export as DOT" 按钮
• 下载 .dot 文件后，可用 Graphviz 命令行检测环：

  dot -Tpng -O dependency-graph.dot  # 生成图片辅助肉眼判断  
  # 或用 Python networkx 解析 dot 并运行 cycle detection  

---

三、常见循环依赖模式与修复建议

• 模式1：无条件自调用

  stage('Retry on Failure') {
    steps {
      script {
        if (currentBuild.result == 'FAILURE') {
          build 'my-pipeline'  // ❌ 缺少递归退出条件，会无限触发  
        }
      }
    }
  }

  ✅ 修复：加入计数器或状态标记

  

  Linux installer

  先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

  下载

  def maxRetries = 3
  def retryCount = params.RETRY_COUNT ?: 0
  if (currentBuild.result == 'FAILURE' && retryCount < maxRetries) {
    build job: 'my-pipeline', parameters: [string(name: 'RETRY_COUNT', value: "${retryCount + 1}")]
  }

• 模式2：上下游双向触发

  • ci-build 成功后触发 cd-deploy
  • cd-deploy 失败后通过 webhook 或 build 反向触发 ci-build 的 rollback 分支
    ✅ 修复：
  • 使用独立的 rollback-pipeline，不复用主构建流水线
  • 或在 cd-deploy 中禁用对 ci-build 的直接 build 调用，改用 API 触发并加 X-Jenkins-Source: rollback 标头，由上游 Pipeline 判断来源跳过常规构建逻辑

• 模式3：共享 Jenkinsfile 被多项目引用，参数混淆导致误循环

  • 多个仓库共用同一份 Jenkinsfile@shared-lib
  • 某项目传参 TARGET_ENV=prod，另一项目传 TARGET_ENV=staging，但脚本未校验，prod 分支意外调用 staging 部署任务
    ✅ 修复：在 build 前显式校验参数合法性，或使用 job-dsl 动态生成隔离的 Pipeline 实例

---

四、补充建议：预防胜于诊断

• 在所有 build 步骤前添加日志：

  echo "Triggering ${jobName} with params: ${params}"

• 对关键跨流水线调用启用 quietPeriod: 5，避免高频抖动放大循环
• 定期导出 Dependency Graph DOT 数据，用脚本扫描 -> 边是否存在长度 ≥3 的环（提示深层耦合）
• 将 Pipeline Graph Analysis 的「环检测」集成进每日健康检查报告（配合 Jenkins Health Advisor）

不复杂但容易忽略。