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
