Repository navigation
feat: Bitbucket Cloud pull requests (watch, run, wait, checks, MCP) - #24
Conversation
prw now works with bitbucket.org/<workspace>/<repo>/pull-requests/<N> URLs wherever it takes a PR URL. - internal/forge: parses GitHub and Bitbucket PR URLs and builds their links. Watch-list entries gain a host (empty for GitHub, so existing config files keep their meaning), and the same owner/repo#N on both is two different PRs. - internal/bitbucket: a Bitbucket Cloud client that answers in the github package's types, so the watcher, wait, checks, broadcast and the MCP tools work unchanged: source commit = head; OPEN/MERGED/DECLINED/SUPERSEDED map to open/merged/closed; build statuses (Pipelines, Jenkins, ...) become check runs with link and duration (STOPPED = cancelled); participants' approvals and change requests become reviews; the PR's merge checks become the merge state (git conflict -> conflict, failing blocking check -> blocked, else ready), reused for 2 minutes while the PR is unchanged. It reuses the GitHub client as transport (auth header, ETag cache, rate-limit errors, cancellation) and never follows a "next" link to another host with the credentials. - Auth: Atlassian API token + email (Basic) or an access token (Bearer), from bitbucket_token / bitbucket_email or BITBUCKET_TOKEN / BITBUCKET_EMAIL; anonymous for public repositories. A 404/401/403 explains how to set it up. No GitHub token is needed for Bitbucket-only watch lists. - Watcher: one client per host; rate-limit pauses are per host; a Bitbucket PR is checked at most once a minute (Bitbucket allows 1,000 requests/hour). - Notifications, generic webhooks, list (bitbucket:workspace/repo), --json outputs and MCP results carry the host and Bitbucket links. - `prw config set` no longer echoes token values. Auto-watch, --logs and `prw flaky` stay GitHub-only for now. Verified live with the real binary on public atlassian/atlassian-connect-express PRs: watch, run --once, list, checks (failed Pipeline with link and duration, merge blocked by a missing approval), wait --json. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1236b2d5d4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| name := s.Name | ||
| if name == "" { | ||
| name = s.Key | ||
| } | ||
| run := github.CheckRun{ID: s.UpdatedOn.UnixNano(), Name: name, HTMLURL: s.URL, StartedAt: s.CreatedOn} |
There was a problem hiding this comment.
When two build statuses have different keys but the same display name, this mapping discards their distinct identities: both have App.ID == 0, so github.LatestCheckRuns treats them as reruns of one check and drops whichever has the earlier update timestamp. A newer successful status can therefore hide an independent failed or still-running build, causing wait, checks, and MCP to report success incorrectly. Bitbucket identifies statuses by key, not name, as documented in its build-status API. Preserve that identity through aggregation rather than deduplicating distinct keys by display name.
Useful? React with 👍 / 👎.
prw now works with Bitbucket Cloud PRs (
bitbucket.org/<workspace>/<repo>/pull-requests/<N>) wherever it takes a PR URL.Design
Rather than rewriting the GitHub code paths, a Bitbucket client answers in the
githubpackage's types, so the watcher,wait,checks,broadcastand the MCP tools work unchanged; the only new concept is a host on each PR.conflict/blocked/readyinternal/forge: GitHub + Bitbucket PR URL parsing and links. Watch-list entries gainhost(empty = GitHub, so existing configs are unchanged); the sameowner/repo#Non both services is two PRs.internal/bitbucket: reuses the GitHub client as transport (auth header, ETag cache, rate-limit errors, ctx cancellation); never follows anextlink to another host with credentials; merge checks reused for 2 min while the PR is unchanged.bitbucket_token/bitbucket_emailorBITBUCKET_TOKEN/BITBUCKET_EMAIL; anonymous for public repos; 401/403/404 errors explain how to set it up. No GitHub token needed for Bitbucket-only watch lists.prw runchecks a Bitbucket PR at most once a minute; rate-limit pauses are per host.prw config setno longer echoes token values.--logs,prw flaky(clear errors / messages).Test plan
go test ./... -race,go vet ./...next--json, checks,run --oncewithout a GitHub token, private-repo hint🤖 Generated with Claude Code