Use GitHub app token to access firecracker repo#24
Conversation
The "e2b-dev/firecracker" string was hardcoded as the default for five separate function parameters. Hoist it into a FIRECRACKER_REPO constant at module scope so future renames are a single-line change. Pure refactor — no behaviour change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Babis Chalios <babis.chalios@e2b.dev>
Route the git clone through a short-lived installation token supplied by the workflow as FIRECRACKER_REPO_TOKEN, using the x-access-token user. The token works for both public and private repositories, so the wiring is the same regardless of repo visibility — and gives us a higher rate limit ceiling than the default GITHUB_TOKEN. Fail loudly via :? if the env var is missing rather than falling back to unauthenticated clones, which would silently mask a misconfigured workflow. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Babis Chalios <babis.chalios@e2b.dev>
PR SummaryMedium Risk Overview Validation passes Reviewed by Cursor Bugbot for commit 2806c6b. Bugbot is set up for automated code reviews on this repo. Configure here. |
bchalios
force-pushed
the
feat/github-app-token
branch
from
e077682 to
149e05f
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 149e05f. Configure here.
Route both the validate job's gh_api calls and the build job's git clone through a short-lived installation token minted by actions/create-github-app-token@v2. The default GITHUB_TOKEN can't read repos outside this one, so it isn't enough on its own. Partition tokens by purpose rather than swapping GH_TOKEN wholesale: - GH_TOKEN stays the default GITHUB_TOKEN, used for fc-versions operations (gh release view in get_existing_release_assets, etc.). - FIRECRACKER_GH_TOKEN carries the App token. gh_api() in validate.py is the only firecracker-API path, so we override GH_TOKEN in its subprocess env to use this token instead. A simpler-looking design — set GH_TOKEN to the App token for the whole validate step — happens to work today because fc-versions is public and GitHub's API accepts any bearer token for public reads. But it would silently break the moment fc-versions flips private: get_existing_release_assets would 404, has_new_artifacts would always be true, and the publish job would do pointless extra work. The build job mints its own token only when check_release decided we actually need to build, avoiding a wasted mint on no-op runs, and passes it to build.sh as FIRECRACKER_REPO_TOKEN. publish/deploy keep using github.token — they only touch this repo and GCS, no firecracker access needed. Today this targets the public e2b-dev/firecracker repo. When the source flips to a private fork, only three things change: the FIRECRACKER_REPO constant in validate.py, the host string in build.sh, and the repositories list here. Requires two new repo secrets: FIRECRACKER_APP_ID and FIRECRACKER_APP_PRIVATE_KEY. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
bchalios
force-pushed
the
feat/github-app-token
branch
from
149e05f to
2806c6b
Compare
2 participants
Use a token created by a Github App to access (clone) the firecracker repo