Repository navigation
test-companion: fix signing in as the GitHub App, and say why it fails - #95
Open
naimish-browse wants to merge 2 commits into
Open
naimish-browse wants to merge 2 commits into
naimish-browse wants to merge 2 commits into
Conversation
Any failure to look up the App's installation was reported as "the GitHub App is not installed on this repository", hiding GitHub's real answer. A wrong App ID or a key from another App looked exactly like a missing installation. Now only a 404 is reported as "not installed". Any other failure is a warning that carries GitHub's own reason, e.g. "Bad credentials (HTTP 401)", and says which inputs to check. A failed token request also carries GitHub's reason. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Pre-merge checks:
  |
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Title check |  |
This assessment has not completed. The check will be retried on the next pre-merge check run. |
-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled.
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
gh sends its token as "Authorization: token ...", and GitHub accepts an App's JWT only as "Authorization: Bearer ...". So every App sign-in failed with "A JSON web token could not be decoded (HTTP 401)" and the Action fell back to github-actions[bot], even with the right App ID and key. Checked against the real App: through gh, 401; with Bearer, 200. The two calls made as the App (find the installation, get the token) now use fetch with Bearer. Everything after uses the installation token through gh as before. The two remaining silent fallbacks now say why. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
naimish-browse
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Signing in as the GitHub App never worked, and the Action hid why.
The bug. The Action sent the App's signed login (a JWT) through
gh.ghsends it asAuthorization: token …, but GitHub accepts an App's JWT only asAuthorization: Bearer …. So every sign-in failed withA JSON web token could not be decoded (HTTP 401), and the Action quietly fell back togithub-actions[bot], even with the correct App ID and key.Checked against the real App with the same key and App ID: through
gh, 401; withBearer, 200 and the installation found.What changes
fetchwithBearer. Everything after that uses the installation token throughgh, as before.Bad credentials (HTTP 401), and says to checkapp-idandapp-private-key. A failed token request and the two previously silent fallbacks now explain themselves too.GITHUB_API_URL, so GitHub Enterprise Server works too.The logged reason is GitHub's response message only, never the JWT or a token.
Tests: 9 new for the App calls and messages; all 700 pass.
🤖 Generated with Claude Code