Does the Gitea source control integration work with Forgejo?

[MrGeorgen]

Preflight

• I searched existing issues and docs before opening this.
• This proposal is grounded in a real Roomote use case, not a broad generated feature list.

Problem

The docs list Gitea as a supported source control provider, but I couldn't find anything about Forgejo. Since Forgejo is a hard fork and the API has diverged in places, I'd rather ask than assume.

Has anyone got this working against Forgejo, or is the connector tested against Gitea only?

Current workaround

None — currently not using Roomote for this reason.

Proposed behavior

support forgejo

Affected surfaces

Other

Self-hosting implications

setup forgejo token and permission

Alternatives considered

No response

Documentation impact

No response

[roomote-community]

I've analyzed this issue and here's my proposed implementation plan:

1. Treat Forgejo as a tested compatibility target of the existing Gitea provider rather than adding a separate persisted provider ID. Roomote already routes self-hosted instances through GITEA_BASE_URL, /api/v1, and the shared Gitea repository/credential/webhook paths, so retaining sourceControlProvider: "gitea" avoids duplicating the provider stack.
2. Add Forgejo contract fixtures and tests around packages/gitea/src/api.ts, packages/gitea/src/oauth.ts, and packages/gitea/src/ci.ts for OAuth authorization/refresh, repository pagination, issue/PR comments, webhook list/create/update, and Actions APIs. Use a currently supported Forgejo release as the initial compatibility floor and add narrow response normalization or endpoint fallbacks only where those tests identify an actual divergence.
3. Add representative Forgejo webhook coverage in apps/api/src/handlers/gitea/__tests__/ for signature/event headers and PR, issue/comment, and workflow payloads. Preserve the existing Gitea behavior while accepting any Forgejo-specific header or payload differences found during verification.
4. Exercise the shared pull-request operations in packages/sdk/src/server/lib/pull-requests/ against Forgejo contracts: listing/reading PRs, creating or updating a PR, posting top-level and inline review comments, and reporting unsupported capabilities honestly.
5. Update setup copy in apps/web/src/app/(onboarding)/setup/ and the public guide at apps/docs/providers/source-control/gitea.mdx to label the connector as Gitea/Forgejo-compatible, document Forgejo OAuth application setup and permissions, state the tested Forgejo version range, and include a verification checklist covering connect, sync, clone, webhook delivery, PR/issue mentions, review automation, and optional Actions triage.

This approach gives Forgejo explicit, test-backed support without introducing a second provider whose storage, routing, and API implementation would largely duplicate Gitea. It also keeps any future fork-specific behavior isolated behind compatibility handling in the existing adapter.

Please tag @roomote if you'd like me to implement this, or reply with feedback on the plan.