Setup pi bot user

I have all the context I need. Let me create a comprehensive report and commit it to the repo.I've written the report to docs/setup-pi-bot.md (committed to main as d501721). Here's the summary.

How to make `pi` your Forgejo bot identity

The key idea: in Forgejo, the token determines who acts. Today your workflow runs with the auto-injected FORGEJO_TOKEN, so every reply/commit/PR is authored by the system account forgejo-actions (see the first reply above). To post as a dedicated pi user, you create that user and feed a PAT from it into the workflow.

Steps

Create a pi user (Site Admin → Users → New Account). Its username + avatar become the bot's public face — upload pi-logo.webp, add a bio. Make it a normal/restricted user.
Grant access — add pi as a Collaborator (Write) on each repo, or for your personal alex/* forge, an owner-level role.
Mint a scoped PAT as pi (Settings → Applications → Access Tokens) with minimal scopes: issue:write, pull_request:write, repository:write, plus reads. Set a 90-day expiry.
Store it as an Actions secret named PI_TOKEN — at the owner level so all alex/* repos inherit it. (Tokens go in secrets, never vars — secrets are masked, variables are not.)
Point the workflow at it — the one-line change that flips the identity:

        with:
          github_token: ${{ secrets.PI_TOKEN }}   # was: ${{ env.FORGEJO_TOKEN }}

Verify — comment /pi who are you?; the reply should now show as @pi with the logo.

Watch-outs

Keep scopes minimal + expiry short; rotate before expiry.
If main/branches are protected, allow pi (or token pushes) to bypass, or commits/merges get blocked.
/pi currently triggers for any comment — consider restricting who can invoke it.

Full details (background, scope table, alternatives, security checklist) are in docs/setup-pi-bot.md. Want me to apply the Step 5 workflow edit as a PR?

I have all the context I need. Let me create a comprehensive report and commit it to the repo.I've written the report to `docs/setup-pi-bot.md` (committed to `main` as `d501721`). Here's the summary. ## How to make `pi` your Forgejo bot identity **The key idea:** in Forgejo, *the token determines who acts*. Today your workflow runs with the auto-injected `FORGEJO_TOKEN`, so every reply/commit/PR is authored by the system account **`forgejo-actions`** (see the first reply above). To post as a dedicated **`pi`** user, you create that user and feed a PAT from it into the workflow. ### Steps 1. **Create a `pi` user** (Site Admin → Users → New Account). Its username + avatar become the bot's public face — upload `pi-logo.webp`, add a bio. Make it a normal/restricted user. 2. **Grant access** — add `pi` as a **Collaborator (Write)** on each repo, or for your personal `alex/*` forge, an owner-level role. 3. **Mint a scoped PAT** as `pi` (Settings → Applications → Access Tokens) with minimal scopes: `issue:write`, `pull_request:write`, `repository:write`, plus reads. Set a 90-day expiry. 4. **Store it as an Actions *secret*** named `PI_TOKEN` — at the **owner level** so all `alex/*` repos inherit it. (Tokens go in `secrets`, never `vars` — secrets are masked, variables are not.) 5. **Point the workflow at it** — the one-line change that flips the identity: ```yaml with: github_token: ${{ secrets.PI_TOKEN }} # was: ${{ env.FORGEJO_TOKEN }} ``` 6. **Verify** — comment `/pi who are you?`; the reply should now show as **`@pi`** with the logo. ### Watch-outs - Keep scopes minimal + expiry short; rotate before expiry. - If `main`/branches are protected, allow `pi` (or token pushes) to bypass, or commits/merges get blocked. - `/pi ` currently triggers for **any** comment — consider restricting who can invoke it. Full details (background, scope table, alternatives, security checklist) are in **[`docs/setup-pi-bot.md`](../blob/main/docs/setup-pi-bot.md)**. Want me to apply the Step 5 workflow edit as a PR? --- [View action run](https://forge.l3x.in/alex/.profile/actions/runs/2) | Model: zai/glm-5.2 (thinking: xhigh) | Time: 2m 23s | Tokens: 38.8K | Pi SDK v0.80.3 | Action v2.25.0-develop (develop @ 0e171ae)

alex commented

2026-07-01 09:22:02 +00:00

Author

Owner

/pi update every Pi workflow in this forge to restrict trigger to admins, create PRs accordingly

forgejo-actions referenced this issue from a commit

2026-07-01 09:24:27 +00:00

ci: restrict Pi workflow trigger to repo admins

forgejo-actions referenced this issue

2026-07-01 09:24:46 +00:00

ci: restrict Pi workflow trigger to repo admins #2

forgejo-actions commented

2026-07-01 09:25:19 +00:00

I have the full context. There's one Pi workflow (.forgejo/workflows/pi.yml) that currently triggers on /pi for any commenter. The task is to restrict it to admins. Let me make the change and open a PR.The change is applied. Now let me create a branch, commit, push, and open a PR. Since this is Forgejo, I'll use the Forgejo API directly with the available token.PR created. Let me verify it looks correct.Done.

This forge has a single Pi workflow — .forgejo/workflows/pi.yml — so one PR covers it.

PR #2 → #2 — ci: restrict Pi workflow trigger to repo admins

What changed

Added an author_association guard to the pi-agent job's if so /pi only fires for repo admins:

 jobs:
   pi-agent:
+    # Only repo admins/owners (OWNER / MEMBER) may invoke Pi.
     if: |
       (startsWith(github.event.comment.body, '/pi ') || startsWith(github.event.review.body, '/pi '))
+      && (github.event.comment.author_association == 'OWNER'
+          || github.event.comment.author_association == 'MEMBER')

OWNER → the repo owner (covers personal forges like this one, where alex is owner).
MEMBER → org members with admin rights (covers org-owned repos).

Non-admin commenters (CONTRIBUTOR, NONE, FIRST_TIME_CONTRIBUTOR, …) are now silently skipped by the job. This closes the gap the bot-setup report flagged — previously any registered user could invoke the agent and the LLM spend / repo write that comes with it. This matches how I (the bot) was able to run just now: your comment is OWNER-associated, so it still triggers.

If you'd prefer a tighter or looser policy (e.g. OWNER-only for this personal forge, or also allowing COLLABORATOR), say the word and I'll adjust.

I have the full context. There's one Pi workflow (`.forgejo/workflows/pi.yml`) that currently triggers on `/pi ` for **any** commenter. The task is to restrict it to admins. Let me make the change and open a PR.The change is applied. Now let me create a branch, commit, push, and open a PR. Since this is Forgejo, I'll use the Forgejo API directly with the available token.PR created. Let me verify it looks correct.Done. This forge has a single Pi workflow — `.forgejo/workflows/pi.yml` — so one PR covers it. **PR #2 → https://forge.l3x.in/alex/.profile/pulls/2** — *ci: restrict Pi workflow trigger to repo admins* ### What changed Added an `author_association` guard to the `pi-agent` job's `if` so `/pi ` only fires for repo admins: ```diff jobs: pi-agent: + # Only repo admins/owners (OWNER / MEMBER) may invoke Pi. if: | (startsWith(github.event.comment.body, '/pi ') || startsWith(github.event.review.body, '/pi ')) + && (github.event.comment.author_association == 'OWNER' + || github.event.comment.author_association == 'MEMBER') ``` - **`OWNER`** → the repo owner (covers personal forges like this one, where `alex` is owner). - **`MEMBER`** → org members with admin rights (covers org-owned repos). Non-admin commenters (`CONTRIBUTOR`, `NONE`, `FIRST_TIME_CONTRIBUTOR`, …) are now silently skipped by the job. This closes the gap the bot-setup report flagged — previously *any* registered user could invoke the agent and the LLM spend / repo write that comes with it. This matches how I (the bot) was able to run just now: your comment is `OWNER`-associated, so it still triggers. If you'd prefer a tighter or looser policy (e.g. `OWNER`-only for this personal forge, or also allowing `COLLABORATOR`), say the word and I'll adjust. --- [View action run](https://forge.l3x.in/alex/.profile/actions/runs/3) | Model: zai/glm-5.2 (thinking: xhigh) | Time: 3m 17s | Tokens: 93.9K | Pi SDK v0.80.3 | Action v2.25.0-develop (develop @ 0e171ae)

alex commented

2026-07-01 09:51:17 +00:00

Author

Owner

/pi can we have a single reusable Pi workflow and just refer to it from other workflows in this forge?

forgejo-actions referenced this issue

2026-07-01 09:57:00 +00:00

ci: make the Pi workflow reusable across the forge #3

forgejo-actions commented

2026-07-01 09:57:16 +00:00

The Forgejo version is 15.0.3, so reusable workflows (workflow_call) are fully supported. Let me implement this — refactoring pi.yml into a reusable workflow and adding docs + a drop-in wrapper for other repos.Everything looks correct. Let me create the PR with these changes.The PR tool hit a 404 (likely a Forgejo API path difference). Let me do it directly via git + the Forgejo API.Branch pushed. Now let me open the PR via the Forgejo API.Yes — that's exactly the right instinct, and Forgejo 15 supports it via standard reusable workflows. Done in PR #3 → #3.

Short answer

You can't have zero config per repo (Forgejo dispatches issue_comment per repo, so one workflow can't auto-run across all of them), but you can have one source of truth that every repo delegates to with a 4-line wrapper. That's strictly better than copying the full file.

What changed

.forgejo/workflows/pi.yml → now a reusable workflow: added the workflow_call trigger alongside the existing issue_comment one. So alex/.profile keeps firing directly (it's its own consumer, no wrapper needed), and every other repo can call it.
docs/examples/pi.yml → ready-to-copy drop-in wrapper.
docs/reusable-pi-workflow.md → full guide.

How another repo enables Pi

Drop this at .forgejo/workflows/pi.yml in any alex/* repo:

name: Pi AI Agent
on:
  issue_comment:
    types: [created]
permissions:
  contents: write
  issues: write
  pull-requests: write
jobs:
  pi-agent:
    uses: alex/.profile/.forgejo/workflows/pi.yml@main
    secrets: inherit

It works because the comment event propagates into the called workflow (so the if guard and github.event.comment still resolve), actions/checkout checks out that repo (github.repository = the caller), and owner-level secrets/vars (LLM_API_KEY, MODEL, …) are inherited via secrets: inherit.

Why this is the right move for #1

This is where reuse and the pi bot identity compound: when PI_TOKEN is set up (per docs/setup-pi-bot.md), flipping github_token from ${{ env.FORGEJO_TOKEN }} to ${{ secrets.PI_TOKEN }} in this one file makes every consuming repo post as @pi — instead of editing N repos. I left the token untouched in this PR so nothing breaks; it's a one-line follow-up once the PAT exists. PR #2 (admin-only trigger) is independent and merges cleanly against this.

The Forgejo version is 15.0.3, so reusable workflows (`workflow_call`) are fully supported. Let me implement this — refactoring `pi.yml` into a reusable workflow and adding docs + a drop-in wrapper for other repos.Everything looks correct. Let me create the PR with these changes.The PR tool hit a 404 (likely a Forgejo API path difference). Let me do it directly via git + the Forgejo API.Branch pushed. Now let me open the PR via the Forgejo API.Yes — that's exactly the right instinct, and Forgejo 15 supports it via standard **reusable workflows**. Done in **PR #3 → https://forge.l3x.in/alex/.profile/pulls/3**. ## Short answer You can't have *zero* config per repo (Forgejo dispatches `issue_comment` **per repo**, so one workflow can't auto-run across all of them), but you can have **one source of truth** that every repo delegates to with a 4-line wrapper. That's strictly better than copying the full file. ## What changed - **`.forgejo/workflows/pi.yml`** → now a reusable workflow: added the `workflow_call` trigger alongside the existing `issue_comment` one. So `alex/.profile` keeps firing directly (it's its own consumer, no wrapper needed), and every other repo can call it. - **`docs/examples/pi.yml`** → ready-to-copy drop-in wrapper. - **`docs/reusable-pi-workflow.md`** → full guide. ## How another repo enables Pi Drop this at `.forgejo/workflows/pi.yml` in any `alex/*` repo: ```yaml name: Pi AI Agent on: issue_comment: types: [created] permissions: contents: write issues: write pull-requests: write jobs: pi-agent: uses: alex/.profile/.forgejo/workflows/pi.yml@main secrets: inherit ``` It works because the comment event propagates into the called workflow (so the `if` guard and `github.event.comment` still resolve), `actions/checkout` checks out *that* repo (`github.repository` = the caller), and owner-level `secrets`/`vars` (`LLM_API_KEY`, `MODEL`, …) are inherited via `secrets: inherit`. ## Why this is the right move for #1 This is where reuse and the `pi` bot identity compound: when `PI_TOKEN` is set up (per `docs/setup-pi-bot.md`), flipping `github_token` from `${{ env.FORGEJO_TOKEN }}` to `${{ secrets.PI_TOKEN }}` in this **one** file makes *every* consuming repo post as `@pi` — instead of editing N repos. I left the token untouched in this PR so nothing breaks; it's a one-line follow-up once the PAT exists. PR #2 (admin-only trigger) is independent and merges cleanly against this. --- [View action run](https://forge.l3x.in/alex/.profile/actions/runs/5) | Model: zai/glm-5.2 (thinking: xhigh) | Time: 6m | Tokens: 169.3K | Pi SDK v0.80.3 | Action v2.25.0-develop (develop @ 0e171ae)

alex commented

2026-07-01 10:34:10 +00:00

Author

Owner

/pi what's missing from this ticket?

forgejo-actions commented

2026-07-01 10:35:34 +00:00

Looking at the ticket against the plan in docs/setup-pi-bot.md, the supporting work is in place but the core deliverable of the ticket isn't actually done — the bot still isn't pi. Here's what's missing:

1. The identity switch itself (the whole point)

.forgejo/workflows/pi.yml still uses the auto token:

          github_token: ${{ env.FORGEJO_TOKEN }}

That's the one-line change (report Step 5) that makes the agent act as pi. It was explicitly deferred in PR #3, so every reply is still authored by @forgejo-actions — including the one you're reading right now. Until that flips to ${{ secrets.PI_TOKEN }}, the bot user is not "set up" in any observable sense.

2. The manual prerequisites (Steps 1–4) — no evidence they're done

No pi account confirmed to exist (logo pi-logo.webp was dropped in comment 1 but there's no sign it's uploaded to a user).
No PI_TOKEN Actions secret (owner-level) — proven by point 1: if it existed and were wired, replies would already show @pi.
No PAT minted, no scopes/expiry chosen, no access granted to repos.

These are admin-side and can't be done from code, but the ticket should track them so "done" is verifiable.

3. No acceptance criteria / definition of done

The ticket body is just the logo image — there's no checklist. The report's own Security checklist is entirely unchecked, and there's nothing stating what "setup pi bot user" means as a gate (e.g. "/pi who are you? replies as @pi; commits pushed by agent are authored by pi").

4. Scope note

The thread has produced two real PRs (#2 admin-only trigger, #3 reusable workflow) — both useful, but arguably scope creep relative to the ticket's title. They should probably live as their own issues so #1 can close cleanly on the identity setup alone.

TL;DR: the report, admin-gating, and reusable workflow are done; what's missing is the pi identity actually existing and being used — the PI_TOKEN secret + the one-line github_token swap. Want me to open a PR making the pi.yml change (Step 5) so it's ready the moment you create the pi user + PI_TOKEN secret?

Looking at the ticket against the plan in `docs/setup-pi-bot.md`, the supporting work is in place but the **core deliverable of the ticket isn't actually done** — the bot still isn't `pi`. Here's what's missing: ### 1. The identity switch itself (the whole point) `.forgejo/workflows/pi.yml` still uses the auto token: ```yaml github_token: ${{ env.FORGEJO_TOKEN }} ``` That's the one-line change (report Step 5) that makes the agent act as `pi`. It was explicitly deferred in PR #3, so **every reply is still authored by `@forgejo-actions`** — including the one you're reading right now. Until that flips to `${{ secrets.PI_TOKEN }}`, the bot user is not "set up" in any observable sense. ### 2. The manual prerequisites (Steps 1–4) — no evidence they're done - No **`pi` account** confirmed to exist (logo `pi-logo.webp` was dropped in comment 1 but there's no sign it's uploaded to a user). - No **`PI_TOKEN`** Actions secret (owner-level) — proven by point 1: if it existed and were wired, replies would already show `@pi`. - No PAT minted, no scopes/expiry chosen, no access granted to repos. These are admin-side and can't be done from code, but the ticket should track them so "done" is verifiable. ### 3. No acceptance criteria / definition of done The ticket body is just the logo image — there's no checklist. The report's own **Security checklist** is entirely unchecked, and there's nothing stating what "setup pi bot user" means as a gate (e.g. *"`/pi who are you?` replies as @pi; commits pushed by agent are authored by pi"*). ### 4. Scope note The thread has produced two real PRs (#2 admin-only trigger, #3 reusable workflow) — both useful, but arguably **scope creep** relative to the ticket's title. They should probably live as their own issues so #1 can close cleanly on the identity setup alone. --- **TL;DR:** the report, admin-gating, and reusable workflow are done; what's *missing* is the `pi` identity actually existing and being used — the `PI_TOKEN` secret + the one-line `github_token` swap. Want me to open a PR making the `pi.yml` change (Step 5) so it's ready the moment you create the `pi` user + `PI_TOKEN` secret? --- [View action run](https://forge.l3x.in/alex/.profile/actions/runs/6) | Model: zai/glm-5.2 (thinking: xhigh) | Time: 1m 24s | Tokens: 26.1K | Pi SDK v0.80.3 | Action v2.25.0-develop (develop @ 0e171ae)

alex closed this issue

2026-07-12 12:12:42 +00:00

Rows
Columns

Setup pi bot user #1

How to make pi your Forgejo bot identity

Steps

Watch-outs

What changed

Short answer

What changed

How another repo enables Pi

Why this is the right move for #1

1. The identity switch itself (the whole point)

2. The manual prerequisites (Steps 1–4) — no evidence they're done

3. No acceptance criteria / definition of done

4. Scope note

How to make `pi` your Forgejo bot identity