Jenkins任务执行时卡在“模块已更改，正在重新计算依赖图”15-20分钟

我之前帮不少团队排查过类似的Jenkins构建卡顿问题，针对你提到的卡在依赖图重计算步骤15-20分钟的情况，给你整理几个常见的排查方向和解决方案：

1. Git仓库变更检测开销过大 #

如果你的代码仓库体积大、包含大量历史提交或者子模块，Jenkins在扫描变更时会消耗大量时间：

• 优化Git拉取策略：在项目配置的Git设置里，尝试使用浅克隆（添加--depth 1参数），只拉取最新的提交版本；同时可以设置git config core.compression 0关闭压缩，减少IO和CPU开销（如果网络条件允许的话）。
• 排除无关变更目录：在Jenkins项目的“源码管理”模块中，添加「Excluded Regions」，把不需要检测变更的目录（比如docs/**、test/resources/**这类大文件目录）排除在外，缩小变更扫描的范围。

2. 依赖管理工具的缓存或解析问题 #

如果你的项目用Maven、Gradle这类工具管理依赖，依赖解析环节也可能拖慢整个步骤：

• 复用本地依赖缓存：确保Jenkins构建节点的依赖仓库（比如Maven的~/.m2、Gradle的~/.gradle）是持久化的，不要每次构建都重新下载依赖。可以把这些目录挂载为节点的持久化存储，或者用「Pipeline Cache Plugin」来缓存依赖目录。
• 启用构建缓存：Gradle用户可以在settings.gradle中启用本地构建缓存：

  buildCache {
      local {
          enabled = true
      }
  }
  

  Maven用户可以添加-Dmaven.repo.local=/path/to/cached/repo参数，指定复用的本地缓存路径。

3. 构建节点资源不足 #

远程服务器的CPU、内存或磁盘IO瓶颈也会导致步骤卡住：

• 检查节点资源状态：登录到你的远程构建服务器，用top或htop命令查看构建过程中的资源使用率。如果CPU占满、内存不足，考虑升级节点配置，或者把这个任务分配到资源更充足的Jenkins节点上。
• 清理工作区临时文件：用「Workspace Cleanup Plugin」在每次构建前清理旧工作区的临时文件，避免磁盘空间不足影响IO性能。

4. 插件版本存在bug #

旧版本的Jenkins插件可能存在性能问题：

• 升级相关插件：检查并升级Git插件、Pipeline插件以及对应的Maven/Gradle插件到最新稳定版，很多卡顿问题都是旧插件的已知bug导致的。

你可以先从调整Git变更检测范围和检查节点资源开始排查，这两个是最常见的诱因。比如先临时排除几个大目录，看看构建时间有没有明显缩短，再逐步定位具体原因。

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