Skip to main content
Bitbucket Pipelines

CodeRifts for Bitbucket — a decision on every pull request

Not run. The component/pipe calls coderifts check, a command that does not exist in coderifts 8.8.0 (measured 2026-10-17). Do not count this as an enforcement path until it is re-run. re-measured 2026-10-20: npx -y coderifts@8.8.0 check → error: unknown command 'check'

Only a granted change can proceed.

The enforcing boundary on Bitbucket is a required custom merge check.

The adapter reads branch restrictions and does not apply the check.

A configuration read of that merge check is not available.

A live Bitbucket project is not measured.

What this gate does. Advisory unless you make the check required — and even then, read the limit below: a build status on Bitbucket can be overwritten by anyone with repository write.

Add a CodeRifts contract check to your bitbucket-pipelines.yml and catch breaking API changes before they reach production. Three steps, five minutes.

Format coverage, read 2026-10-04, is the table on the documentation page. An incomplete analysis in authorize mode is ANALYSIS_FAILED and STOP, with the gap named.

Setup in 3 Steps

No native app to install. Just add the check to your pipeline.

1

Get a free API key

Sign up at app.coderifts.com/api/signup to get your API key.

2

Add CODERIFTS_API_KEY as a repository variable

Go to Repository settings → Pipelines → Repository variables and add the key as a secured variable.

3

Add the contract check to bitbucket-pipelines.yml

pipelines:
  pull-requests:
    '**':
      - step:
          name: API Contract Check
          image: alpine:latest
          script:
            - apk add --no-cache curl jq git
            - git fetch origin "$BITBUCKET_PR_DESTINATION_BRANCH"
            - OLD=$(git show "origin/$BITBUCKET_PR_DESTINATION_BRANCH:api/openapi.yaml")
            - NEW=$(cat api/openapi.yaml)
            - |
              RESULT=$(jq -n --arg o "$OLD" --arg n "$NEW" '{old_spec:$o,new_spec:$n}' \
                | curl -sf -X POST https://app.coderifts.com/api/v1/diff \
                    -H "Authorization: Bearer $CODERIFTS_API_KEY" \
                    -H "Content-Type: application/json" -d @-)
              echo "$RESULT" | jq .
              BREAKING=$(echo "$RESULT" | jq '.breaking_changes // 0')
              if [ "$BREAKING" -gt 0 ]; then
                echo "ERROR: $BREAKING breaking change(s) detected:"
                echo "$RESULT" | jq -r '(.changelog.breaking // [])[]'
                exit 1
              fi

Every Pull Request will now run this CodeRifts check automatically.

Advisory — this gate trusts the CodeRifts API response and fails the CI job. It does not verify a signed receipt, and it blocks a merge only if you make the job a required check. For a required-check merge gate with offline receipt verification — use branch restrictions, and read the limit with them: a green build is not an unforgeable gate. Any actor with repository write can overwrite a build status by posting a new one on the same commit, and the control that would be unforgeable — a required custom merge check — exposes no API for reading its configuration. A configuration read here can never rise above UNVERIFIABLE.

What It Does

On every Pull Request, CodeRifts analyzes your OpenAPI specs and reports:

Breaking Changes

Detects 10 types of breaking changes: endpoint removals, type changes, required field additions, and more.

Risk Scoring

Returns a 0–100 risk score. The score is a heuristic, not a calibrated probability — read the decision and the named patterns, not the number.

Policy Checks

Checks policy violations from your .coderifts.yml — breaking budgets, freeze windows, no-delete rules.

Security Analysis

Catches auth regressions, sensitive field exposure, and security-critical schema changes.

Deprecated: the Docker pipe

The docker://coderifts/bitbucket-pipe image is not currently published to Docker Hub. Use the API call above (advisory — it trusts the API response and fails the job), or coderifts/contract-gate as a required check. We do not issue VERIFIED for Bitbucket from configuration alone — the result is capped at UNVERIFIABLE until a behavioural canary observes the provider actually refusing a merge. What VERIFIED means, per provider states why. See the REST API documentation for full details.

Start protecting your APIs in Bitbucket today.

Add the contract check, get your free API key, and catch breaking changes on every Pull Request.