You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "potiuk (via GitHub)" <gi...@apache.org> on 2026/05/26 15:28:51 UTC
[I] feat(tools/forgejo): forge + tracker bridge for Codeberg / Gitea / Forgejo [airflow-steward]
potiuk opened a new issue, #310:
URL: https://github.com/apache/airflow-steward/issues/310
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/`](../tree/main/tools/github/) — the API similarity means much of the read/write surface ports near-verbatim with endpoint substitution
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] feat(tools/forgejo): forge + tracker bridge for Codeberg / Gitea / Forgejo [magpie]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on issue #310:
URL: https://github.com/apache/magpie/issues/310#issuecomment-5873619753
Sure - go ahead. : )
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] feat(tools/forgejo): forge + tracker bridge for Codeberg / Gitea / Forgejo [magpie]
Posted by "Kaap10 (via GitHub)" <gi...@apache.org>.
Kaap10 commented on issue #310:
URL: https://github.com/apache/magpie/issues/310#issuecomment-5870863087
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 official **`tea` CLI** (mirroring how the GitHub adapter uses the `gh` CLI), or strictly raw **`curl`** requests targeting the Forgejo REST API?
*Context:* Using `tea` abstracts 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 on `tea` aligns with Magpie's baseline environmental tooling expectations.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org