A CI/CD server, also called a build server, runs the tasks in a software delivery pipeline and brings its components together. During continuous integration, it can turn code into software artifacts and run tests after changes are integrated. For API teams, the same platform can also check API definitions and guide documentation before proposed changes are merged. section 8.0 section 8.3
A pull-request (PR) build is a build-server job triggered when someone proposes a change. It runs checks before reviewers spend time on the proposal, then displays its status on the PR. If it fails, the submitter can follow the link to the job results and inspect the logs. The checks and failure thresholds should reflect the team's merge criteria. section 8.3 section 8.7
For an API design proposal, a PR build can:
- Check the PR title with a script and use a PR template to prompt for the reason behind the change. section 8.3
- Lint API definitions with Spectral, failing the build on ERROR-level problems; lint Markdown guide documentation according to its configured failure level. section 8.3 section 8.7
- Compare old and new API definitions for breaking changes with Tufin/oasdiff, failing the build when it detects one. section 8.3 section 8.7
A passing build clears a path for review; it does not replace review. Reviewers still need to examine the build report for non-failing warnings. A code-hosting service's code-owners feature can separately require approval from an API governance team member before affected files are merged. GitHub Actions is one possible build-server platform, not a required pipeline design; some hosting and build-server combinations may need additional PR-build setup. section 8.0 section 8.3 section 8.7
