GitLab Runner与服务器版本不匹配是否引发Go依赖拉取错误？

环境信息 #

• GitLab服务器版本：

  GitLab Enterprise Edition 17.5.0-pre c30a70942c6
  

• 自定义GitLab Runner版本（运行于Ubuntu）：

  Version:      16.1.0
  Git revision: b72e108d
  Git branch:   16-1-stable
  GO version:   go1.19.9
  Built:        2023-06-21T21:52:30+0000
  OS/Arch:      linux/amd64
  

问题场景 #

两天前CI/CD流水线运行正常，今日多个Go程序编译流水线失败，触发原因是go.mod中更新了特定依赖版本：

replace (
    gitlab.com/my-proj/common => gitlab.com/my-proj/common.git v0.2.29
)

仅将版本从v0.2.28升级到v0.2.29，错误发生在Go尝试拉取v0.2.29时：

go: downloading gitlab.com/my-proj/common.git v0.2.29
cmd/server/main.go:14:2: no secure protocol found for repository

已有其他用户反馈相同错误，该问题过去数月从未出现，今日突然在多条流水线触发。

核心疑问 #

自定义GitLab Runner（16.x）与GitLab服务器（17.x）的版本不匹配是否会导致该问题？

回答 #

版本不匹配极有可能是导致该问题的原因，具体分析如下：

1. GitLab 17.x的协议安全变更
   GitLab 17.x可能对Git依赖拉取的安全协议做了调整，比如禁用了旧版TLS协议或不安全的HTTP传输方式。而16.1.0版本的Runner内置的Go 1.19.9发布于2023年6月，对较新的安全协议支持有限，无法适配GitLab 17.x的新安全要求，导致Go在拉取依赖时无法建立有效安全连接，触发no secure protocol found错误。

2. Runner与GitLab的版本兼容性限制
   GitLab官方明确建议Runner版本与服务器版本保持在同一大版本或相邻大版本范围内（如服务器17.x对应Runner 17.x或16.9+）。16.1.0属于较早的16.x分支，与17.x服务器存在明显的版本断层，旧版Runner的网络请求逻辑、认证方式可能无法适配新版服务器的API或协议规则。

3. 验证与解决方向

• 临时将Runner升级至与GitLab服务器大版本一致的版本（如17.x），重新运行流水线，观察错误是否消失；
• 检查GitLab服务器的安全配置，确认是否禁用了旧协议，同时查看Runner的Git全局配置（如git config --global http.sslVersion）是否支持服务器要求的协议版本；
• 在本地使用相同Go版本（1.19.9）尝试拉取v0.2.29依赖，若本地正常，则可确认问题出在Runner与服务器的协议兼容性上。

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