Pi flow doesn't work on org repos #13

Closed
opened 2026-08-14 18:20:16 +00:00 by alex · 2 comments
Owner

(startsWith(forgejo.event.comment.body, '/pi ') && forgejo.event.sender.login == forgejo.repository_owner)

Seems that this isn't enough to run from org/repo kind of repos

https://forge.l3x.in/alex/.profile/src/commit/6308490c219ffe9db2f02c68f93cd4460486d7ee/.forgejo/workflows/pi.yml#L21 Seems that this isn't enough to run from org/repo kind of repos
Author
Owner

/pi let's fix it

/pi let's fix it
Contributor

The referenced line is the job's if: guard: forgejo.event.sender.login == forgejo.repository_owner. On org-owned repos the "owner" is the organization, so a commenting user can never match it — the job is always skipped there. Let me verify my planned fix (API-based permission check) actually works against this Forgejo instance before wiring it into the workflow:The API check works and correctly distinguishes owner/admin from everyone else. Now let me apply the fix:Workflow is valid. Now let me update the docs to match the new authorization model and document the org-repo requirements:Both paths verified (owner → allowed, stranger → denied with a clear error). Creating the PR:Fixed in #14#14

Root cause: the guard compared the commenting user against forgejo.repository_owner. On org/repo repositories the "owner" is the organization itself, so sender.login == repository_owner can never match and the job was always skipped.

The fix:

  • The job-level if: now only gates on the /pi prefix (issue comment, review comment, or review body — the latter also restores review-triggering dropped in 6fb8f3b).
  • A new Authorize invoker step queries the Forgejo API for the sender's effective permission on the repo (/repos/{owner}/{repo}/collaborators/{sender}/permission using PI_TOKEN): owner/admin → agent runs; anything else → job fails with a clear ::error:: annotation so unauthorized attempts are visible instead of silently skipped.
  • Works identically for user/repo and org/repo (org owners/admins get owner/admin on org repos). Verified live against the forge: repo owner → allowed, non-collaborator → denied.
  • docs/setup-pi-bot.md updated with org-repo requirements (pi as site/org admin so the permission query works; PI_TOKEN + model vars at org level) and the now-accurate access-control note.

After merge, /pi on any org repo should work — worth a quick /pi ping on the org repo that was failing to confirm.


View action run | Model: zai/glm-5.2 (thinking: max) | Time: 7m 17s | Tokens: 333.5K | Pi SDK v0.84.0 | Action v2.27.0-develop (develop @ ee8f1d1)

The referenced line is the job's `if:` guard: `forgejo.event.sender.login == forgejo.repository_owner`. On org-owned repos the "owner" is the organization, so a commenting user can **never** match it — the job is always skipped there. Let me verify my planned fix (API-based permission check) actually works against this Forgejo instance before wiring it into the workflow:The API check works and correctly distinguishes owner/admin from everyone else. Now let me apply the fix:Workflow is valid. Now let me update the docs to match the new authorization model and document the org-repo requirements:Both paths verified (owner → allowed, stranger → denied with a clear error). Creating the PR:Fixed in #14 — https://forge.l3x.in/alex/.profile/pulls/14 **Root cause:** the guard compared the commenting user against `forgejo.repository_owner`. On `org/repo` repositories the "owner" is the organization itself, so `sender.login == repository_owner` can never match and the job was always skipped. **The fix:** - The job-level `if:` now only gates on the `/pi ` prefix (issue comment, review comment, or review body — the latter also restores review-triggering dropped in 6fb8f3b). - A new **Authorize invoker** step queries the Forgejo API for the sender's effective permission on the repo (`/repos/{owner}/{repo}/collaborators/{sender}/permission` using `PI_TOKEN`): `owner`/`admin` → agent runs; anything else → job fails with a clear `::error::` annotation so unauthorized attempts are visible instead of silently skipped. - Works identically for `user/repo` and `org/repo` (org owners/admins get `owner`/`admin` on org repos). Verified live against the forge: repo owner → allowed, non-collaborator → denied. - `docs/setup-pi-bot.md` updated with org-repo requirements (`pi` as site/org admin so the permission query works; `PI_TOKEN` + model vars at org level) and the now-accurate access-control note. After merge, `/pi` on any org repo should work — worth a quick `/pi ping` on the org repo that was failing to confirm. --- [View action run](https://forge.l3x.in/alex/.profile/actions/runs/14) | Model: zai/glm-5.2 (thinking: max) | Time: 7m 17s | Tokens: 333.5K | Pi SDK v0.84.0 | Action v2.27.0-develop (develop @ ee8f1d1)
alex closed this issue 2026-08-15 20:58:04 +00:00
Sign in to join this conversation.
No labels
dependencies
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
alex/.profile#13
No description provided.