Validation on pull requests

August 6, 2026 · View on GitHub

CAMARA Validation runs on pull requests to main in onboarded API repositories. If the repository releases from a maintenance branch, validation may also run there according to the repository's workflow configuration. This page describes what you see, what you do about it, and what codeowners should check before merge.

What you see

When you open or update a pull request, CAMARA Validation appears in the checks list, with annotations attached to the changed lines. The complete validation report is the workflow summary linked from the check.

For where validation results are shown and the differences between same-repository and fork pull requests, see Where to see validation results. For the format of each problem message, see Validation problem messages.

What you do

  1. Open the workflow summary linked from the CAMARA Validation check.
  2. Look at errors first. Errors should be fixed before merge. During the pilot, GitHub may not technically block every pull request merge on validation errors, but errors will block the release process at /create-snapshot and should not be left on main intentionally.
  3. For each error, read the source file and line shown in the message and fix it in your branch. Use the rule code (for example [S-002]) to look up extra guidance in the Validation FAQ when the short message is not enough.
  4. Push the change. The check re-runs automatically.
  5. Look at warnings and hints before requesting review. They are not errors, but many of them turn into errors at a later release type — fixing them in the same pull request is usually cheaper than returning to them later.

What can block you

A few common patterns to be aware of when reviewing the validation results:

  • Errors in API definitions, test files, or release-plan.yaml. Fix the source file before merge — leaving them on main will block /create-snapshot.
  • Warnings that will become errors at a later release type. Common example: missing test files are a hint on alpha releases, a warning at release candidate, and an error at public release. Plan to fix them before the next release type is reached.
  • Hints pointing at items to verify, not items that always need to change. Read the message before acting.
  • A problem in a cached common file under code/common/. Do not edit the cached file locally — see Bundled API definitions and the FAQ entry for [P-021].
  • A change to release-plan.yaml mixed with other changes. Rule [P-022] requires release-plan.yaml updates to be in their own pull request — split the pull request if needed.

When the short message is not enough to act, look up the rule code in the Validation FAQ.

Codeowner guidance

  • Do not intentionally merge errors to main unless the repository has explicitly accepted the resulting release-process risk. The release process at /create-snapshot will block until the errors are gone. Warnings and hints are not blocking, but scan the workflow summary before merge and confirm the warnings make sense in context — many of them indicate something that will block a later release type.
  • Some pull requests need a maintainer to approve the workflow run before it can start at all. GitHub does this for pull requests it doesn't yet trust to run automatically — most commonly, someone's first pull request to the repository. Until a maintainer approves the run, it will not start, so the CAMARA Validation check is missing from the checks list entirely, not passing or failing. If a pull request has no CAMARA Validation check yet, open its Conversation tab and look near the merge box for a banner asking to approve the pending workflow run, rather than assuming there was nothing to check.

For what each severity obligates your team to do, and why the same rule can report differently as your API's status advances, see What a validation result obligates your team to do.

What to open next