Repository navigation
ci(guardian): post reviews as the codegraph-brain GitHub App when configured - #735
Conversation
…figured With vars.GUARDIAN_APP_CLIENT_ID and secrets.GUARDIAN_APP_PRIVATE_KEY set, the review job mints an installation token (actions/create-github-app-token v3.2.0, pinned) and both posting paths use it, so reviews come from codegraph-brain[bot]. Without them the step is skipped and posting falls back to GITHUB_TOKEN, as before. The app's key reaches every repository the app is installed on, so the token is narrowed to this repository and to pull-requests: write, and it is minted after every step that touches the PR checkout. The workflow tests pin the condition, the pin, the scope, the permissions, the fallback on both posting paths and the ordering. Closes #734 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds unit tests to tests/unit/test_guardian_workflow.py to verify the behavior, scoping, and execution order of the GitHub App token minting process in the Guardian workflow. The review feedback suggests a more robust and simplified approach to finding the index of the minted step directly from the steps list instead of mapping and looking up by name.
Review of #735: the ordering test missed a token handed to the ingest step and a mint placed before it. A new test pins that only the two posting steps reference steps.app-token; the ordering test now also counts steps that name pr/ in their command. Both misses were seen failing. The workflow comment no longer claims a silent fallback: with the variable set, a missing or wrong key or a missing installation fails the job before any LLM call. It also notes the token's one-hour lifetime. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
From Gemini's review of #735. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
/guardian review |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary: Checked the app-token gating: the if condition, the fallback to github.token when the step is skipped, and the posting steps all resolve correctly. Checked that the new tests reference only the posting steps and are ordered after the PR checkout steps. The main open question is whether the narrowed token permissions cover everything the review step reads.
🤖 claude-haiku-5-5 · 10,543 prompt + 3,056 completion = 13,599 tokens · graph 0/2 files (0%)
| # provider's default ("low"). #246 J measured the finder at "medium". | ||
| GUARDIAN_ANTHROPIC_EFFORT: ${{ vars.GUARDIAN_ANTHROPIC_EFFORT }} | ||
| GH_TOKEN: ${{ github.token }} | ||
| GH_TOKEN: ${{ steps.app-token.outputs.token || github.token }} |
There was a problem hiding this comment.
🟠 [Library Contract] — App token narrowed to pull-requests only may break the review step's GitHub reads
The minted app token requests only permission-pull-requests: write, so any contents read the review step performs through GH_TOKEN (for example gh api on repository files) would fail once the app token is in use, while github.token worked before.
Fix: Confirm every gh call in the Run Guardian Review step needs only pull-request access, or add permission-contents: read to the create-github-app-token step and extend the permissions test accordingly.
There was a problem hiding this comment.
No change needed. The only GitHub call the review step makes with GH_TOKEN is POST repos/{repo}/pulls/{pr}/reviews (src/cgis/guardian/github_poster.py:128). The diff and the files come from local git in pr/. GitHub's permission table lists that endpoint under Pull requests: write, and the fallback issues.createComment on a PR is covered by the same permission. The independent review of this PR checked both against the docs.
| if: steps.guardian.outputs.posted_inline != 'true' | ||
| uses: peter-evans/create-or-update-comment@a111a2c3bacd7be7898ee22d0d71d9aec2bb972c # v4 | ||
| with: | ||
| token: ${{ steps.app-token.outputs.token || github.token }} |
There was a problem hiding this comment.
🟡 [Logic Bug] — Token expiry can silently drop the fallback comment for long reviews
The app token is minted before the review and lasts one hour, so a review that runs past that window would leave both the inline post and the fallback comment failing with an authentication error and no report posted.
Fix: Mint the token immediately before each posting step, or have the fallback step fall back to github.token when the app token request fails.
There was a problem hiding this comment.
Fixed in fc9daf5: the review job has timeout-minutes: 45, below the token's 60-minute lifetime, so a review cannot outlive the token it posts with. Pinned by test_the_review_job_ends_before_the_app_token_expires.
From guardian's review of #735: a review running past the installation token's hour would fail both posting paths. The job now has timeout-minutes: 45, pinned by a test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Closes #734.
Change
Mint GitHub App token:actions/create-github-app-tokenv3.2.0, pinned to its SHA.vars.GUARDIAN_APP_CLIENT_IDis set.repositories: ${{ github.event.repository.name }}) and topermission-pull-requests: writeonly.pr/.steps.app-token.outputs.token || github.token:GH_TOKENfor the inline review,token:for the fallback comment.To switch it on (maintainer)
zaebee/codegraph-brain. With the variables set but no installation, the mint step fails the job loudly.gh secret set GUARDIAN_APP_PRIVATE_KEY --repo zaebee/codegraph-brain < key.pemgh variable set GUARDIAN_APP_CLIENT_ID --repo zaebee/codegraph-brain --body <Client ID>contentspermission from write to read. Nothing here needs it.🤖 Generated with Claude Code