forgejo-ci

Central, reusable Forgejo Actions for the agent dev-cycle. Target repos don't copy CI — they carry a ~6-line stub that calls these workflows by reference, so updating CI for dozens of repos is a single change here (on @main).

Public on purpose. Cross-repo uses: / workflow_call requires the called repo be public. This repo holds no secrets — those live in each consuming repo's (or the org's) Actions settings and are passed explicitly, least-privilege (each stub passes only the secrets that one workflow declares — never secrets: inherit, which on a public reusable-workflow source would hand every repo secret to code defined in another repo). See SECURITY.md.

Paired with the private forgejo-agent-skills plugin (the local agent half). check.sh here is the same multi-language gate the plugin bundles for its local inner loop — one logic, two homes (CI + local), kept in sync.

What's here

check.sh                         multi-language gate (Go/TS/Rust/Swift/Java; extensible)
.forgejo/workflows/              reusable (on: workflow_call):
  ci.yml          gate — checks out caller + this repo, runs check.sh in an OTEL span
  security.yml    pinned scanners (go/ts/rust/secrets; self-detect, no-op when absent)
  on-merge.yml    PR merged → move Linear ticket to Finalization (linear-transition.py)
  auto-fix.yml    CI failed → pluggable agent fixes + re-pushes (autofix.sh), verify-then-push
.forgejo/scripts/                autofix.sh, linear-transition.py, otel-span.sh
stubs/.forgejo/workflows/        drop-in stubs a target repo copies (the ONLY per-repo footprint)

Adopt in a target repo

Copy the four stubs from stubs/.forgejo/workflows/ into the repo's .forgejo/workflows/. Each is a thin uses: of a workflow here. Then:

• Secrets (repo or org Actions settings; the stubs pass only each workflow's declared secrets — not secrets: inherit): LINEAR_API_KEY, AUTOFIX_TOKEN (content:write), optionally ANTHROPIC_API_KEY/CURSOR_API_KEY and OTEL_EXPORTER_OTLP_ENDPOINT/_HEADERS.
• Variables: AUTOFIX_AGENT (claude|cursor|custom), optionally AUTOFIX_CMD, AUTOFIX_MAX_ATTEMPTS.
• Branch protection on develop: make gate + the Security jobs required checks — but only the ones your runner can satisfy. The gate and the per-stack jobs hard-fail (by design) when a detected stack's toolchain is absent, so e.g. a Rust/Swift/Android repo needs a tailored runner; until then leave rust-security (and the corresponding stack) non-required rather than permanently red.
• Create the human-merge label for the risk gate.

Pin to a release tag instead of @main if you want change control per repo; @main gives automatic rollout.

Multi-language gate + runner requirements

check.sh detects a stack by its manifest and runs that stack's fast checks. It is fail-loud: no recognized stack → the gate fails (a green-but-empty gate is a lie; ALLOW_NO_CHECKS=1 opts out); a detected stack whose core toolchain is missing → fails (needs a tailored runner — iOS wants macOS+Xcode, Android wants the SDK), while optional linters skip-with-note. The reusable ci.yml sets up Go + Node today; teach it Rust/Swift/Android toolchains (or labeled runners) as those stacks come online.

Status

Dormant until Forgejo Actions is enabled instance-wide + a runner is registered (Linear OPS-246). Reusable-workflow / cross-repo uses: and workflow_run support are to be verified against the live instance when Actions is live.