fix(forge): honor project forge_override for self-hosted forges

[ameyypawar]

Fixes #14319. Opening as a draft for review — the direction was confirmed by the maintainer investigation in the issue and by the reporter, so I'd welcome a self-hosted test and any steer on the shape before marking it ready.

Bug

0.20.1 regressed self-hosted GitLab: a project with forge_override = gitlab shows "No forge could be determined" and the GitLab settings section disappears.

Cause

547b873 moved forge resolution into Rust, but but_forge::derive_forge_repo_info(url) never consumed the project's forge_override. For a self-hosted host that isn't a recognized keyword (gitlab.com/gitlab.*) and before an account is configured, it returns None — so forge_info() returns None and ForgeForm.svelte hides the GitLab config (gated on forgeInfo?.name === "gitlab").

Fix

Resolve the forge type in one place, resolve_forge_name, in priority order:

1. the URL host (github.com, gitlab.*, …),
2. a configured account whose custom host matches,
3. the project's saved forge_override — last resort, mirroring pre-0.20.1's if forgeType === "default" && forgeOverride.

A recognized host or a matching account always wins, so a stale override can't mislabel a repo whose forge is already known. Owner/repo still come from the URL's GenericProvider regardless of how the type is resolved, so the override path produces the same ForgeRepoInfo the account path would.

The override (legacy_project.forge_override) is threaded through forge_info, compare_branch_url, and the forge API paths in but-api and the CLI auth path. The pure-URL identity comparison (remote_urls_match) passes None.

Tests

• resolve_forge_name precedence — the override resolves a self-hosted host; a recognized host and a matching account each win over the override; none → None
• end-to-end derive_forge_repo_info on a self-hosted URL (owner/repo parsed correctly)
• build_base_url builds the self-hosted web URL from the override-derived info
• from_override_str is case/whitespace-insensitive

cargo check --workspace and clippy are clean.

Notes / open questions

• Host detection is substring-based, so a self-hosted host embedding another forge's domain (e.g. git.azure.company.com) is still detected as that forge and the override won't correct it — a pre-existing limitation, left out of scope here.
• Account-vs-override ordering: a configured account (which carries credentials) is treated as authoritative over the saved preference. This doesn't affect the reported case (no account configured).
• I threaded an Option<ForgeName> parameter through derive_forge_repo_info and its callers; happy to switch to a centralized ctx-level helper if that's preferred.

The reporter offered to test a build on their self-hosted instance — that would be the strongest confirmation.

---

Note

High Risk
Changes forge detection, credential selection, and cache invalidation across desktop and core forge/review paths; mis-resolution or auth matching could break integrations or cause wrong-host API use.

Overview
Restores self-hosted forge detection when a project has a saved forge_override but the remote host is not recognizable on its own (#14319). Rust forge resolution now takes an optional override as a last resort after URL host detection and matching integration accounts, and that override is passed through forge info, compare URLs, reviews/CI, and related API paths.

The forge layer also tightens repository and credential matching: richer ForgeRepoInfo (host/port), explicit same-server/same-repository checks, and resolve_account so live API calls only use accounts that match the repo’s forge and host (with safer remote reuse across protocols).

On desktop, project settings send partial ProjectUpdate payloads instead of full project objects, and RTK Query invalidates forge caches only when the override actually changes—so editing name/description no longer refetches PRs/checks. Forge settings UI stays available when an override is saved even if auto-detection would hide the picker.

^{Reviewed by Cursor Bugbot for commit 0073388. Bugbot is set up for automated code reviews on this repo. Configure here.}

[PetrAltman]

I'm the reporter of #14319. Built this branch on Windows (x86_64-pc-windows-msvc) against my self-hosted GitLab and can confirm the main fix works: the "Configure GitLab integration" section is back in Project Settings and the "No forge could be determined" error is gone. Thanks for this!

One remaining issue that looks related to URL construction, in case it's in scope here:

The "View MR" button on the virtual branch (in the side column) opens GitLab at a truncated host — just gitlab instead of the full gitlab.internal.example.com. The short host actually resolves on my internal network (DNS search domain), but the page then fails with an SSL certificate error, because the cert is issued for the full FQDN gitlab.internal.example.com, not the short name. So the truncation is the root cause; the cert error is just the symptom.

The "Open MR in browser" button in the merge column opens the correct full URL (gitlab.internal.example.com/...) with no cert error.

So the two buttons seem to build the MR URL via different paths: the merge-column one resolves the self-hosted host correctly, but the virtual-branch "View MR" one keeps only the first host label and drops the rest of the domain. Happy to grab logs or test a follow-up change if useful.

(Host redacted — my real instance is an internal *.int.* domain.)

[PetrAltman]

Update / root-cause find, reporter of #14319 here.

I tracked down what actually triggered this on my setup: my git origin remote was pointing at a short host (gitlab) instead of the full FQDN (gitlab.internal.example.com). After fixing origin to use the FQDN, the GitLab integration works correctly even on 0.21 (which doesn't include this PR).

That seems to explain the original error: in 0.20.1 forge resolution became host-based, and my short origin host matched neither the built-in gitlab.* patterns nor my configured account host (gitlab.internal.example.com), so it resolved to no forge — while the saved forge override wasn't consulted as a fallback. Which is exactly what this PR adds.

So the PR still looks valuable as a robustness fallback (honor the override when the origin host can't be matched — mirrors, SSH host aliases, etc.), even though my specific breakage came down to a misconfigured origin.

One related note on the two MR buttons: "View MR" (virtual branch, side column) appears to build its URL from the raw origin host, while "Open MR in browser" (merge column) uses the resolved forge instance URL. That's why they differed for me — with origin fixed to the FQDN, both work now. Might still be worth having "View MR" use the resolved forge URL for consistency, but it's no longer broken on my end.

[ameyypawar]

Thanks for building it and confirming — glad the GitLab section and forge detection are back on your self-hosted instance.

And thanks for chasing the root cause. It lines up with the fix: when the origin host doesn't match a built-in pattern or a configured account host — as a short or aliased host won't — 0.20.1 resolved to no forge and never consulted the saved override. This PR restores that fallback, so a saved forge preference still resolves in those cases (mirrors, SSH host aliases, short internal hostnames).

The "View MR" host truncation looks like a separate area from this PR (which changes forge resolution, not MR-URL construction) — probably best as its own issue. I'd want to trace both buttons' URL paths before proposing a fix, so it targets the right spot.

[Byron]

Thanks @ameyypawar for the fix, and @PetrAltman for taking a look.

Something I'd feel uncomfortable with is that support for the forge override now is explicitly needed in but-api, so it can easily be forgotten as well. It feels like it belongs closer to but-forge. With that said, @estib-vega would know best if this is the right direction.

[alec-chernicki]

Bump on this PR if possible. I believe I'm running into this when attempting to run against a hosted GitHub Enterprise account.

[Byron]

@alec-chernicki Could you try this PR locally and see if it solves your problem? And even if not, maybe it's not far from actually working. With that incentive, it should be easier to find a reviewer.
Thanks for your consideration - your help here would be vital as real-world testing isn't an option for the team right now.

[alec-chernicki]

@Byron, I ran this branch against the same GitHub Enterprise account, and I now see all the PR features in the app. This fix looks like it works.

[Byron]

Review

I started with a project whose remote URL was set to https://forge-test.invalid/group/repo.git to make the automatic forge detection fail.

From there I could set the override in the Tauri app (but not in Lite):

Without that, reviews could already not be retrieved, with it, that error would disappear (but I didn't check if the disappearance isn't some sort of caching effect).

The key change in is but_forge::forge_info() which now takes the override as well. From there, whenever the remote url is used, the forge override is present as well.

The security fix

It appears that there was a latent issue with the user account matching, that was now exposed with forge overrides. It could lead to enterprise account tokens being sent to public hosts, as the URL for the remote was rebuilt based on the overridden forge, while the account may have been matched based on the actual host.

Notes for the (additional) Reviewer

• I moved all tests for public APIs into integration tests as a flyby refactor. This makes the production source files less imposing.
• The PR got bigger due to the added tests and docs here and there, as well as due to follow-up fixes to the Svelte UI regarding its handling of the forge override. The Lite GUI doesn't have that yet.
• Keep manually selected forges editable in project settings is a logic-bugfix detected by the review which I ran into myself, and confirmed fixed in the Svelte GUI afterwards.

Addressed Codex Review Comments

• [P1] Require a host-matching account for override-backed API calls — /Users/byron/dev/github.com/gitbutlerapp/gitbutler.fix-14319-forge-override/crates/but-api/src/legacy/forge.rs:312-315
  For an unrecognized self-hosted GitLab remote with an override and no preferred account, this now permits API calls even when only a GitLab.com or other-instance account is saved. ForgeRepoInfo carries no host, and GitLabClient::from_storage defaults to the first saved account. Consequently, list_reviews queries the wrong server and publish_review_only sends private titles, descriptions, and branch names there, potentially creating an MR in a same-named repository. Require a host-matching account for API actions while retaining override-only display and template support.
• [P2] Invalidate forge queries when the saved override changes — but-api/src/legacy/forge.rs:135-135
  When choosing a forge for an initially unrecognized repository, forge_info is already cached as null. updateProject invalidates only ReduxTag.Project, whereas ForgeInfoService.get provides ForgeProvider; the project layout keeps that query subscribed and gates integration on it. Saving the override therefore never refetches this newly project-dependent result, leaving integration disabled until a reload or target change. Invalidate affected forge queries when setting or clearing the override, covering the desktop contract required by AGENTS.md:29–31.
• [P2] Keep manually selected forges editable in project settings — but-forge/src/forge_info.rs:74-74
  After reopening an override-only repository, this returns the manually chosen provider as ForgeInfo.name. ForgeForm.svelte treats that value as automatic detection and renders the selector only for "default", so any recognized override hides the only UI for changing or clearing it. A mistaken GitHub choice for a GitLab host therefore cannot be corrected from settings. Keep the selector available for saved overrides or distinguish detection from override resolution, per AGENTS.md:29–31.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 7d15d92. Configure here.}