Repository navigation
feat(tools/forgejo): forge + tracker bridge for Codeberg / Gitea / Forgejo #310
Description
Add tools/forgejo/ (or tools/gitea/ — same API family) as a forge bridge for self-hosted Git forges using the Forgejo / Gitea API. The API is mostly GitHub-compatible, so much of tools/github/ can be ported with minimal changes.
Suggested capabilities (mirror the GitHub bridge):
- Issue + PR read/write (same shape as GitHub)
- Repo metadata, labels, milestones
- CI integration — Forgejo Actions is GitHub-Actions-compatible
Why: As projects look at GitHub-alternatives, Forgejo/Gitea is the leading self-hostable option. Codeberg (codeberg.org) runs Forgejo and hosts a substantial OSS set including KeePassXC client tooling, the F-Droid mirror, and a growing migration set. Gitea itself uses Gitea. Some Linux subsystems and Apache podling discussions raise Forgejo as the "exit ramp" if GitHub policies become a problem — having the bridge means a project can move without losing the framework.
Reference:
- Forgejo API: https://forgejo.org/docs/latest/admin/api-usage/
- Gitea API: https://docs.gitea.com/api/
- Existing GitHub bridge to port from:
tools/github/— the API similarity means much of the read/write surface ports near-verbatim with endpoint substitution
Activity
docs(vendor-neutrality): cite the open forge/runtime extension-point …
Kaap10 commentedon Sep 28, 2026
Hi @potiuk, I would love to pick this up and work on adding the Forgejo/Gitea bridge!
Just a quick note: the Forgejo API reference link in the description (
.../admin/api-usage/) is currently returning a 404. It seems their docs were restructured, and the correct link is now:https://forgejo.org/docs/latest/user/api/usage/I was analyzing the implementation approach for porting
tools/github/and have a quick architectural question:Would you prefer the
tools/forgejo/operations to be built around the officialteaCLI (mirroring how the GitHub adapter uses theghCLI), or strictly rawcurlrequests targeting the Forgejo REST API?Context: Using
teaabstracts away the need to manually fetch and map integer IDs for labels/milestones (which the Forgejo REST API requires), keeping the agent recipes much simpler and less error-prone. However, I want to ensure depending onteaaligns with Magpie's baseline environmental tooling expectations.potiuk commentedon Sep 28, 2026
Sure - go ahead. : )
feat(tools/forgejo): add Forgejo/Gitea adapter bridge (apache#310)
feat(tools/forgejo): add Forgejo/Gitea adapter bridge (apache#310)
feat(tools/forgejo): add Forgejo/Gitea adapter bridge (apache#310)
feat(tools/forgejo): add Forgejo/Gitea adapter bridge (apache#310)
feat(tools/forgejo): add Forgejo/Gitea adapter bridge (apache#310)
feat(tools/forgejo): add Forgejo/Gitea adapter bridge (apache#310)
feat(tools/forgejo): add Forgejo/Gitea adapter bridge (part of apache…
feat(tools/forgejo): add Forgejo/Gitea adapter bridge (part of apache…
feat(tools/forgejo): add Forgejo/Gitea adapter bridge (part of #310) (#…
feat(bitbucket): add guarded cloud PR merge (#1471)
feat(tools): add asf-nexus and wire Nexus staging check into verify-rc (