結果: マージ (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. 学んだこと：オープンソースコントリビューションのコツ
- リンク
一言まとめ
| PR | alpine-docker/k8s#99 Point eksctl and jq URLs at their current repositories |
| 変更点 | Dockerfile·README.md·build.sh·latest_versions.sh から行単位で、アドレスのみ。4行追加、4行削除 |
| 反応 | PR に付随するチェック・ボットなし。メンテナーが「Thanks.」のコメント、36秒後にマージ |
| 結果 | PR 公開 10-17 03:53 → マージ 11:30、約 7時間37分。スカッシュマージ（我々のアカウントが作者）、マージ直後に master ビルド成功 |
1. 何が問題だったのか：まだ壊れていないもの
今回も率直に記します。何かが壊れて直したわけではありません。古いアドレスはリダイレクトを辿れば今でも取得でき、このイメージのビルドも 正常に動作していました。「いつか壊れる可能性のあるもの」を事前に修正した PR です。
TT Lab との関係は以下の通りです。TT Lab リポジトリの Jenkinsfile はパイプラインの kubectl コンテナとして alpine/k8s:1.31.2 を使用しています。コメントによるとシェルと kubectl・helm が揃っており、「眠って待機し命令を受ける」コンテナの形に合致するため選びました。我々が使うイメージでもあるこのリポジトリのビルドスクリプトを 2026-10-17 に小規模プロジェクトを巡回する中で読んでいる際に、古いアドレスを 2 つ見つけました。
| 古いアドレス | 現在のアドレス | 使用箇所（ベースコミット） |
|---|---|---|
github.com/weaveworks/eksctl |
github.com/eksctl-io/eksctl |
Dockerfile 58行目（eksctl 最新版のダウンロード）、ジェイソン README.md 25行目 |
github.com/stedolan/jq |
github.com/jqlang/jq |
build.sh 16行目、 latest_versions.sh 6行目（jq 1.6 のダウンロード） |
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
1行目の 301 は古い組織から新しい組織への引き渡し段階であり、その次の 302 は GitHub リリースが本来行う動作（「最新版」を実際のバージョンへ、バージョンアドレスをアセットサーバーへ）です。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へ移行し、古い アドレスは新しい場所へ自動転送されると記していました。そのためDockerfile58行目 のcurl -sL "https://github.com/weaveworks/eksctl/releases/latest/download/…"は 3年以上何の問題もなく動作しました。README.md25行目 のツールリストのリンクも古いアドレスでした。 - jq.
build.sh16行目 とlatest_versions.sh6行目 が jq 1.6 バイナリをstedolan/jqのリリースから取得しています。この jq はイメージの中に含まれるのではなく、ビルドスクリプトが各ツールの最新版を GitHub API に問い合わせる際に使用するツールです。そのため、この行が壊れると 1つのイメージだけでなくビルドスクリプトのバージョン確認全体に影響が及びます。
リダイレクトがあるため、今すぐの問題はありません。それでも修正する理由は 2つありました。GitHub のリポジトリ移行ドキュメントによると、古い場所に同名の新しいリポジトリやフォークが作成されると、リダイレクトは永久に削除されます（利用量が多いリポジトリでは古い名前を完全に引退させ、再利用できなくすることもあります）。リダイレクトは他者が維持する約束事であるため、我々には確認する手段がありません。また、 curl -sL は失敗しても HTTP エラーを終了コードとして
返さないため（-f がない）、リダイレクトが途切れた場合、ビルドは不正なレスポンスボディをバイナリとして保存したまま、次のステップで奇妙な形で
失敗すると予想されます。最後の文はフラグで検証したものであり、実際に遮断はしていません（未計測）。
前例もありました。同じリポジトリの #94（2026-09-01 マージ）が、移行先の sealed-secrets リポジトリのアドレスを同じ方法で修正しました。今回の PR はその作業を残りの 2つのツールに続けて行ったものです。
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つのアドレスのみであり、新しいアドレスが最後まで取得できることは上記のリダイレクトチェーンで確認済みです。
4. 反応：「Thanks.」
| 時刻（10-17） | 作業 |
|---|---|
| 03:47–03:48 | タグ選択の再現、リダイレクトの実測 |
| 03:53 | コミット（DCO 署名・SSH 署名）、13秒後に PR 公開。PR に付随するチェックなし |
| 11:29 | メンテナーのコメント「Thanks.」 |
| 11:30 | 36秒後にスカッシュマージ |
| 11:30–11:31 | master の CircleCI build 1分22秒、成功 |
このリポジトリの CI は CircleCI であり、ビルドジョブは master/main ブランチでのみ実行されます。そのため、PR 段階ではチェックが一切なく、マージ直後になって初めて master でビルドが 1回実行されました。ただし、 build.sh は Docker Hub に既に存在するタグを再ビルドしません。1分22秒という短時間から判断すると、今回のビルドは jq を取得してタグを確認したところで終了し、 Dockerfile の eksctl の行までは到達しなかったと考えられます。CircleCI のログは確認していません（未確認）。新しい Kubernetes のパッチバージョンがリリースされ、実際にイメージをビルドする日に eksctl の行が使用されます。
メンテナーはリポジトリの貢献者一覧において、2番目（6個）とは大きな差が開く 64個のコミットを持ち、実質的に一人でリポジトリを保守している人物です。ドラフトを作成する際に確認した最近の外部 PR のマージ時間は、#94 が当日（約 2時間14分）、#86 が 1日以内、#88 が 5日でした。今回の 7時間37分はその間に位置します。
マージコミット cf424d4c の作者は我々のアカウントであり、
メッセージは我々のコミットメッセージのタイトルの末尾に PR 番号が付いたものです。こちらで個別に対応すべき作業はありませんでした。
おまけで見つけた我々の側の改善点
第1節のタグ選択の再現結果を改めて見ると、このリポジトリは Kubernetes の最新マイナーバージョン 4つ（現在は 1.37・1.36・1.35・1.34）のみを新しくビルドします。TT Lab が使用する
1.31.2 はこのリストに含まれておらず、今回の修正を含め今後のツールの更新が反映されません。アップストリームの修正とは別に、
我々のパイプラインのイメージタグを現在ビルドされているバージョンに上げることが次の作業となります。
5. 学んだこと：オープンソースコントリビューションのコツ
- リダイレクトは障害ではなく猶予期間です。 移行した側が「古いアドレスは自動転送する」と約束してくれても、その約束は古い名前空間が空いている
間しか守られません。ビルドスクリプトや Dockerfile のように、人が見直すことが少ない場所ほど長く残り続けます。
curl -sILを 1回実行するだけで確認できます。 - 前例を探し、同じスタイルで提出する。 #94 が同種の修正をすでに受け入れているのを確認し、コミットメッセージにも「#94 のように」と記載しました。 メンテナーにとっては初めて見る提案ではなく、すでに受け入れている作業の続編となります。
- 変更の範囲をあえて狭める。 jq のバージョンアップ、
curl -fの追加など、一緒にやりたいことは他にもありましたが、一つも盛り込みませんでした。「アドレスのみ」という一言で説明できる PR なら、チェック機能のないリポジトリであってもメンテナーが目で直接確認できます。 - 使用しているイメージのアップストリームを読むと、自側の問題も見えてきます。 今回アップストリームに還元したのは 4つのアドレスですが、同じ調査を通じて、我々のパイプラインが すでに更新されなくなったバージョンを使用していることが分かりました。コントリビューションは他人のための作業であると同時に、自らの運用を見つめ直す機会でもあります。
ティティの一言。 友達が引っ越すときに、「古い家に届いた手紙は新しい家に転送してあげるね」って約束してくれたんだって。だからみんな 3年間古いアドレスに 手紙を送っていたの。でも、その古い家に誰かが新しく引っ越してきたらどうする？ アドレス帳の 4行を新しいアドレスに直したら、「ありがとう。」って一言が返ってきたよ。 そしたら、うちのアドレス帳にもすごく古い番号が一つあることに気づいたんだ。それもすぐ直さなきゃね。
リンク
すべての資料は 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