Jenkins Windows Slave克隆Git仓库返回状态码130问题求助

状态码130本质是进程收到中断信号后异常退出，Windows环境下通常是以下几种触发场景：

• 进程被用户手动终止
• 系统资源不足（内存、CPU占满）时被系统自动查杀
• 父进程（此处为Jenkins进程）主动终止了Git子进程
• 网络链路中断被下层协议强制断开会话

你调整的大概率是流水线任务的全局执行超时，本次报错发生在Jenkins Master拉取流水线定义文件的阶段，触发的是Git插件自带的默认超时限制：

• Jenkins Git插件默认的全局超时为10分钟，刚好匹配你日志中从任务启动到报错的10分钟间隔（10:40启动，10:50报错）
• 该超时配置优先级高于流水线全局超时，需要单独修改：进入Jenkins全局系统配置，找到Git插件设置项，将「超时时间（分钟）」调整为大于10的数值，大仓库建议设置为30以上
• 如果是Slave节点执行代码拉取的场景，还需要在checkout步骤中单独指定超时：checkout([$class: 'GitSCM', ..., extensions: [[$class: 'CheckoutOption', timeout: 30]]])

在执行Git操作前配置以下环境变量即可输出详细调试信息：

• GIT_TRACE=1：输出Git命令执行的全流程trace日志
• GIT_CURL_VERBOSE=1：如果使用HTTP/HTTPS协议拉取，输出完整的HTTP请求响应日志
• GIT_TRACE_PACKET=1：输出Git传输过程中的网络包细节
  配置方式可以选择在Jenkins节点的系统环境变量中全局添加，或者在流水线的环境块中单独声明：

pipeline {
  agent any
  environment {
    GIT_TRACE = '1'
    GIT_CURL_VERBOSE = '1'
  }
  stages {
    // 你的流水线阶段
  }
}

你的仓库体积较大，且报错发生在增量解析阶段，还可以排查以下问题：

1. 检查Master节点的内存占用：Git解析delta阶段会占用大量内存，1.2GB仓库解析时峰值内存可能达到4-8GB，如果Master节点内存不足会被Windows系统自动查杀进程
2. 优化Git配置：在Master和Slave节点的Git全局配置中添加大仓库优化参数：

   git config --global http.postBuffer 1073741824
   git config --global core.compression 0
   

3. 可尝试开启浅克隆降低拉取压力：如果不需要完整的Git历史，拉取时添加--depth 1参数，仅拉取最新一次提交
4. 检查Git版本兼容性：Master和Slave节点的Git小版本不一致，建议统一升级到最新的Windows版Git，避免版本差异导致的兼容性问题

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