Skip to content

fix(modules): GitHub API tarball endpoint so private repos install - #332

Merged
WebTigers merged 1 commit into
mainfrom
fix/private-tarball-api-endpoint
Oct 9, 2026
Merged

WebTigers merged 1 commit into
mainfrom
fix/private-tarball-api-endpoint

Conversation

@WebTigers

Copy link
Copy Markdown
Owner

What

Tiger_Module_Github::tarballUrl() returned GitHub's web archive URL
(github.com/<org>/<repo>/archive/<ref>.tar.gz), which 404s for a PRIVATE repo even with a valid
bearer token
. Switched to the API tarball endpoint
(api.github.com/repos/<org>/<repo>/tarball/<ref>), which honours the token and 302s to a signed
codeload URL. It works for public repos too, so one URL serves both the public directory and an
authenticated private/company source.

Why it surfaced now

The authenticated module-source feature (v1.20.0, #330) made the company private feed the first
caller to fetch a private repo directly with a token. Update detection uses the API and worked
(correctly saw TigerMarketing 0.2.0 → 0.3.0), but install fell through to tarballUrl() and failed
with "Failed to download the release tarball."

Verification

Live, against the private WebTigers/TigerMarketing with a fine-grained read-only token:

  • github.com/.../archive/v0.3.0.tar.gz → HTTP 404
  • api.github.com/repos/.../tarball/v0.3.0 → HTTP 200, 996 KB, via codeload

Unit: GithubTest + GithubParseTest updated; full tests/Unit/Module suite green (140 tests).

Scope

The licensed/authority path is unaffected — it mints its own signed URL (Tiger_License_Authority)
and never calls tarballUrl(). (A private release ZIP asset via browser_download_url has the same
web-host limitation and remains a separate follow-up; all current company modules are source/theme repos
that install from the tarball.)

🤖 Generated with Claude Code

https://claude.ai/code/session_01ASauLLscjqdsNqBNsx2Typ

…stall

tarballUrl() returned the web archive URL (github.com/<org>/<repo>/archive/<ref>.tar.gz),
which 404s for a PRIVATE repo even with a valid bearer token. The authenticated module-source
path (the company private feed) is the first caller to fetch a private repo directly, so it hit
the 404 on install while update DETECTION (which uses the API) worked. Switch to the API tarball
endpoint (api.github.com/repos/<org>/<repo>/tarball/<ref>), which honours the token and 302s to a
signed codeload URL; it works for public repos too, so one URL serves both. Verified live: the web
path returned 404 and the API endpoint 200 for a private repo with the same fine-grained token.

The licensed/authority path is unaffected — it mints its own signed URL and never calls tarballUrl().

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ASauLLscjqdsNqBNsx2Typ
@WebTigers
WebTigers merged commit efcaabb into main Oct 9, 2026
14 checks passed
@WebTigers
WebTigers deleted the fix/private-tarball-api-endpoint branch October 9, 2026 11:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant