Implement provider-neutral Repo Coder support for GitLab and Bitbucket

[serge-ivo]

Summary

Implement provider-neutral git provider support for Repo Coder so the same Coder runtime/workflow can support GitHub, GitLab, Bitbucket, and local-only repositories without forking separate Coder implementations.

Plan document: https://github.com/ProAgentStore/platform/blob/main/agents/coder/GIT_PROVIDERS_PLAN.md

Direction

• Keep one core Repo Coder implementation.
• Add provider-specific connector/auth/import/build/issue layers underneath the existing coding surface and CODING_SESSION workflow.
• Preserve existing GitHub behavior and data.
• Make local checkouts first-class for private repos that the user's machine can already access.

Suggested Phases

1. Provider-neutral repo identity fields and compatibility mapping from github_repo.
2. Provider-aware Add Repo UI and repo badges/copy.
3. GitLab connector for projects, issues, issue creation, and pipelines.
4. Bitbucket connector for repositories, issues, issue creation, and pipelines.
5. Optional provider-branded catalog presets over the same Coder implementation.

Acceptance Criteria

• Existing GitHub Coder flows continue to work.
• Local path repos continue to work.
• GitLab and Bitbucket clone URLs can be represented without pretending they are GitHub repos.
• Hosted issues/builds are dispatched by provider and gracefully unavailable when auth is missing.
• Write actions remain gated by connector consent.

[serge-ivo]

Recommendation: defer the provider abstraction. Keep this issue open as the plan it already is.

I audited the whole coding/repo path against the two options — extract a provider interface now with GitHub as the first implementation, or hold. The evidence points to holding, and it points there mainly because the GitHub-specific code is already isolated, which was the stated condition for not doing it.

I have no GitLab or Bitbucket credentials and cannot verify against a real instance, so nothing below is an end-to-end result. That limitation is itself most of the argument.

What is actually coupled

Layer	State	Evidence
App auth / JWT / token cache	Isolated	All of it in lib/github-app.ts, behind exactly two exports the rest of the codebase uses: githubAppConfigured(env) and installationTokenForOwner(env, userId, owner). Nothing outside that file touches a PEM, an RS256 JWT, or the github_installations table.
Runner clone	Already neutral	packages/browser-runner/src/coding/repo.ts:34 — ensureRepo(dir, {cloneUrl, branch, token}) then a plain git clone --depth 1. One GitHub-ism in the whole file: url.replace(/^https:\/\//, \https://x-access-token:${token}@\`)` at :55. That is a single string (GitLab wants oauth2:, Bitbucket x-token-auth:).
Issues / Actions clients	Isolated	lib/github-issues.ts and lib/github-actions.ts are single-purpose modules; the latter's header says it already de-duped four copy-pasted fetches.
Registry connector	Isolated, and already the target shape	lib/connectors/github.ts is a declarative GITHUB_MANIFEST compiled by compileConnector.
DB	Half neutral already	coding_repos has clone_url, branch, workdir — all provider-agnostic. github_repo is the only hosted-identity column.
routes/coding.ts	Tangled	2 verbatim copies of /github\.com[:/]([\w.-]+\/[\w.-]+?)(?:\.git)?\/?$/i (:184, :227); 4 copies of repo.githubRepo.split("/")[0] (:1017, :1368, plus :305/:325 inline, plus coding-session-open.ts:53); /deployment (:319) is a hand-inlined duplicate of the latestRunFor helper defined 20 lines above it; available:false overloaded to mean "not GitHub" (:397, :411).

So: one file is messy. Eight of nine layers are already behind clean boundaries, including the one the issue is really about. Adding GitLab does not require unpicking any of them — it requires a new module plus a dispatch.

The decisive point: the connector framework already supports the auth models GitLab and Bitbucket need

lib/connectors/types.ts:122 — auth: "oauth" | "token" | "app" | "none". GitLab is OAuth or a PAT; Bitbucket is OAuth or an app password. Both are already expressible. "app" being GitHub-specific is not a blocker, because a GitLab connector would never use it.

There is nothing here to unblock. A GitLab connector today is a new manifest file next to github.ts, using primitives that shipped with #86. An interface extracted now would not remove a single step from that work — it would add one.

Why an auth interface designed now would be wrong

This is the part I'd bet on being wrong, and it is the part that is hardest to change later.

installationTokenForOwner(env, userId, owner) is not a neutral signature that happens to be implemented over GitHub. It encodes GitHub's grant model: credentials are minted per installation, an installation is bound to an account (listInstallations() → account.login match at github-app.ts:194), tokens are short-lived and re-minted, and the whole thing hangs off an App the org admin installed. owner is the resource scope because on GitHub it genuinely is.

None of that transfers:

• GitLab — a PAT or OAuth token belongs to a user, not to an owner-scoped installation, and groups nest arbitrarily (group/subgroup/project), so "the owner" is not even a well-defined single segment. Self-managed instances add a base URL that GitHub's model has no slot for.
• Bitbucket — app passwords are user-scoped; OAuth is workspace-scoped. Different again.

An interface written against one implementation would take owner: string because that is what the only implementation needs, and both other providers would then have to lie to it. That is the "will not survive contact" failure, and it is worse than no interface, because the next person inherits indirection plus the wrong shape and has to argue their way out of a documented abstraction.

GIT_PROVIDERS_PLAN.md is honest about this — it ends with five open questions, and three are auth-model questions (GitLab OAuth-vs-token first? self-managed now or later? Bitbucket workspace OAuth vs app passwords?). Building the interface now means answering those three by guessing. They are cheap to answer with one real account and expensive to answer wrong.

This is the same call the platform made on DCR (#180), and for the same reason.

What would change my mind

Not "we might add GitLab". Specifically: someone has a GitLab account we can authenticate against. At that point Phase 1 of the plan (provider/repo_slug/web_url/default_branch columns, backfill provider='github', neutral parsing helpers) is a few hours of low-risk work with a real second implementation to check the shape against — which is exactly the position from which an interface is worth designing.

One thing worth doing regardless — but it is not this issue

The routes/coding.ts duplication above is a real bug surface today: two copies of one regex and four of one owner-parse can drift, and /deployment re-implements latestRunFor inline. Collapsing that into a small repo-identity helper is justified purely as de-duplication, needs no provider decision, and would shrink Phase 1 whenever it happens.

I have deliberately not done it here — it is a different concern from #221, it touches the busiest route file in the API, and folding it into a provider-neutrality issue would make a mechanical cleanup look like the start of an abstraction it is not. Worth its own issue.

Verdict

(b) — the abstraction would be speculative. Recommend leaving #221 open as the roadmap item and plan doc it already is, and starting at Phase 1 when a real GitLab instance exists to design against. Nothing in the current code makes that later start more expensive than an earlier one.

[serge-ivo]

Phase 3 read path shipped — 30afadf. Issue stays open; phases 3-write, 4 and 5 remain.

First, the elephant. The one comment on this issue (2026-08-06) recommends deferring, and I
did not overturn it — I implemented the part it explicitly blessed and left the part it warned
about alone. Its argument is specifically that generalising installationTokenForOwner(env, userId, owner) would not survive contact with GitLab's user-scoped token or Bitbucket's
workspace-scoped OAuth. That signature is untouched. Phase 1 (d9d01bf) already agreed with
it and abstracted the output instead; this commit does the same thing one layer up.

What was actually still broken

Phase 1 made a repo know its host. It could not answer a question about it, because all five
hosted surfaces still opened with the same expression:

if (!repo.githubRepo?.includes("/")) return refuse()

That one line carries three separate claims: is this repo hosted at all, do we know its
coordinate, and is its host one we can drive. Fusing them is why a correctly-added GitLab repo was
told its Issues panel "isn't connected to GitHub" — the only false claim was the third, and the
sentence reported the second, sending the owner to fix a mistake they had not made.

Shipped

• lib/hosted-repo.ts — the dispatcher. hostedReadRefusal answers "can this be asked" and
  returns the sentence that is actually true; the readers answer "what did the host say". Six
  call sites share it: /issues, /issues/:n, /next-issue, /deployment, /deployments,
  /builds, /pulls.
• lib/gitlab-api.ts — GitLab REST v4 reads: issues + pipelines, over the vault PAT the
  clone already uses (user_api_keys provider gitlab), public projects unauthenticated.
• supports becomes three independent flags. GitLab is now {issues:true, builds:true, pulls:false} — it reads issues and pipelines but has no merge-request client, and a single
  hosted:boolean would have made turning the first two on assert the third.
• The Co-pilot reads through the same dispatcher. Leaving coding-inspect.ts on the GitHub
  client would have shipped exactly the half-migration this issue must not: the Issues panel
  listing a GitLab backlog while the brain, asked about the same repo, said "not connected to
  GitHub".

Two mappings are decisions, each with a test that fails on the plausible mistake: an issue's
number is GitLab's iid, never its globally-unique id; and a pipeline's single status is
widened into GitHub's (status, conclusion) pair rather than teaching the console a second
vocabulary.

GitHub is a re-route, not a rewrite

Same resolveGithubRead so the conditional cache's identity and the token it was minted under
come from one resolution (#401/#418). Same unauthenticated fallback for a public repo's Actions
runs (CODER-010/#121). Same {available:false} bodies with no run key (#304). /builds still
filters before fanning out — now by "can this host be asked" instead of by github_repo.

Verified

Ten CI gates green; 6,756 tests / 408 files; CI's Playwright e2e green. No migration —
provider/repo_slug shipped in 0097, this is a code-level dispatch.

Then, against the live gitlab.com API, using the exact URL shape the client builds
(gitlab-org/gitlab-runner, unauthenticated):

Field	Live value	Consequence
iid vs id	39333 vs 186596050	confirms the iid decision is load-bearing, not cosmetic
state	"opened"	normalised to open, the word every caller filters on
pipeline name	null on every real pipeline	the source fallback ("merge_request_event") is exercised in reality, not a nicety
user_notes_count, labels[], web_url, ref, sha, updated_at	all present as mapped	—

Not verified, and it is the thing that matters

No end-to-end run against a GitLab repo attached to a Coder instance — nobody here has GitLab
credentials, which is precisely the condition the deferral comment named ("someone has a GitLab
account we can authenticate against"). The mappings are pinned against recorded shapes plus the
live probe above, and the dispatch is pinned by a test asserting a nested GitLab slug never
reaches api.github.com (group/sub/project is not an owner/repo; a leak would build an
authenticated request against a namespace nobody asked about). The first real project pointed at
this is the acceptance test.

Left open, deliberately

• Phase 3 writes (creating a GitLab issue). The registry connector's tools stay github_* —
  they are explicitly GitHub-named tools taking an owner/repo argument, not repo-row surfaces,
  so they are not a half-migration of this seam.
• GitLab merge requests — github-prs.ts is substantial (checks, review state, mergeability,
  run correlation); claiming it from an untested mapping is what supports.pulls:false prevents.
• Phase 4 (Bitbucket) — still blocked on the vault holding one opaque value per provider while
  an app password is a username + secret.
• Phase 5 (provider presets).
• Self-managed hosts resolve as other: they clone fine and claim nothing. gitlab-api.ts
  hardcodes gitlab.com, which is what keeps its URL a constant — no request field on this path
  can move where an authenticated read is sent.

Status section of agents/coder/GIT_PROVIDERS_PLAN.md updated to match.