在 CI/CD 流水线中接入 GitHub 加速 · 博客

CI 拉取 GitHub 的痛点

构建节点位于跨境网络时，流水线里下载依赖、拉取源码、获取二进制工具都可能拖慢整体时长，甚至因为超时直接失败。把需要访问 GitHub 的环节统一换成本站加速地址，通常是最省事的改善方式。

接入方式一：替换下载地址

Dockerfile 或构建脚本里下载 Release 二进制、源码归档时，把原始地址拼接加速域名即可：

# Dockerfile 片段：下载发布二进制并校验
RUN curl -fL -o /usr/local/bin/tool \
      "https://ghclone.com/https://github.com/owner/repo/releases/download/v1.0/tool-linux-amd64" \
    && chmod +x /usr/local/bin/tool

接入方式二：克隆加速

流水线里需要克隆源码时，把仓库地址换成加速地址；只做构建的场景建议配合浅克隆减少数据量：

git clone --depth=1 https://ghclone.com/https://github.com/owner/repo.git

含子模块的项目，克隆完成后用定向替换继续拉取子模块：

git config --local url."https://ghclone.com/https://github.com/".insteadOf "https://github.com/"
git submodule update --init --recursive

接入方式三：缓存与制品库

对构建频率高的依赖，别每次都跨境重新下载：CI 平台一般提供缓存目录（如把下载产物放进缓存路径），或把固定版本的归档推入内网制品库。原则是「跨境的下载只做一次，之后都走局域网或缓存」。

可靠性清单

固定版本（标签或提交）再下载，构建结果才可复现
下载后校验哈希，失败立即终止，避免脏产物进入下游
给下载步骤加重试包装（--retry 或 shell 循环），抵消偶发链路抖动
多线路环境建议在脚本里做 fallback：首选线路失败后自动换下一条

# shell 重试包装示例
fetch() {
  curl -C - -fL --retry 3 --retry-delay 2 -o "$2" "$1" && return 0
  echo "download failed: $1" >&2
  return 1
}
fetch "https://ghclone.com/https://github.com/owner/repo/releases/download/v1.0/tool.tar.gz" tool.tar.gz

关于 GitHub Actions

GitHub Actions 的托管运行器本身位于 GitHub 网络内，拉取官方资源通常不需要加速；使用自建 runner（尤其放在跨境网络中）或第三方 CI 平台时，才需要按本文方式替换地址。另外注意：不要在 URL 里携带任何凭据，本站也会剥离请求中的凭据头，写操作一律拒绝。