Bitbucket Data Center

OpenReview uses Bitbucket's native REST API and signed webhooks. This adapter is separate from the Bitbucket Cloud Forge app. Native API contract tests pass; no external Data Center instance has been connected for live acceptance.

Connect

Authorize the instance hostname (including a non-default port) in the server and Convex SCM_ALLOWED_HOSTS. Use a trusted HTTPS instance URL, including its context path, such as https://bitbucket.example/bitbucket.
In Settings → Code providers, select Bitbucket Data Center. Supply a dedicated bot's HTTP access token and username as JSON: {"token":"<HTTP access token>","username":"<bot username>"}. Give the bot repository write on the selected repositories. Avoid a site administrator token. Credentials and webhook secrets are encrypted with workspace/provider scope.
Save a random webhook secret of at least 32 characters. Select authorized repositories, then enable/index them using repository settings. Discovery requires write access and filters out archived/unavailable repositories. HTTPS clone links must belong to the configured instance.
In Bitbucket repository or project settings, add the displayed OpenReview webhook URL. Enter the saved secret using HMAC SHA-256. Keep TLS verification enabled. Subscribe to Push, PR Opened, Source branch updated, Modified, Merged, Declined, Deleted, and Comment added events, plus reopening where the installed version supports it.
Verify a delivery before enabling automatic reviews. OpenReview checks X-Hub-Signature against the exact body, matches X-Event-Key to the signed event key, and deduplicates X-Request-Id within the connection. Durable event leases bound retry/crash recovery.

See Atlassian's HTTP access tokens, webhook setup, event payloads, and REST reference.

Behavior and limits

Repository identity is the connection, instance, and native numeric repository ID. The adapter checks identities before source access and uses the target repository for forked PR events.
Reviews use the native merge base and source commit. The target branch commit is a separate revision key; changed target revisions invalidate an in-flight review. Metadata/comment versions are not mistaken for code revisions.
Cross-repository author matching requires an immutable numeric native ID on an active NORMAL account. Service, inactive and unspecified account types cannot provide this author proof. Ingestion rechecks author identity, both repository/branch refs, draft state and native reviewer decisions after reading the diff. Native APPROVED and NEEDS_WORK decisions retain their lastReviewedCommit, including old-revision decisions, and are supplied as bounded review context. Contradictory duplicate participants or decisions without reviewed commits fail visibly. These decisions are context, not runtime execution evidence. Opt-in native approval uses separate activity-owned receipts and the trusted approval gates below.
Native JSON diffs retain path components, rename paths, added-line anchors, and hunk boundaries. Truncated inventories, diffs, segments, lines, binaries, or inconsistent spans stop the review visibly. The native changes endpoint cannot be paged past its server cap.
Findings publish as RANGE comments pinned to both commits. Fix links use the existing authenticated landing page and paired local bridge. Findings must point to added lines. Bot-owned run/finding markers prevent normal retry duplication; summaries and thread replies use native comments. There is still a read/check/write race against concurrent native pushes; live publication acceptance is required.
Build status comes from the documented legacy commit-status list endpoint, which remains present in the 10.5 REST schema. It supplies CI context, not OpenReview runtime execution evidence. Opt-in native approval uses the safeguards below. The runtime worker can now acquire a commit-pinned native Data Center archive; actual execution remains opt-in and requires a separately paired worker and approved image/command.
Follow-ups and explicit re-review require an exact, active NORMAL author returned by native /users?permission=REPO_WRITE&permission.projectKey=…&permission.repositorySlug=…. Bitbucket resolves effective permission, including inherited grants; OpenReview does not infer access from group names. The documented user lookup requires authentication rather than repository/site admin. Results are fully paginated and rechecked before answering, learning and publication. Missing type, service accounts, name mismatches, revoked access, malformed responses and incomplete pages cannot authorize an answer. Actual inherited-group, project and global-admin acceptance still requires a live Data Center instance.
Explicit re-review commands persist an atomic receipt keyed by repository and native comment ID. Re-delivery under a different webhook delivery ID cannot enqueue the same command twice; a new comment is needed for another explicit review. The receipt and new review are committed together, including the target revision key.
File enumeration is capped at 10,000 entries and sources at 200 KB. Oversized/non-UTF-8/binary sources produce explicit index exclusions. Network errors fail rather than masquerading as excluded files. File cache keys use the native last-modified commit for each path, so unrelated later commits reuse existing source/index entries. Enumeration checks every file against its parent directory's last-modified map and fails on missing entries. Branch protection badges are not populated from native branch restrictions.

Live acceptance still required

Use a disposable Data Center project to verify token scope, context-path routing, repository selection, indexing, fork/rename/base updates, signed event retries, inline publication, comment follow-ups, updated-revision review, Fix launch, and disconnect/revocation. Contract fixtures do not establish a working external installation.

Exact-revision runtime source

The native archive endpoint accepts an explicit commit and tar.gz format. OpenReview requires a full immutable Git commit, verifies the configured numeric repository identity before and after download, and uses a fixed openreview/ prefix for the worker's extraction. No path filter or default-branch fallback is used. Credentials stay on the explicitly authorized HTTPS instance/context path; redirects are refused. The archive response must identify the configured bot through X-AUSERNAME. Missing/changed publisher headers fail visibly.

Compressed downloads are limited to 20 MB, checked against any supplied Content-Length, and streamed with cancellation on limits. Missing bodies or non-gzip responses fail before queuing source for execution. This supplies raw repository bytes independently of bounded review context. Existing worker source authorization, current revision/policy checks, no-network Docker limits and recorded startup/outcome evidence remain in force. A commit that cannot be archived from the target repository, including an unavailable fork commit, fails without changing to another revision.

Native-response tests verify archive transport/identities/limits and durable preparation → authorized worker source download, including visible publisher-mismatch failure without execution evidence. No Data Center installation or Docker execution from a real native Data Center archive has been verified yet.

Approval evidence foundation (historical local increment)

approvalEvidence performs native reads only. It requires the token's exact authenticated X-AUSERNAME header on every request, a unique active numeric publisher account, explicit draft/lock/version and participant coverage, and the selected target repository identity. Source and destination refs, native version, author and reviewer decisions are rechecked before returning. Human or unknown-account NEEDS_WORK decisions block eligibility; native merge conflicts, unknown outcomes and vetoes also block it. These checks do not certify a later native write.

Commit-status keys are read for the exact source commit. Duplicate keys, unknown states and incomplete cursors fail visibly. Atlassian documents a most-recent-100 status ceiling, so reaching 100 entries cannot establish full coverage and stops verification. Native activity IDs distinguish the publisher's latest explicit approval from later unapprove or ambiguous review-completion events; a second activity read detects a newer decision even when the participant remains approved at the same commit. An activity is evidence only, not an OpenReview receipt.

At this historical increment, publication and withdrawal were unavailable. The following implementation supersedes that state; live acceptance remains pending. See the Bitbucket 9.2 pull request reference and official OpenAPI schema.

Opt-in native approval (implemented; live acceptance pending)

Trusted organization/team/repository policies and the shared maximum-confidence review/runtime gates apply. Native merge vetoes must already pass, including any minimum-approval requirement; OpenReview does not discount its prospective approval. Additional checks use exact native status keys. A GitHub App identity cannot be satisfied by Data Center statuses. Approval remains disabled by default.

The current authenticated publisher changes only its own participant status using native PUT, with exact lastReviewedCommit and the documented PR version query guard. The latter is deprecated by Atlassian; instances that ignore its guard or omit required metadata are not accepted without native verification. Approval and post-write readback bind both refs, author and objections. An intact top-level native bot comment records the unique newly observed approval activity ID, source commit and destination revision. One native approval event must be observed after the request; absent or ambiguous events and unproven write responses stop without creating a receipt and require native inspection before retrying.

Replay needs the matching current participant and activity. Withdrawal reads the receipt author, current token identity, participant and latest bot decision twice; an old receipt cannot remove a later observed same-account decision. It changes only the publisher to UNAPPROVED, using the current exact source commit and version. Known receipt-write or revision-race failures invoke this same guarded cleanup; withdrawal errors stay visible. Closed PRs have no active OpenReview receipt and no status write is attempted. Native reads/writes and comment persistence cannot be atomic: concurrent native decisions and the installed version's guards must be tested on the actual instance. OpenReview never calls the merge endpoint with a write method.

Subscribe additionally to reviewer updated, approved, unapproved and changes requested events available on the instance. Signed pr:reviewer:* delivery rechecks existing approval jobs without a model review. Atlassian's changes-requested examples use both needs_work and changes_requested keys; both take this same route. PR changes/closure also recheck jobs, with the existing periodic sweep covering configured checks and policies. See native reviewer event payloads.

Native-response and durable factory/coordinator tests cover publication, replay, changed destinations, stale activity ownership, ambiguous events, human objections, missing metadata, closed changes, receipt failures and cleanup. No active Data Center instance, live native write, webhook subscription change or provider permission grant is claimed.