Why / the catch
Bitbucket is a common host, but unlike GitHub/GitLab/Gitea it has no blessed first-party CLI in the gh/glab/tea mold. Every existing provider here is a thin wrapper that shells out to a CLI which already handles auth and emits JSON. Bitbucket only offers a REST API, so a BitbucketProvider would be the first provider that has to do that plumbing itself - and that's the bulk of the work.
What's actually hard
- Auth becomes our problem.
gh/glab/tea log in once and we never touch credentials. Bitbucket would need app passwords / API tokens / OAuth read from somewhere (env, stk.*, a credentials file) - new surface, and secret handling we currently avoid entirely.
- HTTP, not a subprocess. Either add an HTTP-client dependency (talk REST directly: requests, pagination, error mapping, JSON) or shell out to
curl (ugly, still hand-rolls auth/pagination). Today there's zero network code in the providers; this introduces it.
- Cloud vs Data Center are different APIs. Bitbucket Cloud (bitbucket.org, REST 2.0) and Bitbucket Data Center/Server (self-hosted, a different REST API and PR model) are not interchangeable - likely two code paths or a scoped "Cloud first" decision.
Shape of the work (if pursued)
- Detection:
ProviderKind::Bitbucket, parse for "bitbucket", bitbucket.org host match, and a stk.bitbucketHost for Data Center (with the Cloud-vs-Server API split called out).
- Implement the 13
ReviewProvider methods against the REST API: list/create PRs, update destination branch, get/update description, merge (with merge strategy + the decline-as-close_review), merge_blocker from the PR's mergeable state, wait_for_checks from Bitbucket build statuses, open_reviews, draft handling (Cloud has limited draft support - verify).
- Config for auth credentials, documented; never logged.
Recommendation
Do this after the Gitea provider (#189) and only if there's real demand - it's materially more work and risk (new dependency, credential handling, two API dialects) than any provider so far. Worth keeping the issue open to gauge interest. If pursued, "Bitbucket Cloud only, app-password/API-token auth" is the smallest sensible first slice.
Severity: low-medium (enhancement; significant, and a departure from the CLI-wrapper architecture).
Why / the catch
Bitbucket is a common host, but unlike GitHub/GitLab/Gitea it has no blessed first-party CLI in the
gh/glab/teamold. Every existing provider here is a thin wrapper that shells out to a CLI which already handles auth and emits JSON. Bitbucket only offers a REST API, so aBitbucketProviderwould be the first provider that has to do that plumbing itself - and that's the bulk of the work.What's actually hard
gh/glab/tealog in once and we never touch credentials. Bitbucket would need app passwords / API tokens / OAuth read from somewhere (env,stk.*, a credentials file) - new surface, and secret handling we currently avoid entirely.curl(ugly, still hand-rolls auth/pagination). Today there's zero network code in the providers; this introduces it.Shape of the work (if pursued)
ProviderKind::Bitbucket,parsefor"bitbucket",bitbucket.orghost match, and astk.bitbucketHostfor Data Center (with the Cloud-vs-Server API split called out).ReviewProvidermethods against the REST API: list/create PRs, update destination branch, get/update description, merge (with merge strategy + the decline-as-close_review),merge_blockerfrom the PR's mergeable state,wait_for_checksfrom Bitbucket build statuses,open_reviews, draft handling (Cloud has limited draft support - verify).Recommendation
Do this after the Gitea provider (#189) and only if there's real demand - it's materially more work and risk (new dependency, credential handling, two API dialects) than any provider so far. Worth keeping the issue open to gauge interest. If pursued, "Bitbucket Cloud only, app-password/API-token auth" is the smallest sensible first slice.
Severity: low-medium (enhancement; significant, and a departure from the CLI-wrapper architecture).