test(install): serve GitHub tarball fixtures locally in bun-add.test.ts

Closed
RO
2mo ago
+140-8

Problem

test/cli/install/bun-add.test.ts went red on every retry in build 77839 (and 77787/77818) with:

error: GET https://api.github.com/repos/mishoo/UglifyJS/tarball/v3.14.1 - 504
error: mishoo/UglifyJS#v3.14.1 failed to resolve

Seven tests in this file fetch real tarballs from api.github.com (via the owner/repo#ref dependency form, which alloc_github_url turns into …/repos/{owner}/{repo}/tarball/{ref}). bun already retries 5xx up to max_retry_count times, but the retries are immediate with no backoff, so a GitHub 504 window exhausts all 6 attempts. The tests themselves exercise bun add's GitHub-shorthand handling (package.json writing, bin linking, cache folder naming, resolved-commit extraction from the tarball root directory), not GitHub.

Fix

Make the affected tests hermetic:

  • test/cli/install/dummy.registry.ts: add makeGithubTarball(rootDir, files) (builds a gzip'd tar whose single top-level directory matches GitHub's <owner>-<repo>-<short-sha> layout) and setGithubTarball(owner, repo, ref, bytes). The existing server now routes /repos/:owner/:repo/tarball/:ref to those fixtures so an install under test can point GITHUB_API_URL at it.
  • test/cli/install/bun-add.test.ts: register fixtures for mishoo/UglifyJS#v3.14.1, dylan-conway/install-test-3#v1.0.{0,1,2} and liz3/empty-bun-repo in beforeAll, and pass GITHUB_API_URL for the seven GitHub-tarball tests. The fixtures reproduce the exact directory listing, package.json name/version and bin entry the tests already assert, so every existing expect (including the @GH@mishoo-UglifyJS-e219a9a@@@1 cache-folder name and the e219a9a resolved commit in stdout, which bun reads from the tarball's root directory name) is preserved unchanged.

The two tests that go through git clone (should handle Git URL in dependencies (SCP-style) and git dep without package.json and with default branch) do not use GITHUB_API_URL and are left alone; #35035 addresses the SCP-style one.

Why this is the right fix

These tests have no reason to depend on api.github.com being up: they are asserting bun's behavior, and every byte of the GitHub response they care about is now produced locally. #34419 applied the same pattern (point GITHUB_API_DOMAIN at a local server) to bun create; this extends it to the install path's GITHUB_API_URL. The new makeGithubTarball/setGithubTarball helpers are exported so the other files in the same cluster (bunx.test.ts, bun-install-lifecycle-scripts.test.ts) can adopt them in their own follow-ups.

Verification

$ bun bd test test/cli/install/bun-add.test.ts
 54 pass
 0 fail
Ran 54 tests across 1 file. [21.66s]

Release build: 54 pass / 0 fail in 3.28s (down from ~58s before, since no network round-trips to GitHub). A couple of unrelated files that import dummy.registry.ts (bun-remove.test.ts, bun-install-retry.test.ts) behave identically before and after.

No single culprit PR: the live-GitHub dependency in these tests predates the Rust port.

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