Pull request build

As explained in Automating API Delivery

A pull request build is an automated validation build triggered for a pull request to provide feedback on changes before integration.

A pull request build is an automated job triggered when a pull request is raised. It validates proposed API changes before integration and reports its status directly in the pull request interface, giving submitters and reviewers fast feedback. section 8.7

A practical API pull request build can:

• Run API linting against definition files and fail on ERROR-level violations. section 8.7
• Compare old and new definition files and fail when breaking changes are detected. section 8.7
• Lint Markdown guide documentation, run custom scripts, and preserve warnings for reviewer inspection even when they do not fail the build. section 8.7
• Require governance approval through code owners after automated minimum design-review criteria pass. section 8.3

Fast feedback policy

Keep the pull request build to no more than five minutes where practical. Parallelize independent jobs to reduce waiting time, then let reviewers investigate warnings and other findings that did not fail the build. section 8.11.2 section 8.7

Figure 8.2 The process the Acme team uses to check that PRs satisfy the minimum design review criteria and get approval from the governance team

Use the process diagram to trace automated PR checks through governance approval and the merge decision. section 8.3

How Automating API Delivery covers it

How deep it goes

Combines linting, breaking-change checks, documentation checks, custom scripts, reporting, and approval gates, while deferring human design judgment.

Examples

Uses API definitions, Markdown guides, build logs, PR status displays, parallel jobs, and governance approval workflows.

What it assumes

Assumes a pull-request workflow, version-controlled API definitions, and a configured build server; explains automated checks within that workflow.

What you can do after

Diagnose failed API checks from pull request status and build logs, then distinguish blocking errors from review-only warnings.

How it connects

Connects API linting, breaking-change detection, code owners, continuous integration, build servers, and deployment pipelines.

liveBookmanning.com

Read Automating API Delivery on liveBook Get the book at manning.com

Related concepts

• breaking change checkuses · A breaking change check detects changes between API versions that can cause existing consumers or implementations to stop working.
• CI/CD serveruses · A CI/CD server is a computer or service that automates software integration, building, testing, packaging, validation, and delivery or deployment tasks.
• api lintinguses · API linting is the automated analysis of an API description or design against rules for correctness, consistency, security, and maintainability.
• fast feedbackproduced by · Fast feedback is the timely communication of automated check results indicating whether a software change preserves expected behavior.
• pull requestused by · A pull request is a version-control proposal to integrate changes from one branch or repository into another, typically supporting review and discussion before merging.
• GitHub Actionsimplemented by · GitHub Actions is GitHub’s workflow automation platform for defining and running jobs in response to repository events, schedules, and other triggers.

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.