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

Merged

alex merged 2 commits from pi-reusable-workflow into main

2026-07-01 10:24:25 +00:00

forgejo-actions commented

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

What

Turns alex/.profile/.forgejo/workflows/pi.yml into a reusable workflow so every repo in the forge can invoke the same Pi definition instead of duplicating it.

Closes the request in #1: "can we have a single reusable Pi workflow and just refer to it from other workflows in this forge?"

Why

Today any repo that wants Pi must copy the whole workflow — action reference, model/provider wiring, the who-may-invoke guard, the token config — and the copies drift apart. Forgejo 15 supports the standard workflow_call reusable-workflow pattern, so we can have one source of truth and let other repos delegate with a 4-line wrapper.

Changes

.forgejo/workflows/pi.yml — added the workflow_call trigger (kept issue_comment too, so .profile is its own consumer and needs no wrapper). No change to behaviour for this repo.
docs/examples/pi.yml — ready-to-copy drop-in wrapper for any other repo: uses: alex/.profile/.forgejo/workflows/pi.yml@main + secrets: inherit.
docs/reusable-pi-workflow.md — full guide: the wrapper, how event/github.repository/secrets/vars propagate through a called workflow, why each repo still needs a tiny file (per-repo issue_comment dispatch), and how this dovetails with the pi bot identity (PI_TOKEN becomes a one-line edit that applies forge-wide).

How other repos consume it

# .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

When /pi … is commented in that repo, the wrapper fires, the comment event is propagated into the called workflow (so the if guard and github.event.comment still work), actions/checkout checks out that repo (github.repository = the caller), and owner-level secrets/vars (LLM_API_KEY, MODEL, …) are inherited.

Notes / trade-offs

You can't have zero per-repo config: Forgejo dispatches issue_comment per repo, so one workflow can't auto-run across all of them. The reusable pattern centralises the logic; each repo only carries the delegating wrapper — strictly better than copying the full file.
Token identity unchanged in this PR (env.FORGEJO_TOKEN) to avoid breaking the working setup. Once PI_TOKEN exists (per docs/setup-pi-bot.md), flipping github_token in this one file makes every consuming repo post as @pi — which is the main payoff of combining this with #1.
The in-flight admin-restriction change (#2) is independent and will merge cleanly against this if guard.

## What Turns `alex/.profile/.forgejo/workflows/pi.yml` into a **reusable workflow** so every repo in the forge can invoke the same Pi definition instead of duplicating it. Closes the request in #1: _"can we have a single reusable Pi workflow and just refer to it from other workflows in this forge?"_ ## Why Today any repo that wants Pi must copy the whole workflow — action reference, model/provider wiring, the who-may-invoke guard, the token config — and the copies drift apart. Forgejo 15 supports the standard `workflow_call` reusable-workflow pattern, so we can have **one source of truth** and let other repos delegate with a 4-line wrapper. ## Changes - **`.forgejo/workflows/pi.yml`** — added the `workflow_call` trigger (kept `issue_comment` too, so `.profile` is its own consumer and needs no wrapper). No change to behaviour for this repo. - **`docs/examples/pi.yml`** — ready-to-copy drop-in wrapper for any other repo: `uses: alex/.profile/.forgejo/workflows/pi.yml@main` + `secrets: inherit`. - **`docs/reusable-pi-workflow.md`** — full guide: the wrapper, how event/`github.repository`/`secrets`/`vars` propagate through a called workflow, why each repo still needs a tiny file (per-repo `issue_comment` dispatch), and how this dovetails with the `pi` bot identity (`PI_TOKEN` becomes a one-line edit that applies forge-wide). ## How other repos consume it ```yaml # .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 ``` When `/pi …` is commented in that repo, the wrapper fires, the comment event is propagated into the called workflow (so the `if` guard and `github.event.comment` still work), `actions/checkout` checks out _that_ repo (`github.repository` = the caller), and owner-level secrets/vars (`LLM_API_KEY`, `MODEL`, …) are inherited. ## Notes / trade-offs - You can't have **zero** per-repo config: Forgejo dispatches `issue_comment` per repo, so one workflow can't auto-run across all of them. The reusable pattern centralises the _logic_; each repo only carries the delegating wrapper — strictly better than copying the full file. - Token identity unchanged in this PR (`env.FORGEJO_TOKEN`) to avoid breaking the working setup. Once `PI_TOKEN` exists (per `docs/setup-pi-bot.md`), flipping `github_token` in this **one** file makes every consuming repo post as `@pi` — which is the main payoff of combining this with #1. - The in-flight admin-restriction change (#2) is independent and will merge cleanly against this `if` guard.

forgejo-actions added 1 commit

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

ci: make the Pi workflow reusable across the forge a0cd2ce44a

Add a workflow_call trigger to .forgejo/workflows/pi.yml so it becomes a
reusable workflow: alex/.profile keeps triggering directly on issue
comments (no wrapper needed), and every other repo in the forge can invoke
the same definition via:
  uses: alex/.profile/.forgejo/workflows/pi.yml@main
  secrets: inherit

- docs/examples/pi.yml: ready-to-copy drop-in wrapper for consuming repos
- docs/reusable-pi-workflow.md: full guide on the pattern, event/secrets/vars
  propagation, and how it dovetails with the pi bot identity (PI_TOKEN)

forgejo-actions referenced this pull request

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

Setup pi bot user #1

alex added 1 commit

2026-07-01 10:22:59 +00:00