[Feature]: Add Forgejo as Source Control Provider

[pat-s]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Not sure

Problem or use case

Besides GH, GL and BB, it would be great to also have support for Forgejo. There is fj as the CLI which can be used for the underlying API calls.

Proposed solution

Add support for Forgejo Git platforms.
Ideally multiple instances would be supported from the beginning as many people operate on more than just one instance. Also there is no single default instance anyhow so T3CODE_FORGEJO_URL or similar would anyhow be required.

Why this matters

Forgejo is a modern alternative to existing Forges like GH and GL.

Smallest useful scope

Allowing to link at least one Forgejo instance.

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.

[hazrpg]

This would also help Gitea users too - since the API is backward compatible with it. And I'd love to see both forgejo and gitea compatibility.

[pkeech]

+1 for getting this added!

[RobbyV2]

+1! A lot of organizations use either forgejo and gitea (and forks), it would be super helpful :)

[gustavohariel]

+1 on this!

[hack13]

+1 on this as well, as a selfhoster I would love native integration

[petmar20]

+1 Hoping for gitea support. Seems like this issue has been open a long time.

[insalata-fresca]

I wanted this for my self-hosted Forgejo, so I built it — a complete implementation is ready on a branch in case it's useful here:

https://github.com/insalata-fresca/t3code/tree/forgejo-provider (single commit on current main; 22 files, +2,033/−10 — roughly 40% of that is tests)

Design notes, following the existing Bitbucket (API-token) provider idiom as closely as possible:

• Full SourceControlProvider: list/get/create pull requests, PR checkout (incl. fork remotes), create repository, clone URLs, default branch — against the Forgejo v1 API
• Config via env, mirroring the Bitbucket pattern: T3CODE_FORGEJO_API_BASE_URL + T3CODE_FORGEJO_API_TOKEN (Gitea-style Authorization: token scheme). The base-URL env addresses the self-hosted/no-default-instance point from the issue description
• Host detection for forgejo / gitea / codeberg substrings — so Gitea instances and Codeberg work too, per the comments above
• No CLI dependency (considered fj, but the API route matched the existing Bitbucket provider shape better)
• 18 new tests; full sourceControl, pullRequest, shared and client-runtime suites green; monorepo typecheck clean; zero new dependencies
• Running in production against a live Forgejo instance (v15) — clone, PR create and PR checkout exercised for real

Known gap: the new multi-provider PR page would additionally need a ForgejoPullRequestProvider to light up for Forgejo remotes — happy to add that as a follow-up.

I read CONTRIBUTING and know large feature PRs aren't wanted right now, so I'm deliberately not opening one unprompted. If this is something you'd take, say the word and I'll open the PR (and split or trim it however you prefer) — otherwise feel free to lift anything useful from the branch.

Built with AI assistance (Claude), reviewed and deployed by me.

[quasarea]

I researched the current implementations and would like to propose a coordination path before adding another one.

There is now a released shared forgejo-bridge v0.2.0 (release commit 9000369ee452336d99309889415190f665918246) used by Codex through a packaged MCP integration. Its contract intentionally centralizes multi-instance selection, credentials, repository policy, pagination, Forgejo 15/16 compatibility, normalized errors, and capability discovery. T3 would invoke the same bridge through its JSON CLI boundary; it would not read tokens or implement Forgejo REST behavior itself.

PR #3028 already contains valuable first-class T3 work: the provider kind, registry refinement, remote UX, checkout mechanics, web/mobile presentation, and tests. Rather than create a competing implementation, I propose retaining those pieces and replacing ForgejoApi / ForgejoKeyStore with a thin bridge adapter.

A deliberately small first PR could support:

• bridge discovery/version negotiation;
• arbitrary self-hosted remote resolution through the bridge;
• repository lookup and clone URLs;
• default branch;
• read-only pull-request list/get;
• local Git checkout once the bridge exposes a normalized checkout descriptor.

Repository/PR creation and richer review/Actions mutations would remain capability-gated follow-ups. Generic Git URL cloning would continue to work without the bridge.

Important distribution caveat: the bridge is released and deployed in our environment, but is not yet a public dependency suitable for general T3 users. Before preparing code, would maintainers accept an optional external bridge boundary in principle, assuming a public/installable distribution is provided? If so, I am happy to coordinate with @pat-s and adapt the existing PR rather than duplicate it.

[quasarea]

Follow-up: the distribution prerequisite is now resolved.

The bridge has been published as a clean, single-root-commit public repository:

• Source: https://github.com/quasarea/forgejo-bridge
• Release: https://github.com/quasarea/forgejo-bridge/releases/tag/v0.2.0
• Public root commit: db1d692d7789b6336bc645eecd5eff47dd7606e5
• CI: tests, go vet, formatting, and build pass
• Release assets: Linux/macOS amd64+arm64, Windows amd64, and SHA-256 checksums

The public history excludes private deployment wrappers, instance configuration, credentials, and consumer-specific customization. The proposed T3 boundary remains a thin optional CLI adapter over the versioned JSON contract.

[pat-s]

Host detection for forgejo / gitea / codeberg substrings — so Gitea instances and Codeberg work too, per the comments above

Codeberg is not a forge but an instance (!!) that runs Forgejo - I wonder how often I will have to type this in the next years... :/ Basically stopped reading there.

Important distribution caveat: the bridge is released and deployed in our environment, but is not yet a public dependency suitable for general T3 users. Before preparing code, would maintainers accept an optional external bridge boundary in principle, assuming a public/installable distribution is provided? If so, I am happy to coordinate with @pat-s and adapt the existing PR rather than duplicate it.

You could at least have waited for more than 20min for a reply before building a completely unneeded "bridge" using an anonymous throw-away account.
All of this is what people legitimately refer to as "AI slop" - and while I hate the term itself, it really needs to be understood that this needs to stop. With this I mean these anonymous, "on the side" coding and posting automation without thinking about what is needed, where this fits in and how it will be perceived. Use AI as a tool to create quality work and not just something that can be compiled and "fixes" something in a hacky way that isn't sustainable.

Such contributions are close to spam and they don't help anyone - instead they create noise that prevents other from moving forward (I've now lost 10 min of my life in this rant).

/rant off