feat: multi-forge support — adapter pattern + Gitea by afonsojramos · Pull Request #2842 · gitify-app/gitify

afonsojramos · 2026-05-06T13:15:14Z

Summary

Pivots Gitify from GitHub-only to multi-forge by introducing a ForgeAdapter contract (src/renderer/utils/forges/) that all forge-specific code routes through, then ports the existing GitHub modules into forges/github/ and lands a Gitea adapter as the first non-GitHub citizen. Account.forge is a required field with a one-shot legacy-state migration; capabilities (mark-as-done, unsubscribe, GraphQL enrichment) are surfaced per-adapter so unsupported actions hide gracefully instead of silently no-op'ing.

CONTRIBUTING.md replaces the "no other forges" stance with a multi-forge policy and MAINTAINERS.md lists per-forge owners (Gitea: @bircni and myself). Lint is clean and 944/944 tests pass; Gitea PAT login verified end-to-end against gitea.com.

Note: Gitea's notification model is absurdly simple

Closes #2786

afonsojramos · 2026-05-06T13:45:16Z

@setchy I think this is a good first implementation with two forges. Now, if we want to expand this, then the login flow needs a bit of a rework. I don't mind giving it a go, but I'd rather work on that after the core implementation is there.

…ration

…pter

… when unsupported

Adds the first non-GitHub forge adapter under the new ForgeAdapter contract: client (fetch-based, no Octokit), types, transform, and adapter registration. Wires Gitea PAT login into the Login and Accounts routes, exposes the Gitea platform icon, and gates unsupported actions (mark-as-done, unsubscribe, GraphQL enrichment) via capability flags. Adapted from work originally proposed in #2787. Co-authored-by: bircni <75789103+bircni@users.noreply.github.com>

…ort-circuit

…new location

setchy · 2026-05-06T14:02:49Z

@setchy I think this is a good first implementation with two forges. Now, if we want to expand this, then the login flow needs a bit of a rework. I don't mind giving it a go, but I'd rather work on that after the core implementation is there.

Awesome work @afonsojramos - love the adapter pattern (i was thinking similar, borrowing from Renovates platform implementation).

I'm going to pull this branch down and run it locally.

We can do this in follow up PRs, but what are you initial thoughts about the reorganizing required for Settings, Accounts and Filters? My hunch is Accounts and Filters should be mostly OK, but some of the Settings config options are GitHub specific.

Also, do you think we should flag the non-GitHub forges as experimental for a period of time, or, just go for it!

setchy

Shall we add a section into README.md that outlines our forge adapter support matrix? we could convey current support and future potential forges perhaps

afonsojramos · 2026-05-06T14:13:45Z

what are your initial thoughts about the reorganizing required for Settings, Accounts and Filters?

Agree with your hunch.

Accounts: already adapter-driven after this PR: the “add new account” overlay iterates listAdapters(), dev-settings opens via getAdapter(account).getDeveloperSettingsUrl(account), and the scopes pill short-circuits for non-GitHub. Remaining GitHub-flavored bits (the scopes warning UI in particular) are inert for Gitea, which is fine for now.
Filters: structurally nothing to do: they operate on normalized GitifyNotification. The data is just narrower from Gitea today (we map all reasons to subscribed, owner type to User, etc.).
Settings: this is where it actually leaks. participating, detailedNotifications, markAsDoneOnOpen and markAsDoneOnUnsubscribe only mean something on GitHub. Three options as I see it:

Keep them global, label as (GitHub) where relevant - smallest change.
Hide them when no GitHub account is configured.
Per-account overrides - I'd say it would be over-complicating the solution.
I'd lean towards 1 for now and revisit when a third forge lands.

do you think we should flag the non-GitHub forges as experimental?

I’d say just go for it, given the simplicity of Gitea’s notification system. It’s nearly a strict subset of GitHub’s, so not much room to surprise people. Future forges with weirder shapes (GitLab todos, Bitbucket reviews) can land behind an experimental: true flag on the adapter; capability-gating should already be the natural place to thread it through.

setchy · 2026-05-06T14:23:09Z

+| **GitHub** Enterprise Cloud with Data Residency | ✅ Supported   | ✅            | ✅        | ✅        | ✅          | ✅               |
+| **Gitea** (incl. Forgejo, Codeberg)             | ✅ Supported   | ✅            | ✅        | —         | —           | —                |
+| **GitLab** (todos)                              | 💭 Considering | —             | —         | —         | —           | —                |
+| **Bitbucket** Cloud / Data Center               | 💭 Considering | —             | —         | —         | —           | —                |


We can drop Bitbucket Data Center since that's EOL.

setchy · 2026-05-06T14:27:20Z

+ *
 * @param account - The account whose scopes to check.
 */
 export function hasRequiredScopes(account: Account): boolean {


Eventually we might want to push this into the forge adapter

Well, why not now? I have two implementation alternatives, but I'll follow my gut with what I feel is best 👀

sonarqubecloud · 2026-05-06T16:09:26Z

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
88.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

afonsojramos requested review from bmulholland and setchy as code owners May 6, 2026 13:15

github-actions Bot added the enhancement New feature or enhancement to existing functionality label May 6, 2026

afonsojramos linked an issue May 6, 2026 that may be closed by this pull request

docs: exploring multi git platform support #2841

Open

afonsojramos and others added 20 commits May 6, 2026 16:02

docs(contributing): replace github-only stance with multi-forge policy

20ce142

feat(types): add Forge type and required Account.forge field with mig…

8ab2764

…ration

feat(forges): add ForgeAdapter interface, registry, and GitHub adapter

a43767b

refactor(forges): route notifications, features, and auth through ada…

2078d85

…pter

test(notifications): expect mark-as-done to fall back to mark-as-read…

9e56554

… when unsupported

refactor(login): route PAT login through forge adapter

c1b68fa

refactor(login): render login methods from forge adapter registry

188c023

refactor(links): route developer settings URL through forge adapter

8834c83

fix(forges): preserve refresh response shape and limit gitea scope sh…

7591e7b

…ort-circuit

refactor(forges/github): relocate GitHub modules into forges/github

e4ef3ed

fix(forges/github): point graphql codegen output and import paths at …

ebad481

…new location

fix(auth): coerce missing enterprise version header to null

db282cc

test(settings): drop obsolete snapshot for go-back test

29a6c5e

test(forges): cover registry dispatch and unknown-forge errors

05ebcae

test(forges/gitea): cover client request paths and pagination

f52c75c

test(forges/gitea): cover adapter dispatch and capabilities

f7668b1

test(forges/github): cover adapter dispatch and login fields

eac24ad

test(forges/github): cover raw notification transform

f032863

style(forges): apply biome formatter to new test files

4d9e45f

afonsojramos force-pushed the multi-platform-support branch from 37bf36f to 4d9e45f Compare May 6, 2026 14:03

setchy reviewed May 6, 2026

View reviewed changes

Comment thread MAINTAINERS.md

setchy reviewed May 6, 2026

View reviewed changes

afonsojramos added 4 commits May 6, 2026 16:16

fix(test): widen latest_comment_url cast to allow null in transform test

ff936a5

chore(codeowners): route forge adapters to their maintainers

ba011e6

docs(readme): add forge adapter support matrix

dda29d1

docs(readme): document forge status symbols (experimental, in progress)

36fdcf7

afonsojramos commented May 6, 2026

View reviewed changes

Comment thread README.md

setchy reviewed May 6, 2026

View reviewed changes

afonsojramos added 2 commits May 6, 2026 17:43

docs(readme): drop Bitbucket Data Center from forge matrix (EOL)

9a654d7

refactor(forges): move OAuth scope checks onto the adapter

2e1d93f

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: multi-forge support — adapter pattern + Gitea#2842

feat: multi-forge support — adapter pattern + Gitea#2842
afonsojramos wants to merge 26 commits intomainfrom
multi-platform-support

afonsojramos commented May 6, 2026 •

edited

Loading

Uh oh!

afonsojramos commented May 6, 2026

Uh oh!

setchy commented May 6, 2026

Uh oh!

Uh oh!

setchy left a comment

Uh oh!

afonsojramos commented May 6, 2026 •

edited

Loading

Uh oh!

Uh oh!

setchy May 6, 2026

Uh oh!

setchy May 6, 2026

Uh oh!

afonsojramos May 6, 2026

Uh oh!

sonarqubecloud Bot commented May 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Conversation

afonsojramos commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

afonsojramos commented May 6, 2026

Uh oh!

setchy commented May 6, 2026

Uh oh!

Uh oh!

setchy left a comment

Choose a reason for hiding this comment

Uh oh!

afonsojramos commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

setchy May 6, 2026

Choose a reason for hiding this comment

Uh oh!

setchy May 6, 2026

Choose a reason for hiding this comment

Uh oh!

afonsojramos May 6, 2026

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud Bot commented May 6, 2026

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

afonsojramos commented May 6, 2026 •

edited

Loading

afonsojramos commented May 6, 2026 •

edited

Loading