[Feature] Support BitBucket data center

[Kennybll]

Currently t3code only supports BitBucket Cloud. I am trying to use t3code at work, but we use BitBucket data center so the BitBucket integration does not work since it uses different endpoints.

[iOSDeveloperGuy]

+1 for this. We use a self-hosted Bitbucket Data Center instance on a custom internal domain, so this is currently the main thing keeping us from being able to use the Bitbucket integration fully.

For us, the most useful initial scope would be authenticating against a custom Data Center instance and supporting the normal PR workflow: create/view PRs, diffs, comments, reviewers, and merge/decline.

I'd also be happy to help test this against a real Data Center instance, or help with the implementation if that's useful.

[BerkayClik]

+1, we run Bitbucket Data Center too. (I opened #14592 for this by mistake; it was closed as a duplicate of this thread, so moving the details here.)

What differs from Cloud, for whoever picks this up:

• API: REST 1.0, /rest/api/1.0/projects/{KEY}/repos/{slug}/pull-requests/..., rather than Cloud's /2.0/repositories/{workspace}/{repo}/pullrequests/....
• Remote URL shapes: https://host/scm/{project}/{repo}.git and ssh://git@host:7999/{project}/{repo}.git.
• Pull request URLs: https://host/projects/{KEY}/repos/{slug}/pull-requests/{n}.
• Auth: instance-scoped HTTP access tokens (bearer), separate from any Bitbucket Cloud credential.
• Base URL: one per host, derived from the remote rather than one process-wide API root, so a Cloud token is never sent to a self-hosted instance (and vice versa).

A read-only first step (list / view pull requests, branch PR status) seems like a reasonable starting scope, with actions (comment, approve, merge) after that.

Related: today a Data Center remote is classified as Bitbucket and its PR traffic goes to api.bitbucket.org (#14591). #14593 stops that by marking such hosts unsupported until this lands.

[OhadC]

I've implemented this on a fork and would like maintainer sign-off on direction and scope before opening a PR: https://github.com/OhadC/t3code/tree/feat/bitbucket-data-center

Scope (tested against a real Data Center instance):

• Detection: remotes on a host with a bitbucket DNS label other than bitbucket.org are a separate bitbucket-server kind. This covers https://host/scm/KEY/repo.git, ssh://git@host:7999/KEY/repo.git, ~user personal repos, context paths, and Data Center PR URLs. They never reach the Cloud client, so this also fixes Self-hosted Bitbucket (Server/Data Center) remotes are treated as Bitbucket Cloud → useless api.bitbucket.org traffic; request Bitbucket Server support #14591.
• Auth: one instance, set by host URL plus an HTTP access token (bearer). Saved in Settings → Source Control, with the token in the secret store, the same way as Cloud credentials since feat: save Bitbucket credentials from Source Control settings #14103. T3CODE_BITBUCKET_SERVER_URL and T3CODE_BITBUCKET_SERVER_TOKEN are the fallback. It's separate from the Cloud credentials. Requests only go to the configured host, and a remote on a different host fails with a clear error, so neither token goes to the other service.
• Repositories: look up a repository, get clone URLs, and check branch PR status. Publish isn't offered.
• Pull requests: list, view, diff, timeline, checks, and the PR watch head SHA. Also create, comment, inline comments and replies, review (approve / request changes), reviewers, edit, and merge / decline / reopen. Reactions, thread resolution, and draft toggling aren't offered, through the existing capability flags.

Size: about 6.9k added lines, roughly half of them tests. Most of it is new adapter files beside the Cloud ones. Shared changes are small: the contract enum value, URL parsing, provider registration, and the settings form.

Splitting: happy to send it as a stack if that's easier to review:

1. detection (fixes Self-hosted Bitbucket (Server/Data Center) remotes are treated as Bitbucket Cloud → useless api.bitbucket.org traffic; request Bitbucket Server support #14591)
2. repository operations
3. reading pull requests
4. pull request actions
5. saved credentials

Or I can start with the read-only part, as suggested above.

Relation to #14593: it marks these hosts unsupported until Data Center support exists. This work replaces that by routing them to the Data Center adapter. If #14593 lands first I'll rebase on it.

Known limitation: one Data Center instance per server, and the host needs a bitbucket DNS label, the same rule detection uses today.

Does this direction and scope work for you, and do you prefer one PR or the stack?

[OhadC]

Status update: the Data Center support is now up as three draft PRs on current main. The fork branch linked above is gone; these replace it.

1. feat(source-control): groundwork for self-hosted Bitbucket #18240 groundwork outside the new package: a git fetchRemoteRef, a nullable publishDescription, two Cloud Bitbucket helpers exported for reuse, and NODE_USE_SYSTEM_CA=1 for the desktop's bundled server
2. feat(source-control): Bitbucket Data Center repositories #18241 repositories: the @t3tools/source-control-bitbucket-server package, detection (fixes Self-hosted Bitbucket (Server/Data Center) remotes are treated as Bitbucket Cloud → useless api.bitbucket.org traffic; request Bitbucket Server support #14591), host URL plus token in Settings, lookup and clone
3. feat(pull-requests): Bitbucket Data Center pull requests #18242 pull requests: list, detail, diff, checks, comments and reviews, reviewers, edit, merge, decline, and reopen

The scope is the one described above, rebuilt on the per-host package architecture. Saved credentials are part of #18241 rather than a separate layer. All three were exercised against a real Data Center instance, with screenshots in the PRs.

GitHub can't base an upstream PR on a fork branch, so all three target main, and #18241 and #18242 also show the commits below them. If you'd rather review them as a native stack, I'm happy for a maintainer to push the branches upstream and retarget the bases.

@juliusmarminge, does this direction and scope work for you? The PRs stay in draft until there's a sign-off here.

[kevin-regnology]

+1 from our side too. We run Bitbucket Data Center 9.4.9 and are currently running into the issue that the "watch PR" feature is used but doesn't really work with it. Would be really cool to have this working.

Also happy to help if help is needed.

[iOSDeveloperGuy]

@juliusmarminge Could your dot triage this proposal for scope approval? I’d like to help with Bitbucket Data Center support, starting with instance authentication and read-only PR browsing. We use it at work, so I can help test against a real instance.

Would that scope be acceptable, perhaps building on @OhadC’s existing work?

[OhadC]

For now, my solution is adapter proxy that adapt between bb dc and cloud.
T3 is requesting with cloud interfaces, adapter is adapting to dc interfaces and make the request, and adapt the respond back to cloud interfaces for T3.
It has some downsides, but it works :)
I'll publish it later (have it on my work laptop)