仅靠重定向维持的地址：alpine/k8s 镜像构建 PR 从提交到合并仅用 7 小时 37 分钟

结果：已合并 (2026-10-17 11:30, alpine-docker/k8s#99). 实际取自 GitHub 的 PR、评论、时间线、检查记录，alpine-docker/k8s 源码（PR 的基础提交 4a10aa07），以及贡献记录的实测原始数据（重定向及标签选择复现）与草稿、TT Lab 仓库的流水线定义。时间均为韩国时间。

目录

• 一句话总结
• 1. 问题所在：尚未损坏的部分
• 2. 原因：迁移的仓库与残留的地址
• 3. 修改内容：diff 摘要
• 4. 反应：“Thanks.”
  • 意外发现的我方改进点
• 5. 收获：开源贡献要领
• 链接

一句话总结

1. 问题所在：尚未损坏的部分

在此坦诚说明，我们并非因为出现了故障才进行修复。通过重定向，旧地址目前依然能够下载成功，该镜像的构建也一直在正常运行。这是一个提前修复“将来可能会损坏的部分”的 PR。

与 TT Lab 的关系如下。TT Lab 仓库的 Jenkinsfile 在流水线中将 alpine/k8s:1.31.2 用作 kubectl 容器。根据注释，由于它同时包含 shell 以及 kubectl 和 helm，符合“休眠等待命令”的容器形态，因而被选中。在 2026-10-17 浏览一些小项目时，我们看到了这个作为我们正在使用的镜像的仓库的构建脚本中的两个旧地址。

在提交 PR 的 5 分钟前（10-17 03:48），我们顺着 curl 的重定向跟踪并仅打印了状态码。原始数据位于贡献记录的 redirects.txt 中，删除了带签名的资产地址查询参数后保留。

301 -> https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_Linux_amd64.tar.gz
302 -> https://github.com/eksctl-io/eksctl/releases/download/v0.231.0/eksctl_Linux_amd64.tar.gz
301 -> https://github.com/jqlang/jq/releases/download/jq-1.6/jq-linux64
302 -> https://release-assets.githubusercontent.com/…(서명 쿼리 지움)
API repos/weaveworks/eksctl -> eksctl-io/eksctl
API repos/stedolan/jq -> jqlang/jq

第一行的 301 是旧组织移交给新组织的阶段，之后的 302 是 GitHub 释放（release）的常规行为（将“最新版”转换为实际版本，将版本地址转换为资产服务器）。当用 GitHub API 询问旧仓库名称时，它也会返回新名称。

我们在相同位置针对 build.sh 烧录了哪个标签也进行了原样运行测试（tags.sh，仅获取列表而不进行构建和推送）。无论是将 Kubernetes 发布版本作为默认页面获取，还是每次获取 100 个，所选的标签都是 1.37.1 1.36.5 1.35.9 1.34.12 ，结果一致。由于没有发现所担忧的页面问题，因此没有为此创建 PR。

2. 原因：迁移的仓库与残留的地址

行号基于 PR 的基础提交 4a10aa07 。

• eksctl。 AWS 官方开源博客（2023-07-13）记载，eksctl 已从 Weaveworks 的 GitHub 组织迁移到了新的顶级组织 eksctl-io ，旧地址会自动转发到新位置。因此， Dockerfile 第 58 行 的 curl -sL "https://github.com/weaveworks/eksctl/releases/latest/download/…" 运行了三年多都没有出现任何问题。 README.md 第 25 行 的工具列表链接也是旧地址。
• jq。 build.sh 第 16 行 与 latest_versions.sh 第 6 行 从 stedolan/jq 的版本中获取 jq 1.6 二进制文件。这个 jq 不包含在镜像内部，而是构建脚本在通过 GitHub API 查询各工具最新版本时使用的工具。因此，一旦这一行损坏，受影响的将不仅仅是一个镜像，而是构建脚本对版本查询的整体流程。

既然有重定向，目前确实没有问题。但我们要修复它有两个理由。根据 GitHub 的仓库迁移文档，如果旧位置新建了同名仓库或派生仓库（fork），重定向将被永久删除（对于使用量大的仓库，甚至会直接退役旧名称以防再次使用）。重定向是他人维护的承诺，我们无法自行确认。此外， curl -sL 即使失败也不会将 HTTP 错误作为退出代码返回（-f 缺失），因此如果重定向中断，构建过程可能会将错误的响应体保存为二进制文件，并在接下来的步骤中以奇怪的方式失败。最后这句话是通过参数推导出来的，并没有亲自去断开进行测试（未实测）。

此前也有过先例。我们用相同的方法修复了同一仓库的 #94（2026-09-01 合并）中迁移后的 sealed-secrets 仓库地址。本次 PR 是将该工作延续到其余两个工具上。

3. 修改内容：diff 摘要

仅修改了地址。jq 的版本（1.6）以及下载方式均保持不变。

 # Dockerfile
-    curl -sL "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_${ARCH}.tar.gz" | tar xz -C /tmp && \
+    curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$(uname -s)_${ARCH}.tar.gz" | tar xz -C /tmp && \
 # README.md
-- [eksctl](https://github.com/weaveworks/eksctl) (latest version when run the build)
+- [eksctl](https://github.com/eksctl-io/eksctl) (latest version when run the build)
 # build.sh, latest_versions.sh (같은 줄)
-curl -sL https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64 -o jq
+curl -sL https://github.com/jqlang/jq/releases/download/jq-1.6/jq-linux64 -o jq

虽然有把 jq 升级到新版本的冲动，但如果更改版本，就会模糊“仅修改地址”这一 PR 的核心诉求，并增加维护者需要核对的内容。因此，我们在 PR 正文中写明了“jq 版本保持 1.6 不变”。正文中包含了上表、实测结果（“两个旧地址均返回 301，GitHub API 也显示已迁移”）、承接 #94 的说明，以及借助 AI 辅助查找编写并经过人工亲自审核的声明。

该仓库没有 CONTRIBUTING、AI 政策和 CLA。不过与其他 PR 一样，我们在提交中附加了 DCO 签名和 SSH 签名。我们没有在本地亲自构建镜像。由于需要多架构构建器并重新下载多个工具，这次没有进行，因此贡献记录中也如实填写了“301 已实测，构建未实测”。修改的内容仅有四个地址，且新地址能完整下载已通过上述重定向链确认。

4. 反应：“Thanks.”

该仓库的 CI 是 CircleCI，且构建作业仅在 master/main 分支运行。因此 PR 阶段没有任何检查，直到合并后才在 master 上运行了一次构建。不过， build.sh 对于 Docker Hub 上已有的标签不会重新构建。从 1 分 22 秒的极短时间来看，本次构建仅停留在获取 jq 并验证标签的阶段， Dockerfile 的 eksctl 行应该尚未执行。我们没有打开查看 CircleCI 日志（未确认）。当发布新的 Kubernetes 补丁版本并实际构建镜像的那一天，eksctl 行才会派上用场。

在仓库的贡献者列表中，该维护者拥有 64 个提交，远超第二名（6 个），可以说是实际上独立维护该仓库的人。在编写草稿时查阅了最近外部 PR 的合并时间：#94 是当天（约 2 小时 14 分钟），#86 是 1 天内，#88 是 5 天。本次的 7 小时 37 分钟正处于其间。合并提交 cf424d4c 的作者是我方账号，消息是我方提交信息标题末尾附加了 PR 编号。我们无需采取任何后续行动。

意外发现的我方改进点

再次查看第 1 节中标签选择的复现结果，该仓库仅重新构建 Kubernetes 的四个最新次要版本（目前为 1.37、1.36、1.35、1.34）。TT Lab 使用的 1.31.2 不在此列表中，因此包括本次修改在内，未来的工具更新将无法应用到该镜像中。撇开修复上游不谈，将我们流水线中的镜像标签升级到当前构建的版本是接下来要做的事情。

5. 收获：开源贡献要领

• 重定向不是故障，而是宽限期。 即使迁移方承诺“旧地址会自动转发”，该承诺也仅在旧命名空间保持空置期间有效。像构建脚本和 Dockerfile 这种人们不常重新阅读的地方，往往会残留很久。只要运行一次 curl -sIL 就能进行确认。
• 寻找先例并以相同形式提交。 看到 #94 已经接受了同类修改后，我们在提交信息中也写明了“像 #94 一样”。这样维护者面对的就不是陌生的提议，而是以往已接受工作的延续。
• 刻意缩小范围。 虽然有许多想顺便做的事情，比如升级 jq 版本、添加 curl -f 等，但我们一个也没有加。用“仅修改地址”这一句话就能说清楚的 PR，即使在没有自动化检查的仓库中，维护者也能一眼直接核实。
• 阅读所用镜像的上游，也能发现我方的问题。 这次虽然只向上游反馈了四个地址，但在同一次调查中，我们发现我方的流水线正在使用不再更新的版本。贡献既是为他人做贡献，也是重新审视自身运维的好机会。

Tee 的寄语。 听说朋友搬家时承诺过“寄到老房子的信会帮你转发到新家”。于是大家连续三年都把信寄到了旧地址。可要是有人搬进那栋老房子该怎么办呢？我们将地址簿里的四行改成了新地址，就收获了一句“谢谢”。同时我们也发现，自己家的地址簿里还有一个非常古老的号码。那个我们也会尽快修复的。

链接

所有资料均于 2026-10-17 查阅。

• PR: alpine-docker/k8s#99 (合并提交 cf424d4c)
• GitHub 仓库迁移与重定向: https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
• 先例: alpine-docker/k8s#94 sealed-secrets 仓库地址
• 修改的文件（基础提交）: Dockerfile, README.md, build.sh, latest_versions.sh, .circleci/config.yml
• eksctl 仓库迁移公告: AWS 官方开源博客, 2023-07-13
• 新仓库: eksctl-io/eksctl, jqlang/jq