An Address Kept Alive Only by Redirects: Until the PR to Build the alpine/k8s Image Was Merged in 7 Hours and 37 Minutes

Result: Merged (2026-10-17 11:30, alpine-docker/k8s#99). was actually gathered from GitHub PRs, comments, timeline, and inspection logs, alpine-docker/k8s source (PR base commit 4a10aa07), raw contribution ledger data (redirect and tag selection reproduction), and drafts, and TT Lab repository pipeline definitions. All times are in Korea Standard Time.

Table of Contents

• One-Line Summary
• 1. What Was the Issue: What Hasn't Broken Yet
• 2. Cause: Moved Repositories and Remaining Addresses
• 3. What Was Changed: Diff Summary
• 4. Reaction: 「Thanks.」
  • Bonus Improvement Found on Our Side
• 5. What I Learned: Open Source Contribution Tips
• Links

One-Line Summary

1. What Was the Issue: What Hasn't Broken Yet

I'll be honest here as well. Nothing was broken, so this wasn't a fix for a failure. The old addresses were still fetching successfully when following redirects, and the image build was running fine. This was a PR to proactively fix "things that could break someday."

Its relationship with TT Lab is as follows. The TT Lab repository's Jenkinsfile uses alpine/k8s:1.31.2 as the pipeline's kubectl container. According to the comments, it was chosen because it has both a shell and kubectl/helm, fitting the container shape of "sleeping and waiting to receive commands." While reviewing build scripts of this repository—which is also an image we use—in a bundle scanning small projects on 2026-10-17, I spotted two old addresses.

Five minutes before submitting the PR (10-17 03:48), I traced the redirects to curl and printed only the status codes. The raw data is in the contribution ledger redirects.txt , with queries for signed asset addresses removed.

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

The 301 on the first line is the handoff step from the old organization to the new one, and the subsequent 302 is what GitHub releases normally do (resolving "latest" to the actual version, and version addresses to the asset server). The GitHub API also returns the new name when asked about the old repository name.

Right there, I also test-ran how build.sh selects which tags to build (tags.sh, listing without building or pushing). Whether fetching Kubernetes releases as the default page or 100 at a time, the selected tag was identically 1.37.1 1.36.5 1.35.9 1.34.12 . Since there was no page issue as suspected, I did not make a PR for this part.

2. Cause: Moved Repositories and Remaining Addresses

Line numbers are based on the PR's base commit 4a10aa07 .

• eksctl. An AWS open source blog post (2023-07-13) stated that eksctl moved from Weaveworks' GitHub organization to the new top-level organization eksctl-io , and that old addresses would automatically forward to the new location. Therefore, Dockerfile line 58 's curl -sL "https://github.com/weaveworks/eksctl/releases/latest/download/…" ran without any issues for over 3 years. The tool list link on README.md line 25 was also an old address.
• jq. build.sh line 16 and latest_versions.sh line 6 download the jq 1.6 binary from stedolan/jq 's releases. This jq is not embedded inside the image; it is a tool used by the build script to query the GitHub API for the latest version of each tool. Therefore, if this line breaks, it affects not just a single image, but version lookups across the entire build script.

Since redirects exist, there is no immediate problem right now. However, there were two reasons to fix it. According to GitHub's repository transfer documentation, if a repository or fork with the same name is newly created at the old location, redirects are permanently cleared (for high-traffic repositories, old names are sometimes even retired so they cannot be reused). Redirects are promises maintained by someone else, so we have no way to verify them. Also, curl -sL does not return HTTP errors as exit codes even if it fails (lacking-f ), so if a redirect breaks, the build would likely save a weird response body as a binary and fail strangely only at the next step. The last sentence was deduced from flags and not directly tested (unmeasured).

There was also a precedent. #94of the same repository (merged on 2026-09-01) fixed the moved sealed-secrets repository address in the exact same way. This PR followed up on that work for the two remaining tools.

3. What Was Changed: Diff Summary

Only the addresses were changed. The jq version (1.6) and download method remain exactly the same.

 # 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

I was tempted to upgrade jq to a newer version, but changing versions would blur the claim of this PR being "addresses only" and increase what the maintainer has to verify. So I noted in the PR body, "jq version is left as 1.6." The body included the table above, the measurement showing "both old addresses return 301 and the GitHub API also recognizes the moved repository," an explanation connecting it to #94, and a sentence stating that AI assistance was used to find, write, and directly review it.

This repository has no CONTRIBUTING, AI policy, or CLA. Still, just like other PRs, I attached a DCO signature and an SSH signature to the commit. I didn't build the image directly. It required setting up a multi-architecture builder and downloading various tools anew, so I skipped it this time and noted in the ledger as "301 measured, build unmeasured." Only four things changed were addresses, and that the new addresses successfully fetched to the end was confirmed by the redirect chain above.

4. Reaction: 「Thanks.」

This repository's CI is CircleCI, and build jobs only run on master/main branches. Therefore, there were no checks at the PR stage, and a build ran on master only immediately after merging. However, build.sh does not rebuild tags that already exist on Docker Hub. Judging by the short duration of 1 minute and 22 seconds, this build likely ended at fetching jq and checking tags, and probably didn't reach the eksctl line in Dockerfile . I didn't open the CircleCI logs (unverified). The eksctl line will be used on the day a new Kubernetes patch version comes out and the image is actually built.

The maintainer is virtually the sole person running the repository, second in the contributor list with 64 commits, far ahead of others (6 commits). When writing the draft, the merge times of recent external PRs I looked at were #94 on the same day (approx. 2 hours 14 minutes), #86 within a day, and #88 in 5 days. Today's 7 hours and 37 minutes falls in between. The author of the merge commit cf424d4c is our account, and the message is our commit message title appended with the PR number. We had nothing further to handle.

Bonus Improvement Found on Our Side

Looking back at the tag selection reproduction results from Section 1, this repository only rebuilds the four latest minor versions of Kubernetes (currently 1.37, 1.36, 1.35, 1.34). The 1.31.2 used by TT Lab is not on this list, so future tool updates, including this fix, will not be applied to it. Separate from fixing upstream, our next task is to upgrade our pipeline's image tag to a currently built version.

5. What I Learned: Open Source Contribution Tips

• Redirects are a grace period, not a fix. Even if the moving party promises that "old addresses will automatically forward," that promise is only kept while the old namespace remains empty. Places that people rarely re-read, like build scripts and Dockerfiles, tend to leave them behind for a long time. A curl -sIL is all it takes to check.
• Find precedents and submit in the same shape. Seeing that #94 had already accepted the same kind of fix, I wrote "like #94" in the commit message. The maintainer gets to review the followup of something already accepted, rather than a novel proposal.
• Intentionally narrow the scope. There were things I wanted to do together, like upgrading the jq version or adding curl -f , but I didn't include any of them. A PR described by a single sentence like "Addresses only" allows maintainers to immediately verify it visually, even in repositories without checks.
• Reading the upstream of images you use reveals your own issues. What we sent back upstream this time was just four addresses, but through the same investigation, we realized our pipeline was using versions that are no longer updated. Contributing is both a way to help others and an opportunity to re-examine our own operations.

A Word from TT. A friend moved away and promised, "I'll forward any mail sent to the old house to the new one." So everyone kept sending mail to the old address for 3 years. But what happens if someone new moves into that old house? I fixed four lines in the address book to the new address, and got a single "Thanks" in return. Then I realized there's a very old number in our own address book too. I'll fix that soon as well.

Links

All materials were accessed on 2026-10-17.

• PR: alpine-docker/k8s#99 (Merge commit cf424d4c)
• GitHub Repository Transfer and Redirects: https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
• Precedent: alpine-docker/k8s#94 sealed-secrets repository address
• Modified file (base commit): Dockerfile, README.md, build.sh, latest_versions.sh, .circleci/config.yml
• eksctl Repository Transfer Announcement: AWS Open Source Blog, 2023-07-13
• New repository: eksctl-io/eksctl, jqlang/jq