fix(ci): read private cloud PRs in docs-sync via a GitHub App token - #13081
fix(ci): read private cloud PRs in docs-sync via a GitHub App token#13081RSO wants to merge 1 commit into
Conversation
Kilo-Org/cloud is now private, so GITHUB_TOKEN can no longer see it and collect.mjs's `repo:Kilo-Org/cloud` search 422s, failing the whole run. Mint a read-only GitHub App installation token for the collect step only.
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| app-id: ${{ secrets.DOCS_SYNC_APP_ID }} | ||
| private-key: ${{ secrets.DOCS_SYNC_APP_SECRET }} | ||
| owner: ${{ github.repository_owner }} | ||
| repositories: cloud,kilocode |
There was a problem hiding this comment.
SUGGESTION: Down-scope the minted token with explicit permissions
actions/create-github-app-token v2 issues the installation token with every permission granted to the app. If the docs-sync app later gains additional permissions (or already has more than Pull requests: read), this token silently carries them into the collect step. Since the PR's intent is a strictly read-only token, consider making that explicit so it holds regardless of future app-permission changes:
repositories: cloud,kilocode
permission-pull-requests: readReply with @kilocode-bot fix it to have Kilo Code address this issue.
|
Hey @RSO why is Cloud private? @emilieschario said very clearly that it wouldn't be privated: 
Tracked in #12970 I think it would be more productive to address the root cause (make Cloud public) instead of this PR. That would also make CI pass and keep docs up to date more transparently. |
2 participants
What
docs-syncnow mints a read-only GitHub App installation token for theCollect merged PRsstep, instead of usinggithub.tokenfor it.Why
collect.mjsis the only place that crosses repo boundaries. It needs exactly three reads on each source repo:GET /search/issues,GET /repos/…/pulls/{n}, andGET /repos/…/pulls/{n}/files— all covered byPull requests: read.Follow-ups worth deciding separately
collect.mjsshould degrade like the per-PR fetches already do, so a future access regression doesn't block the whole bot.