fix(ci): setup-bun action rate-limited on api.github.com (post-suspension TOOLING gap) #3

Closed
opened 2026-05-07 10:05:37 +00:00 by Ghost · 0 comments

Symptom

Test / bun test (push) fails consistently with:

::error::Error: Failed to fetch url
  https://api.github.com/repos/oven-sh/bun/git/refs/tags.
  (status code: 403, status text: rate limit exceeded)
{"message":"API rate limit exceeded for 5.78.80.188.
 (But here's the good news: Authenticated requests get a higher rate limit.)"

(Latest: task 1265, 2026-05-07 10:01-10:02.)

Root cause

oven-sh/setup-bun@v2 resolves the latest bun release tag via unauthenticated api.github.com calls. Operator host (5.78.80.188) makes many of these calls per CI cycle (every setup-* action does similar API resolution), so the unauthenticated 60-req/hr quota is exhausted quickly.

This is the same TOOLING-class that bit setup-go earlier (the actions/go-versions manifest fetch); fixed there by GITHUB_SERVER_URL env. setup-bun's tag-resolution is a different code path that doesn't consult server_url.

Proposed fixes

  1. Pin a bun version explicitly + skip tag resolution: pass bun-version: 1.x.y (concrete) in the workflow. setup-bun then skips the api.github.com tag-list call. Smallest diff, no auth.
  2. Pin via bun-version-file: point at .bun-version or package.json engines.bun. Same effect.
  3. Pass a github.com PAT to setup-bun via token: input: gives auth, raises rate limit. Defeats the post-suspension goal of removing github.com auth dependency. Not recommended.
  4. Vendor bun into the catthehacker runner image: pre-install bun at image-build time, skip the setup-bun action entirely. Best long-term; needs derivative image.

Option 1 (pin a version) is the smallest correct fix. Pick the bun version this repo is currently testing against and hardcode it.

Acceptance criteria

  • Workflow no longer hits api.github.com for tag resolution
  • Test / bun test passes on next push
  • Bun version is explicit (pinned) for reproducibility

Routing

Whoever owns the mcp-claude-channel codebase / its CI workflow.

Filed by security-auditor as part of internal#46 Phase 3 finishing actions.

## Symptom `Test / bun test (push)` fails consistently with: ``` ::error::Error: Failed to fetch url https://api.github.com/repos/oven-sh/bun/git/refs/tags. (status code: 403, status text: rate limit exceeded) {"message":"API rate limit exceeded for 5.78.80.188. (But here's the good news: Authenticated requests get a higher rate limit.)" ``` (Latest: task 1265, 2026-05-07 10:01-10:02.) ## Root cause `oven-sh/setup-bun@v2` resolves the latest bun release tag via unauthenticated `api.github.com` calls. Operator host (5.78.80.188) makes many of these calls per CI cycle (every `setup-*` action does similar API resolution), so the unauthenticated 60-req/hr quota is exhausted quickly. This is the same TOOLING-class that bit `setup-go` earlier (the `actions/go-versions` manifest fetch); fixed there by `GITHUB_SERVER_URL` env. setup-bun's tag-resolution is a different code path that doesn't consult `server_url`. ## Proposed fixes 1. **Pin a bun version explicitly + skip tag resolution**: pass `bun-version: 1.x.y` (concrete) in the workflow. setup-bun then skips the api.github.com tag-list call. Smallest diff, no auth. 2. **Pin via `bun-version-file`**: point at `.bun-version` or `package.json` `engines.bun`. Same effect. 3. **Pass a github.com PAT to setup-bun via `token:` input**: gives auth, raises rate limit. Defeats the post-suspension goal of removing github.com auth dependency. Not recommended. 4. **Vendor bun into the catthehacker runner image**: pre-install bun at image-build time, skip the `setup-bun` action entirely. Best long-term; needs derivative image. ## Recommended Option 1 (pin a version) is the smallest correct fix. Pick the bun version this repo is currently testing against and hardcode it. ## Acceptance criteria - [ ] Workflow no longer hits api.github.com for tag resolution - [ ] `Test / bun test` passes on next push - [ ] Bun version is explicit (pinned) for reproducibility ## Routing Whoever owns the mcp-claude-channel codebase / its CI workflow. Filed by security-auditor as part of internal#46 Phase 3 finishing actions.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: molecule-ai/molecule-mcp-claude-channel#3
No description provided.