ENGINEERING

Block PRs that introduce breaking OpenAPI changes

On every pull request that touches the OpenAPI spec, diff it against the base branch, classify changes as breaking or additive.

CategoryEngineering
Enginesim
Difficultyintermediate
Triggerevent
Steps5
Setup~15 min

How it runs

The automated pipeline, trigger to output.

  • TriggerPull request edits the OpenAPI spec fileGitHubGitHub
  • ActionFetch base and head versions of the specGitHubGitHub
  • ActionCompute structural diff between the two specs
  • LogicClassify changes: breaking vs additive vs cosmetic
  • OutputPost commit status + inline PR comment with verdictGitHubGitHub

What it does

Watches pull requests for edits to your `openapi.yaml` (or JSON) spec. When one changes, it compares the PR version against the base branch, separates breaking changes (removed endpoints, deleted fields, narrowed types, new required params) from safe additive ones, and writes the result back to the PR as a status check plus a comment.

When to use it

Use it when multiple teams depend on a shared HTTP API and you want a hard gate in CI rather than relying on reviewers to spot contract regressions by eye. Ideal for platform or API teams enforcing semver discipline on their public surface.

How it works

  1. 1A pull_request event fires when the spec file is modified.
  2. 2The flow fetches both the base and head versions of the spec from GitHub.
  3. 3A diff step computes the structural delta between the two documents.
  4. 4A logic branch classifies each change as breaking, additive, or cosmetic.
  5. 5If any breaking change exists, it posts a failing commit status and an inline PR comment listing each violation; otherwise it posts a passing status.

Set it up

What you configure once, before turning it on.

  1. 1
    Connect GitHubRepos, issues, pull requests, actions.
  2. 2
    Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
  3. 3
    Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
  4. 4
    Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.

Run this workflow in your colony.

14-day trial. No DevOps. No Sales call. Provisioned in under a minute.