ReviewOS

stacks/buddy

Add proper BitBucket support

#116
Closed chris opened this 9 days ago ·
9 days ago

Clear and concise description of the problem

Add proper BitBucket support

Suggested solution

Add proper BitBucket support

Alternative

No response

Additional context

No response

Validations

9 days ago

Status check — still blocked on #1390, and that blocker is now well-defined.

GitProviderName remains a single-member union ('github') on purpose, and src/git/github-provider.ts is still the only implementation. What has changed is that the surface a second provider must satisfy grew substantially this cycle — reviews, check runs, reactions, collaborator permissions, workflow-run logs, file reads at a ref, GraphQL auto-merge and issue pinning.

That makes #1390 more valuable rather than less: it should extract the interface from the actual call sites and ship a conformance test suite, so implementing this issue becomes "make the mock pass" rather than archaeology across a 1,700-line file. Worth doing #1390 first.

9 days ago

Unblocked. #1390 landed the GitProvider abstraction. Same checklist as #115 — implement GitProvider, pass test/git/provider-conformance.ts, register in IMPLEMENTED_PROVIDERS and createProvider(), add Bitbucket Pipelines templates to src/setup.ts.

Bitbucket will exercise the capability system harder than GitLab: no check runs, no native merge queue, different review-comment semantics. Declare those capabilities false and the callers already degrade — the conformance suite skips a capability's tests when the flag is off, and supports() gates every call site. See docs/advanced/providers.md.

Token convention is already BITBUCKET_TOKEN, BUDDY_BOT_TOKEN.

9 days ago

Implemented in acdd885 and 2a6872d.

BitbucketProvider passes the conformance suite. As predicted on this issue, Bitbucket exercised the capability system hardest — and forced two new capabilities into existence, which is the abstraction working rather than a workaround:

  • reopenPullRequests — a declined Bitbucket pull request is final. reopenPullRequest is absent from the provider entirely, so a caller gating on the flag degrades and one that does not gets a TypeError at the point of the mistake. Buddy's reuse-a-closed-PR path now checks before looking, and opens a fresh pull request instead.
  • labels — Bitbucket has none on pull requests or issues at all.

Also declared false: nativeAutoMerge, draftPullRequests, commentReactions, ciLogs, reviewSuggestions, pinIssues. Neither a fake draft nor a fake label is synthesised — a "[Draft]" title prefix nothing understands is worse than an honest absence.

The fake-API tests caught a real bug here too: Bitbucket returns file contents as plain text, not JSON, so reading any file through the ordinary JSON path turned every text file into a parse error and every parse error into a missing file.

Other specifics handled: /src creates the branch implicitly from a parent commit, so there is no window where a branch exists with nothing on it; deletions are repeated files parameters rather than per-file actions; and the issue tracker is optional per repository, so a 404 there means "no issues", not "broken".

bitbucket-pipelines.yml generation included, with custom pipelines for UI schedules to target.

Sign in to comment on this issue.