steveandClaude Fable 5
4dafac0d13
Nearly every consumer re-pin of review-reusable.yml was a reviewer IMAGE bump, not a structural change — but the tag was baked into a `uses: docker://` step, which is parsed before any expression context exists and so can't read a variable. Run the reviewer as the JOB container instead (container.image DOES accept expressions) with an explicit `run: /entrypoint.sh` step: the tag now resolves per-run via inputs.reviewer_tag → user var GADFLY_REVIEWER_TAG → the baked fallback pin (sha-b37cd09, unchanged). A Gadfly release becomes: build the image, update the ONE user-level variable — every consumer pinned to this file's @<sha> picks it up on its next review with no re-pin. Workflow re-pins remain only for structural yml changes (this is one — intended to be the last routine one). - Entrypoint contract unchanged: same env block, same /entrypoint.sh brains (bash + entrypoint already live in the image; ENTRYPOINT was /entrypoint.sh). - Keep the variable on immutable sha- tags, never :latest (act_runner caches :latest and often does not re-pull a moved one). - Tradeoff noted in comments: vars are unmasked and move without a commit trail — same blast radius as editing this file, minus the audit trail. - README (image/pinning para + Central config table) and examples/reusable.yml updated per the maintenance rule. Co-Authored-By: Claude Fable 5 <[email protected]>
Example consumer workflows
Each file here is a complete, copy-paste stub workflow. Pick the one that matches your
setup, copy it to .gitea/workflows/adversarial-review.yml in the repo you want reviewed, and
set the secrets/vars it references. Gadfly is advisory only — it never blocks a merge.
| File | Backend | Needs |
|---|---|---|
reusable.yml |
slimmest stub — calls Gadfly's reusable workflow and inherits its default swarm (3 cloud + Claude Code, 5-lens suite), forwarding only the secrets it needs (least privilege, not secrets: inherit); the stub keeps a cloud-only models: override so it runs with just the Ollama key (drop it + add the Claude token to get the full default) |
secret OLLAMA_CLOUD_API_KEY |
adversarial-review.yml |
Ollama Cloud (default) + inline notes for every provider; full self-contained stub | secret OLLAMA_CLOUD_API_KEY |
local-ollama.yml |
a local/LAN Ollama daemon | nothing (or GADFLY_BASE_URL for a remote host) |
openai-compatible.yml |
any OpenAI-compatible endpoint (local Ollama /v1, gateway, vLLM, OpenRouter…) |
GADFLY_BASE_URL (+ a key for most gateways) |
endpoint-aliases.yml |
several named backends at once (one comment each) | repo vars GADFLY_ENDPOINT_<NAME> |
claude-code.yml |
the bundled Claude Code CLI engine (claude-code/<model>) |
secret CLAUDE_CODE_OAUTH_TOKEN (or ANTHROPIC_API_KEY) |
opencode.yml |
the bundled OpenCode CLI engine (opencode/<model>) driving an ollama-cloud model — benchmark it against the majordomo loop on the same model |
secret OLLAMA_CLOUD_API_KEY |
.gadfly.yml |
per-repo specialist config (not a workflow — goes at your repo root) | — |
Common to all:
- Triggers: new/reopened/ready non-draft PR (auto),
@gadfly reviewcomment (allowed users), or manualworkflow_dispatchwith apr_number. GITEA_TOKENis provided automatically; comments post asgitea-actions.- Tested backends are the Ollama ones; OpenAI/Anthropic/Google are wired via majordomo but untested. See the repo README for the full config reference and the honest tested/untested status.
Gitea note: repo
vars/secretsare not auto-exposed as env — anything you reference via${{ vars.X }}/${{ secrets.X }}must appear in the step'senv:block (already wired in these examples).