test(install): serve URL tarball dependencies locally in bun-install.test.ts

[robobun]

Problem

• test/cli/install/bun-install.test.ts went red on every retry in CI build 93264 (darwin aarch64), and again in 93273 on an unrelated branch:

  error: GET https://github.com/cujojs/when/tarball/1.0.2 - 503
  error: when@https://github.com/cujojs/when/tarball/1.0.2 failed to resolve
  

  in should handle GitHub tarball URL in dependencies (https://github.com/user/repo/tarball/ref) and its with custom GITHUB_API_URL variant.
• Both tests install a URL dependency that bun downloads verbatim from github.com, so the file fails whenever github.com has a 5xx window. should treat non-GitHub http(s) URLs as tarballs two tests further down does the same against gitpkg-fork.vercel.sh and fails the same way when that host is unavailable (all three fail identically with the outside world unreachable, see the probe below).
• There is no culprit commit: the tests have fetched from these hosts since they were added in fix(bun install): Handle vercel and github tarball path dependencies #6122 and Fix bun install reading Github API from wrong environment variable #6247 (2023). The break is the tests depending on third-party hosts; this PR removes that dependency.

Fix

• Adds urlTarballProxy() to bun-install.test.ts: a per-test Bun.serve on port 0 that answers each registered URL either with a gzipped tarball built in memory with Bun.Archive or with a given Response (404 for anything else), and records every URL it is asked for. The three tests run bun install with http_proxy pointed at it (no_proxy set to the dummy registry's host, so registry traffic is unchanged) and their dependencies switched from https:// to http://.
• The GitHub fixture mirrors what github.com really does for /tarball/ URLs: a 302 to codeload.github.com/<user>/<repo>/legacy.tar.gz/refs/tags/<ref> (checked with curl -I against the real URL), with the tarball served at the codeload URL. The old tests therefore also covered following a cross-host redirect while keeping the original URL as the resolution, and the new ones still do: they assert the proxy saw exactly [tarball_url, codeload_url] and that stdout/lockfile still name the original URL. The gitpkg fixture answers directly, covering the no-redirect path.
• Why a proxy rather than a localhost URL: these tests exist to cover the host-specific classification in src/install/dependency.rs (https?://github.com/<user>/<repo>/tarball/<ref> is a tarball, not a github: dependency, at dependency.rs:959-974; an unknown host with a query string falls through to tarball at :969-974). A proxied plain-http request reaches the proxy in absolute form, so the specifiers keep github.com / gitpkg-fork.vercel.sh and that code runs unchanged. Confirmed with a temporary eprintln! in the is_github_tarball_path branch: it fires for the new https://github.com/... specifier.
• Why http://: the scheme-stripping at dependency.rs:946-957 treats http:// and https:// identically, while an https:// dependency would make the install CONNECT-tunnel to the real host (src/http/HTTPContext.rs:930), which is exactly the network dependency being removed. Everything after classification is the same RemoteTarball download/extract/lockfile path as before; only the proxy hop is added, using bun's regular http_proxy support (src/install/NetworkTask.rs:650; the only other thing http_proxy changes in an install is skipping the registry DNS prefetch in install_with_manager.rs:55). What these tests no longer exercise is the TLS client path, which was never their subject and is covered by the registry/TLS install tests (e.g. bun-install-stalled-tls.test.ts).
• The GITHUB_API_URL variant keeps its purpose (that setting must not affect a tarball URL) but now points at a URL under the test's dummy registry instead of example.com; a request there would fail the existing urls/ctx.requested assertions instead of going to the network.
• Fixtures reproduce the directory listings the tests already assert (GitHub's <user>-<repo>-<sha>/ root, gitpkg's package/ root with the loader-runner dependency that the dummy registry serves), so every existing assertion is kept; the tests additionally assert the exact list of URLs fetched through the proxy and, for the gitpkg test, the exact registry URLs (previously just toHaveLength(2)).
• Verified: bun bd test test/cli/install/bun-install.test.ts -t "tarball URL in dependencies|non-GitHub http": 3 pass, also with HTTP_PROXY/HTTPS_PROXY in the environment pointing at a dead port (no outside network). Same 3 pass with the release build on Linux and on Windows x64 (release build, with and without the dead ambient proxy; the ambient-proxy run also exercises the env override on Windows' case-insensitive environment). On main, the same three tests fail under that environment on both platforms (ConnectionRefused downloading tarball ...). Full file with the debug build: 181 pass, 2 todo; the 13 failures are the bitbucket/gitlab clone tests (blocked by this container's egress) and should support --registry CLI flag (fails identically on clean main here, IPv6 loopback ordering, reported separately), none of them touched by this change.
• Out of scope: the github:-shorthand tests (api.github.com) and the git-clone tests in this file still use the network. test(install): serve GitHub tarball fixtures locally in bun-add.test.ts #35149 makes the bun-add.test.ts equivalents hermetic via GITHUB_API_URL, which is the right base for those; this PR deliberately does not touch dummy.registry.ts so the two do not conflict.

Background

• URL dependencies: a dependencies value that is an http(s):// URL is downloaded as-is and extracted as a tarball (ResolutionTag::RemoteTarball, src/install/extract_tarball.rs:405-420). github.com/<user>/<repo>/tarball/<ref> is GitHub's legacy tarball endpoint (it redirects to codeload.github.com) and is one such URL; it is classified explicitly so it is not mistaken for the github:user/repo form.
• github: dependencies, by contrast, are resolved by building an API URL from GITHUB_API_URL (default https://api.github.com, src/install/PackageManager/runTasks.rs:1693), which is why those tests can be made hermetic with an environment variable and URL dependencies cannot.
• http_proxy: for a plain-http URL bun's HTTP client connects to the proxy and sends the full URL on the request line (GET https://github.com/... HTTP/1.1), so Bun.serve sees request.url === "https://github.com/...". For an https URL it instead sends CONNECT host:443 and speaks TLS to the real host through the tunnel. no_proxy lists hosts that bypass the proxy.

Probe: old vs new tests with the outside network unreachable

Parent environment: HTTP_PROXY=HTTPS_PROXY=http_proxy=https_proxy=http://127.0.0.1:1 (inherited by the spawned installs through bunEnv).

main:

error: ConnectionRefused downloading tarball when@https://github.com/cujojs/when/tarball/1.0.2
error: when@https://github.com/cujojs/when/tarball/1.0.2 failed to resolve
(fail) bun-install > should handle GitHub tarball URL in dependencies (https://github.com/user/repo/tarball/ref)
(fail) bun-install > should handle GitHub tarball URL in dependencies (https://github.com/user/repo/tarball/ref) with custom GITHUB_API_URL
error: ConnectionRefused downloading tarball @vercel/turbopack-node@https://gitpkg-fork.vercel.sh/vercel/turbo/crates/turbopack-node/js?turbopack-230922.2
(fail) bun-install > should treat non-GitHub http(s) URLs as tarballs (https://some.url/path?stuff)
 0 pass
 3 fail

this branch (debug build):

(pass) bun-install > should handle GitHub tarball URL in dependencies (https://github.com/user/repo/tarball/ref) [721.42ms]
(pass) bun-install > should handle GitHub tarball URL in dependencies (https://github.com/user/repo/tarball/ref) with custom GITHUB_API_URL [543.59ms]
(pass) bun-install > should treat non-GitHub http(s) URLs as tarballs (http://some.url/path?stuff) [586.24ms]
 3 pass
 0 fail

Windows x64, release build, same dead ambient proxy: this branch 3 pass (about 33ms each); main 3 fail with the same ConnectionRefused downloading tarball errors.

What github.com returns for the URL the old tests used:

$ curl -sI https://github.com/cujojs/when/tarball/1.0.2
HTTP/2 302
location: https://codeload.github.com/cujojs/when/legacy.tar.gz/refs/tags/1.0.2

Classification probe (temporary eprintln! in the is_github_tarball_path branch of dependency.rs, installing https://github.com/cujojs/when/tarball/1.0.2 through the proxy, reverted before committing):

TEMP_PROBE github tarball path classified as Tarball
TEMP_PROBE github tarball path classified as Tarball
Resolving dependencies
Resolved, downloaded and extracted [2]
Saved lockfile

---

no test proof · iteration 0 · Platform-specific test-only change; deferring to CI.

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: f78ef488-653b-4602-8ab6-f7227212ad9b

📥 Commits

Reviewing files that changed from the base of the PR and between f426a8e and eb5b5ea.

📒 Files selected for processing (1)

• test/cli/install/bun-install.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

^{Updated 7:42 PM PT - Aug 12th, 2026}

❌ @robobun, your commit eb5b5ea has 1 failures in Build #93699 (All Failures):

• test/js/third_party/grpc-js/test-tonic.test.ts - code 1 on 🍎 14 aarch64

---

🧪   To try this PR locally:

bunx bun-pr 37919

That installs a local version of the PR into your bun-37919 executable, so you can run:

bun-37919 --bun

[robobun]

Status: fix is up in this PR (current head eb5b5ea, rebased onto main after #37669 touched the same file; the diff against main is unchanged).

Reproduced: the three URL-tarball tests in test/cli/install/bun-install.test.ts (the two GitHub tarball URL tests from build 93264 plus the gitpkg-fork.vercel.sh one) fail on main as soon as the outside network is unavailable (ConnectionRefused downloading tarball when@https://github.com/cujojs/when/tarball/1.0.2, same failure class as the 503 in CI), on Linux and on Windows. With this branch they pass with no outside network on both, under the debug and release builds, including after the rebase (full file: the only local failures are the pre-existing bitbucket/gitlab clone tests blocked by this sandbox's egress, and the --registry IPv6-loopback one reported separately).

The GitHub fixture answers with the same 302 to codeload.github.com that github.com really sends, so the redirect-following the old tests exercised is still covered.

CI on the current head (build 93699): 178 of 181 jobs passed. bun-install.test.ts itself ran on the darwin 14 aarch64 shard, the lane that was red in 93264, and passed (196 pass, 2 todo, 0 fail, 198 tests); it also passed on every Linux and Windows lane. The one failed job is that same darwin 14 shard, failing only on test/js/third_party/grpc-js/test-tonic.test.ts (1 CANCELLED: Call cancelled, unrelated to this change, reported separately); the remaining annotated failures are files tagged flaky that passed alone or on retry. The two darwin 26 shards were canceled unrun: the test-darwin queue is backlogged fleet-wide (about 80 darwin 26 jobs queued on two boxes at the time of writing), and retriggering would only re-queue all 181 jobs behind that backlog, so I am not doing that; the change has no platform-specific parts (a Bun.serve proxy, http_proxy, Bun.Archive) and is covered by the lanes that did run. Ready for review from my side.

Related: #35149 covers the github:-shorthand tests in bun-add.test.ts; the github: and git-clone tests remaining in this file are out of scope here.

[claude]

LGTM — test-only change that makes three network-dependent install tests hermetic via a local http_proxy + Bun.Archive tarball server.

What was reviewed:

• urlTarballProxy() uses port: 0, await using disposal via server.stop(true), and spreads bunEnv correctly; no_proxy is set to the dummy registry hostname so registry traffic stays unproxied.
• Confirmed http:// vs https:// scheme swap still exercises the is_github_tarball_path classification in dependency.rs (scheme-agnostic), and the fixture layouts match the pre-existing readdirSorted assertions.
• Checked describe.concurrent safety: each test allocates its own proxy server and proxied_urls array, no shared state.
• Assertions were strengthened (exact proxied/registry URL lists replace toHaveLength(2)), none weakened.

Extended reasoning...

Overview

This PR touches a single file, test/cli/install/bun-install.test.ts, rewriting three tests that previously fetched real tarballs from github.com and gitpkg-fork.vercel.sh. It adds a small urlTarballProxy() helper that spins up a per-test Bun.serve({ port: 0 }) acting as an HTTP forward proxy, serving in-memory gzipped tarballs built with Bun.Archive. The tests now point http_proxy at it and switch dependency specifiers from https:// to http:// so requests reach the proxy in absolute-URI form rather than CONNECT-tunneling to the real host. The two nearly-identical GitHub-tarball tests are collapsed into a for (const with_github_api_url of [false, true]) loop.

Security risks

None. This is test-only code with no changes to src/. The proxy server binds to an ephemeral port, serves only whitelisted URLs (404 otherwise), and is torn down via await using / server.stop(true). No new external hosts are contacted — the change strictly removes network egress.

Level of scrutiny

Low-to-medium. It's a de-flake refactor of existing tests, which the repo guidance explicitly encourages ("Never contact external network hosts or live registries"). The main risk with de-flakes is silently weakening coverage; I checked that:

• The github.com / gitpkg-fork.vercel.sh hostnames are preserved in the specifiers, so the host-specific classification branches in src/install/dependency.rs still run (the PR description confirms this with a probe, and the code at dependency.rs strips http:///https:// identically before matching).
• Every assertion from the old tests is retained: readdirSorted output, extracted package.json name, lockfile presence, ctx.requested count. The gitpkg test's urls assertion is tightened from toHaveLength(2) to an exact array, and a new proxied_urls assertion is added.
• The GITHUB_API_URL variant now points at ${ctx.registry_url}github/api instead of example.com, so a regression (bun mistakenly consulting the API for a tarball URL) would surface as an unexpected registry hit rather than a silent network call — an improvement.

Other factors

• env (aliased bunEnv) is module-scoped and correctly spread into the returned proxy env; no_proxy is derived from ctx.registry_url's hostname (localhost), and Bun's HTTP client honors no_proxy (src/http/lib.rs), so registry requests bypass the proxy as intended.
• Tests run under describe.concurrent: each test creates its own proxy on port 0 and its own proxied_urls array inside the test body, so there's no cross-test interference.
• Bun.Archive(files, { compress: "gzip" }).bytes() matches the documented API in packages/bun-types/bun.d.ts.
• The PR description documents verification against both debug and release builds, and against a dead-port ambient proxy to prove hermeticity. No production code paths change, so CI passing on the touched file is sufficient signal.

[claude]

LGTM — test-only hermeticization that removes external network dependencies from three URL-tarball install tests.

What was reviewed:

• urlTarballProxy() helper: Bun.serve on port 0, await using disposal via server.stop(true), new Bun.Archive(files, {compress: "gzip"}).bytes() matches the documented API.
• Proxy env: spreads bunEnv, sets http_proxy/no_proxy (registry hostname bypasses proxy so ctx.requested/urls still work); dependencies switched to http:// so requests reach the proxy in absolute form rather than CONNECT-tunneling.
• Assertions: every existing assertion kept; new ones added (proxied_urls exact match, gitpkg registry URLs upgraded from toHaveLength(2) to exact list). The two near-identical GitHub tests are folded into a for loop without losing the GITHUB_API_URL variant's purpose.
• Concurrency: each test gets its own server/context/arrays, safe under describe.concurrent.

Extended reasoning...

Overview

This PR touches a single file, test/cli/install/bun-install.test.ts, and modifies three tests that previously fetched real tarballs from github.com and gitpkg-fork.vercel.sh. It adds a small urlTarballProxy() helper (a Bun.serve on port 0 that answers registered absolute URLs with an in-memory gzipped tarball built via Bun.Archive, and 404s everything else) and points bun install's http_proxy at it while exempting the dummy registry via no_proxy. The two nearly-identical GitHub-tarball tests are deduplicated into a two-iteration for loop; the GITHUB_API_URL variant now points at a path under the local dummy registry so a stray request would fail the existing urls/ctx.requested assertions instead of leaving the machine. The gitpkg test's toHaveLength(2) registry assertion is tightened to the exact URL list.

Security risks

None. This is test-only code with no changes to production sources. The proxy server binds to an ephemeral port, is scoped per-test with await using, and only serves fixture bytes back to the same process's spawned bun install.

Level of scrutiny

Low-to-moderate. It is a test-infrastructure change whose entire purpose — removing external network hits from tests — is something the repo's review guidance explicitly requires ("Never contact external network hosts or live registries"). The main risks would be (a) weakening the tests' coverage of the classification path in dependency.rs, or (b) introducing flakiness. Both are addressed: the specifiers keep the real github.com / gitpkg-fork.vercel.sh hosts (classification code path unchanged, verified by the author with a source probe), the http/https scheme handling is identical at the classification layer per the cited dependency.rs:946-957, and every prior assertion is preserved with additional exact-match assertions on top. I confirmed new Bun.Archive(files, {compress: "gzip"}).bytes() matches the documented API and that ctx.registry_url is a full URL whose hostname is what no_proxy needs.

Other factors

• No prior human or bot reviews to address; CodeRabbit was rate-limited.
• The helper follows harness conventions: port: 0, spreads env (bunEnv), await using for cleanup, no sleeps or timeouts.
• Response.clone() on the registered redirect keeps the fixture reusable across the (potential) two proxy hits without body-consumed errors.
• Runs under describe.concurrent safely — each iteration/test has its own server, context, and urls/proxied_urls arrays.
• The PR description includes empirical verification (debug + release builds pass with outside network blocked; main fails the same three tests under that condition), which is exactly the fails-for-the-right-reason check the review guide asks for.

[claude]

LGTM — test-only hermeticity fix that removes the github.com / gitpkg-fork.vercel.sh network dependency without weakening coverage.

Checked that the http_proxy + no_proxy approach preserves the real hostnames the dependency.rs classifier keys on, that registry_url ends in / so the concatenated assertion URLs and GITHUB_API_URL are well-formed, and that no_proxy: "localhost" matches the dummy registry host so registry traffic still hits ctx.requested/urls. The 302→codeload fixture keeps the cross-host-redirect coverage the old live test exercised implicitly, and the gitpkg assertion is strengthened from toHaveLength(2) to exact URLs. await using + server.stop(true) cleans up per test inside describe.concurrent.

Extended reasoning...

Overview

Single-file test change to test/cli/install/bun-install.test.ts. Adds a urlTarballProxy() helper (per-test Bun.serve({port: 0}) that answers registered absolute URLs with in-memory gzipped tarballs via Bun.Archive or a canned Response, 404 otherwise) and rewires three tests — the two GitHub /tarball/ tests (collapsed into a for loop over with_github_api_url) and the gitpkg-fork.vercel.sh test — to point bun install's http_proxy at it instead of fetching from the public internet. Dependencies switch from https:// to http:// so requests reach the proxy in absolute form rather than CONNECT-tunneling to the real host. No production code is touched.

Security risks

None. Test-only; the proxy is a local ephemeral server on port 0, torn down via await using. Nothing is exposed and no credentials or trust decisions are involved.

Level of scrutiny

Low-to-medium. This is a de-flaking / hermeticity change of exactly the kind REVIEW.md asks for ("never contact external network hosts"). The important thing to verify is that coverage is not silently reduced. It isn't: every prior assertion is retained verbatim (node_modules directory listing, stdout lines, lockfile presence, ctx.requested), the GitHub fixture reproduces the real 302→codeload.github.com redirect so redirect-following with original-URL resolution is still exercised, and two assertions are strengthened — proxied_urls is checked for exact order/contents and the gitpkg test's registry urls goes from toHaveLength(2) to an exact toEqual([...]). The https→http scheme change is justified against dependency.rs:946-957 (both schemes stripped identically before classification) and the TLS client path was never this test's subject.

Other factors

• Helper hygiene: port: 0, {...env, http_proxy, HTTP_PROXY, no_proxy, NO_PROXY} overrides both casings for Windows and any ambient proxy, Response.clone() guards against reuse, Symbol.asyncDispose → server.stop(true).
• registry_url is http://localhost:<port>/<id>/ (dummy.registry.ts:363/120), so new URL(ctx.registry_url).hostname === "localhost" matches no_proxy and the ${ctx.registry_url}loader-runner / ${ctx.registry_url}github/api concatenations are correct with no double slash.
• Bun.Archive is already used elsewhere in the test suite (e.g. test/js/bun/archive.test.ts, install registry package generators).
• The two near-identical GitHub tests are deduplicated into a loop rather than left as copy-paste, per the "second time a block appears, extract" rule.
• PR description documents verification on Linux debug+release and Windows x64 release, with and without a dead ambient proxy, plus a full-file run. No prior human review comments to address.

[claude]

LGTM — hermetic test fix that removes github.com / gitpkg-fork.vercel.sh network dependency from three URL-tarball install tests.

What was reviewed:

• urlTarballProxy helper: port 0, await using disposal, spreads bunEnv, sets both-case http_proxy/no_proxy for Windows — matches file conventions.
• Checked that all original assertions are preserved and strengthened (exact proxied_urls / registry urls lists replace toHaveLength(2); codeload redirect is asserted).
• Verified new Bun.Archive(files, { compress: "gzip" }).bytes() matches the documented API and ctx.registry_url is the established TestContext field.
• Confirmed the https→http switch does not weaken the classification-under-test (dependency.rs strips both schemes identically) and no_proxy keeps the dummy registry's urls/requested counters unaffected.

Extended reasoning...

Overview

Test-only change to test/cli/install/bun-install.test.ts. Adds a urlTarballProxy() helper that spins up a per-test Bun.serve({ port: 0 }) acting as an http_proxy, serving in-memory gzipped tarballs (via Bun.Archive) or canned redirects for registered URLs. The three URL-tarball tests (two GitHub /tarball/<ref> variants collapsed into a for loop, plus the gitpkg-fork.vercel.sh test) now point http_proxy at this server and use http:// specifiers, eliminating the external-host dependency that caused 503 flakes in CI builds 93264/93273. No production code is touched.

Security risks

None. This is test infrastructure only — a local loopback server serving fixture tarballs to a spawned bun install subprocess. No auth, crypto, or user-facing surface is involved.

Level of scrutiny

Low-to-medium. It's a test hermeticity fix, which the repo review guidelines explicitly encourage ("Never contact external network hosts or live registries — reproduce the condition with a local in-process server"). The main risk with such changes is silently weakening what the test asserts; I verified that every original assertion (stdout lines, readdirSorted listing, package.json name, lockfile access, ctx.requested count) is preserved, and new assertions on the exact proxied/registry URL sequences are strictly stronger than the old toHaveLength(2). The codeload 302 fixture keeps the cross-host-redirect coverage the live github.com endpoint provided implicitly.

Other factors

• The helper follows local conventions: await using for disposal, { ...env, ... } spreading bunEnv, port 0, and Response.clone() so a registered Response can be served more than once.
• Setting both http_proxy/HTTP_PROXY and no_proxy/NO_PROXY handles Windows' case-insensitive environment and overrides any ambient proxy in the parent env — the PR description confirms this was tested on Windows x64 with a dead ambient proxy.
• describe.concurrent is safe here: each test builds its own proxy inside its own withContext closure with an ephemeral port.
• The GITHUB_API_URL variant now points at ${ctx.registry_url}github/api instead of example.com, so a regression that misroutes the tarball URL through the GitHub API would show up in urls/ctx.requested rather than escaping to the network — an improvement over the original.
• The PR description documents debug+release verification on Linux and Windows, a full-file run, and a classification probe confirming the is_github_tarball_path branch still fires with the http:// specifier. No prior human reviews or outstanding comments on the timeline.

[robobun]

Heads-up from #38464, which adds a refusingProxy() helper to the same file (a local proxy the install and git are pointed at through http_proxy/https_proxy; it records every request, including CONNECTs, and answers 404, so the Registry URLs table and the invalid git URL case never touch a resolver). The two branches merge cleanly about 40 lines apart, which would leave two proxy helpers in the file. Whichever of the two lands second should fold its helper into the other: urlTarballProxy here is the same thing plus a map of URLs to serve, so it could become an optional argument of the shared helper.

[robobun]

Closing in favor of #42800. It has the same urlTarballProxy() helper and the same three converted tests. That includes the 302 redirect to codeload.github.com and the proxied URL assertions. It also converts the owner/repo cases in this file through GITHUB_API_URL.

The note above about refusingProxy() in #38464 now applies to #42800.