Jenkins首次调用checkout scm报错错误码18，第二次调用成功问题咨询

1. http.postBuffer配置的生效范围 #

你通过git config --global写入的配置是针对当前Jenkins执行用户的全局Git配置，只要是同一个构建任务、同一个执行节点（Agent）上后续发起的所有Git调用，不管是第一次还是第二次checkout scm，都会读取该配置，不存在仅对第二次生效的情况。

2. 如何让配置在第一次checkout scm生效 #

首先需要纠正一个常见误区：http.postBuffer参数仅作用于Git推送（push）场景，对你当前的拉取（fetch）操作完全不生效，你之前调大该参数后10%的成功率只是链路抖动的偶然结果，和该参数没有任何关系。
如果要让Git客户端配置在第一次checkout scm就生效，不需要修改脚本结构，只要确保配置是在checkout scm之前执行即可，你当前的脚本顺序已经满足要求。

3. 现象的根本原因 #

你遇到的RPC failed; result=18, HTTP code = 200报错，本质是代理到GitHub的链路不稳定、单次全量拉取大仓库时触发了代理的TCP连接超时/中断，和Git配置没有直接关系。
两次checkout scm能成功的逻辑是：

• 第一次checkout scm执行时，会先初始化本地Git仓库，即便最终拉取失败，也已经将部分元数据、部分代码片段拉到了本地工作区
• 第二次checkout scm执行时不需要全量拉取数据，只需要增量拉取第一次没拉完的内容，单次传输的数据量小、耗时短，不会触发代理的超时/中断规则，因此次次都能成功。

你当前的两次checkout方案虽然可用，但不够优雅，推荐三种更可靠的解决方式：

• 调整Jenkins Git插件的拉取超时时间：在SCM配置里将Timeout (in minutes) for clone and fetch operations参数从默认的10分钟调到30分钟以上
• 改用浅克隆：在checkout scm的配置里添加shallow: true, depth: 1参数，只拉取当前分支的最新提交，大幅减少单次拉取的数据量
• 优先使用SSH协议拉取代码：SSH协议在代理环境下的连接稳定性远高于HTTPS，基本不会出现这类RPC中断问题。

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