如何优化超大量分支的Jenkins多分支流水线预检出延迟？

从你提供的日志来看，卡顿发生在git fetch完成、Jenkins获取Jenkinsfile之前，核心问题是Jenkins在处理大量远程分支元数据或不必要的全量分支拉取上消耗了过多时间。以下是具体优化手段：

• 修改Git Fetch策略，仅拉取当前分支
  默认多分支流水线会拉取所有远程分支的引用，这在2500+分支的场景下完全冗余。在流水线的SCM配置中，将fetch命令改为只拉取当前触发的分支：

  git fetch --tags --force --progress -- origin +refs/heads/${BRANCH_NAME}:refs/remotes/origin/${BRANCH_NAME}
  

  避免拉取2000+无关分支的开销，直接减少fetch后的分支处理时间。

• 启用Git浅克隆（Shallow Clone）
  只拉取仓库的最新提交而非完整历史，大幅降低数据传输和本地处理成本。在SCM配置中添加--depth 1参数：

  git clone --depth 1 <repo-url>
  # 或在fetch时使用
  git fetch --depth 1 --tags --force --progress -- origin +refs/heads/${BRANCH_NAME}:refs/remotes/origin/${BRANCH_NAME}
  

  若流水线依赖少量历史提交（如变更日志），可适当调整depth值（比如--depth 10），平衡速度和功能需求。

• 在Agent上缓存Git镜像仓库
  在Jenkins Agent上创建仓库的镜像副本：

  git clone --mirror <repo-url> /path/to/mirror-repo
  

  让所有流水线从本地镜像拉取代码，而非直接连接远程GitLab。定期通过cron任务更新镜像：

  cd /path/to/mirror-repo && git fetch --tags --force --progress
  

  本地镜像的拉取速度远快于远程，彻底解决大量分支拉取的网络和处理瓶颈。

• 调整Webhook触发逻辑，避免全部分支扫描
  确保GitLab的Webhook仅传递当前提交的分支信息给Jenkins，同时在Jenkins多分支流水线配置中关闭“自动扫描全部分支”选项，仅处理Webhook触发的特定分支。这样单个分支流水线启动时，不会再遍历2000+分支的元数据。

• 优化Jenkins Agent资源配置
  卡顿可能是Agent CPU/内存不足，导致处理大量分支元数据时阻塞。给Agent增加CPU核心数和内存（比如从2核4G调整到4核8G），能显著提升分支元数据的处理速度。

• 禁用不必要的SCM特性
  关闭Git插件中冗余功能，比如自动获取所有标签（若流水线不需要标签信息）、跳过子模块同步（若无项目子模块），减少额外处理步骤。

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