GitLab and Bitbucket repositories

Hyperoru brings GitLab and Bitbucket repositories through the same evidence pipeline as GitHub without treating account access as permission to audit every project. An Owner or Admin creates a provider connection, Hyperoru discovers visible projects, and every newly discovered project starts outside the audit scope.

Permission boundary

Hyperoru encrypts the token with workspace and connection identity as associated data. The API returns only has_credential; neither a workspace response nor the operator dashboard can retrieve the token. Repository contents are processed by the isolated runner and are not made available to the admin control plane.

Connect and select projects

1. Open Repositories → Repository providers.
2. Choose GitLab or Bitbucket.
3. Name the connection and enter its account boundary and write-only token.
4. Review the discovered project inventory.
5. Select only the projects Hyperoru may audit.

A later sync preserves existing selections. Newly discovered projects remain unselected, and projects no longer visible to the provider token are archived and disabled instead of silently disappearing from history. Revoking the connection disables every linked project while preserving past audits and reports.

GitLab host validation

GitLab.com is supported directly. A self-managed GitLab base URL must use public HTTPS, must not contain credentials, and must resolve outside loopback, link-local, private, multicast, reserved, and unspecified networks. API redirects are disabled. Project clone and web URLs must stay on the authorized GitLab host.

Bitbucket connections use the fixed api.bitbucket.org and bitbucket.org boundaries. A workspace slug identifies the inventory boundary.

Sync and support diagnostics

The workspace sees connection state, account, project count, last sync time, and a safe error code. Platform operators see the same boundary and health metadata plus the number of projects explicitly selected. Tokens, repository archives, and source payloads are excluded from operator responses.

Use deterministic merge checks after selecting a project. The check submits the provider's full merge commit and refuses to enforce a result produced by a different concurrent audit.

Review changes automatically

Open Continuous reviews → Repository events, select an enabled repository, and configure its event connection. Connection setup requires an Owner or Admin. The webhook URL uses the deployment’s public base URL; the provider must be able to reach it over HTTPS.

1. Copy the repository-specific webhook URL into the provider’s webhook settings. Keep SSL verification enabled.
2. For GitLab, select Push events and Merge request events, generate a signing token, and paste it into Hyperoru. Older GitLab installations can explicitly select the legacy shared-token mode. Hyperoru never silently falls back to that mode.
3. For Bitbucket Cloud, select Repository push and Pull request merged, and enter the same secret of at least 32 characters in both applications.
4. Save the secret in Hyperoru and the webhook in the provider, then send a test delivery.
5. Create the event policy: choose branches, paths, minimum changed files, approval rules, and how to handle a review already in progress.

The signing secret is separate from the read-only repository token. It is encrypted with the workspace, repository, and webhook identity and never returned by the API. Setup does not expand repository access or install a webhook on your behalf.

Connection status and review status

Secret saved means configuration is stored. Last verified delivery confirms an authenticated event reached Hyperoru. Policies evaluated means the event was processed; it does not mean a security review finished or passed. Check the trigger decisions for the review link, queue position, approval request, or reason it was skipped.

Accepted events enter a durable inbox before the API acknowledges them. The worker retries interrupted processing, recovers expired leases, and deduplicates repeated deliveries. Failed deliveries remain visible and can be retried by an Owner or Admin. Replacing the secret or disabling the webhook cancels work from the previous configuration that has not yet been processed; already-created reviews remain in history. Revoking the repository connection also stops new processing.

How changed-file evidence affects a review

GitLab push payloads can omit older commits from large pushes. Bitbucket push payloads and merge events do not include a complete file list. Hyperoru uses the existing read-only repository connection to fetch a comparison at the event’s exact revision before evaluating path and file-count policies. Push comparisons use the previous and new commit from the signed payload; moving branch names are never substituted. Provider comparisons count a renamed file once, and a policy can match either its previous or new path.

Recent deliveries shows the branch, revision, and evidence available for each event:

Merge commits with multiple parents can be compared to their first parent. A single-parent merge might be a fast-forward containing several commits, so its first-parent comparison remains partial. New branches without a previous commit also retain an explicit coverage gap. Comparisons are bounded to 1,000 file records, ten Bitbucket pages, 4 MiB per response, and 15 seconds per event. Retries reuse the saved evidence; a delivery with many branches makes progress one branch at a time.

When the available evidence cannot establish whether a path or minimum-file condition matches, Hyperoru records Change evidence incomplete and asks for approval. Known matching files can still prove that the policy applies. Missing files never prove that a change is out of scope. A reviewer can approve a review of the exact revision, queue it, or reject it with a reason. File evidence confirms the comparison scope; the linked security review has its own execution status and results.

Branch deletions and tags do not start branch reviews. Merged events must identify the destination repository. When a merge commit SHA is omitted, the authenticated event must include the exact merge-request or pull-request number and source commit. Hyperoru saves that identity and reads the specific merged record from the provider. It checks the request number, target repository, target branch, source commit, and merged state before accepting the resulting commit.

Bitbucket sometimes supplies abbreviated commit hashes in pull requests. Hyperoru retains references of at least 12 hexadecimal characters, expands them through the provider's commit API, and checks that the full commits match both the signed event and the pull-request record. A source commit from a fork is read using that fork's immutable repository ID. An unresolved reference never becomes a review revision: reviews always use a full 40-character SHA.

Waiting for the exact merge commit means the event is retained but no review or approval decision can start yet. Hyperoru retries automatically with bounded delays. After eight unsuccessful attempts, delivery history explains the failure and offers Retry delivery to an Owner or Admin. Check that the repository connection is active and can read the merge request. Bitbucket tokens need Pull requests: Read in addition to repository access for this lookup.

Malformed identities remain rejected. Hyperoru never substitutes a moving branch head, the source commit, or an intermediate squash commit for a missing merge result. Once resolved, the exact revision and its comparison evidence are saved and reused after an interrupted worker run. Disabling the webhook, revoking the connection, or rotating credentials during lookup cancels that work. Pair event policies with scheduled reviews and merge checks when you need coverage for events a provider does not deliver.

Rapid changes and the review queue

Minimum review interval spaces automatic review starts for the same policy and branch. A matching revision received during the interval stays in the durable queue with its exact commit. It is not discarded or replaced by a newer revision. Set the interval to 0 to remove this delay. For API compatibility, this setting retains the name debounce_seconds.

The interval starts when the preceding review is created. A later operator cancellation or decision does not restart that clock. Admin shows the same earliest automatic start and explains why a retry cannot run. Operator retries preserve the interval and must still satisfy the current policy version and access checks.

The interval is measured from the previous review’s actual dispatch. Review decisions shows the earliest automatic start when a review is delayed. Other queued reviews and scanner capacity can make the actual start later. Authorized reviewers can choose Review sooner, provide a reason, and bypass the interval for that revision; an active review still finishes first. Cancel queued run records a reason without starting the review.

The conflict policy still controls events received while a review is active. Use Queue after current to retain matching revisions. Ignore duplicate and Cancel incoming deliberately decline those new reviews. Protected branches and policies requiring human approval continue to require a separate decision for every revision, even during a rapid burst of events.

A busy, delayed, or temporarily failing repository does not block ready work in other repositories. Before dispatch, Hyperoru rechecks the policy or schedule version, source connection, workspace availability, and reviewer access. Work from a paused, disabled, or changed configuration is canceled with an explanation instead of running under stale authority. Approving a replacement after revocation cannot cancel the running review.

Provider contracts: GitLab webhook authentication, GitLab event payloads, Bitbucket webhook authentication, and Bitbucket event payloads.

Comparison contracts: GitLab repository comparisons and Bitbucket commit diff statistics.

Merge identity contracts: GitLab merge requests, Bitbucket pull requests, and Bitbucket commit resolution.