liveBook · Manning

Breaking change check

As explained in Automating API Delivery

A breaking change check detects changes between API versions that can cause existing consumers or implementations to stop working.

A breaking change check compares API definition versions to detect modifications that can stop existing consumers or implementations from working. Used as an automated governance control, it moves compatibility review into the API delivery workflow while leaving contextual design judgment to human reviewers. section 1.0 section 1.6

A pull-request pipeline typically performs the check as part of minimum design review criteria:

  • Check out the main-branch API definition into a separate base directory. section 8.5.4
  • Compare the base definition with the pull-request revision using a breaking-change checker. section 8.5.4
  • Configure the check to fail the build when a breaking difference is detected. section 8.5.4
  • Review the failure alongside API linting, prose linting, ticket checks, and human design review. section 8.14 section 8.5

Detecting a removed API path

A pull request changes /v1/catalog/categories to /vx/catalog/categories. The checker treats this as removing the original path and adding another, then fails the build with an error identifying GET /v1/catalog/categories as removed without deprecation. Reverting the change restores compatibility. section 8.5.4

      - name: Breaking change checks
        uses: oasdiff/oasdiff-action/check-breaking@main
        with:
          base: './base/chapter8/apis/product-catalog.oas.yaml'
          revision: './pr-branch/chapter8/apis/product-catalog.oas.yaml'
          fail-on-diff: true

The workflow listing shows the comparison explicitly: the action receives separate base and revision API definition paths and enables failure on differences. section 8.5.4

How Automating API Delivery covers it

How deep it goes
Explains branch checkout, definition comparison, failure configuration, and diagnostic output, but does not enumerate every compatibility rule.
Examples
Uses a product-catalog path replacement and reports an undeprecated GET path removal.
What it assumes
Assumes API definition files, branches, pull requests, and GitHub Actions while teaching the comparison workflow from the governance context.
What you can do after
Operate an oasdiff GitHub Action that compares main-branch and pull-request API definitions and fails on detected differences.
How it connects
Connects API definition files with API linting, CI/CD pipelines, API governance, and pull-request review.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Automating API Delivery. The section links point to the parts of the book it draws on.