Problem
Split out from #499 (which shipped Gitea/Forgejo/Codeberg — see #653). Bitbucket was explicitly deferred there: "Bitbucket — separate issue once Gitea lands."
Bitbucket users (Cloud + Data Center/Server) currently fall through detect_forge_from_url and can't get automatic release creation — they must script it via a hook.
Proposal
Add a Bitbucket variant to ForgeKind and a src/forge/bitbucket.rs implementing the Forge trait, mirroring the structure of gitea.rs / gitlab.rs.
Unlike Gitea (which is ~GitHub-v3-shaped), Bitbucket's API is its own surface, so expect less code reuse:
- Bitbucket Cloud (
bitbucket.org) — REST API 2.0 under https://api.bitbucket.org/2.0. Auth via app passwords / workspace access tokens (Authorization: Bearer or Basic). Note: Bitbucket has no native "release" object like GitHub/Gitea — releases map to annotated tags (already created by FerrFlow) plus optionally a Downloads entry or a PR-mode flow. Decide the release surface: tag-only vs. tag + PR comment.
- Bitbucket Server / Data Center (self-hosted) — different base path (
/rest/api/1.0), different auth. Lower priority; may file as a follow-up.
Detection: hostname allow-list (bitbucket.org) + explicit forge = "bitbucket" override for self-hosted, consistent with how Gitea landed. Self-hosted auto-probing is tracked separately in #332.
Auth env vars: BITBUCKET_TOKEN (+ workspace/user for Basic if needed).
Out of scope
Test plan
- Unit tests for the Bitbucket API client (mocked HTTP responses), same pattern as
gitea.rs tests.
- Detection distinguishes
bitbucket.org from self-hosted GitHub/Gitea.
- Error codes in the
E33xx range (Gitea took E32xx), documented in docs/errors.md.
Docs
User-facing: add "bitbucket" to the forge field in the config reference on ferrflow.com (EN + FR), same as the Gitea doc PR (FerrLabs/FerrFlow-Cloud#661).
Related #499, #332.
Problem
Split out from #499 (which shipped Gitea/Forgejo/Codeberg — see #653). Bitbucket was explicitly deferred there: "Bitbucket — separate issue once Gitea lands."
Bitbucket users (Cloud + Data Center/Server) currently fall through
detect_forge_from_urland can't get automatic release creation — they must script it via a hook.Proposal
Add a
Bitbucketvariant toForgeKindand asrc/forge/bitbucket.rsimplementing theForgetrait, mirroring the structure ofgitea.rs/gitlab.rs.Unlike Gitea (which is ~GitHub-v3-shaped), Bitbucket's API is its own surface, so expect less code reuse:
bitbucket.org) — REST API 2.0 underhttps://api.bitbucket.org/2.0. Auth via app passwords / workspace access tokens (Authorization: Beareror Basic). Note: Bitbucket has no native "release" object like GitHub/Gitea — releases map to annotated tags (already created by FerrFlow) plus optionally a Downloads entry or a PR-mode flow. Decide the release surface: tag-only vs. tag + PR comment./rest/api/1.0), different auth. Lower priority; may file as a follow-up.Detection: hostname allow-list (
bitbucket.org) + explicitforge = "bitbucket"override for self-hosted, consistent with how Gitea landed. Self-hosted auto-probing is tracked separately in #332.Auth env vars:
BITBUCKET_TOKEN(+ workspace/user for Basic if needed).Out of scope
Test plan
gitea.rstests.bitbucket.orgfrom self-hosted GitHub/Gitea.E33xxrange (Gitea tookE32xx), documented indocs/errors.md.Docs
User-facing: add
"bitbucket"to theforgefield in the config reference on ferrflow.com (EN + FR), same as the Gitea doc PR (FerrLabs/FerrFlow-Cloud#661).Related #499, #332.