Reviews and quality

Code review: feedback in your pull requests

Let Yavaren review pull requests against your active rules and comment in the pull request; you choose which, and how.

Yavaren can review pull requests with an AI reviewer that applies your organisation's active enforcement rules (see Standards), then post its feedback in the pull request. It comments; it never approves, merges or pushes. A person on your team always decides.

Switch it on

Open Code review. An admin ticks Code review is on for your organisation and saves. From then on:

• Pull requests Yavaren opens are reviewed after every delivery, before anyone looks. This is on by default once the reviewer is on; you can turn it off for the organisation or for one repository.
• Pull requests your developers open are reviewed only for the repositories where you switch it on. It is off by default.

Reviewing your developers' pull requests

For each repository where you want it:

1. Under Repositories, choose Change and set Your developers' pull requests to On.
2. Choose Make the webhook address. Copy the address and the secret: they are shown once.
3. Add them to the repository's webhooks on your host, as the screen says (GitHub, GitLab, Azure Repos, Bitbucket Cloud or Bitbucket Server). Only pull request events are needed.

Making a new address stops the old one. Stop the webhook stops it altogether. A repository needs an active project that uses it: one of that project's engineers does the review.

How it gives feedback

• Comments only (the default): comments on the lines concerned and one summary comment that is updated, not repeated, on every new commit. Nothing is blocked.
• Also ask for changes when a must rule is broken: where your host lets Yavaren do so (GitHub, Bitbucket Cloud), the review asks for changes, but only when one of your active must rules is not met.
• Commit status: turn it on to get a "Yavaren review" status on the reviewed commit. It is a success unless a must rule is broken in the mode above. A branch rule on your host can require it.

You can also choose how serious a finding must be to be posted on a line, how sure the reviewer must be, the most comments per pull request, paths to leave out (such as docs/**), and whether draft pull requests are reviewed.

What it never does

• It never approves or merges a pull request, and never pushes to any branch.
• It does not run your developers' code, unless you turn on Run the rules' command checks on your developers' pull requests. Then only the quality gates of the repository's stack profile can run, on your runner.
• Text in a pull request is read as content: if it tries to instruct the reviewer, the summary says so and nothing obeys it.

Where to see the results

The Reviews list on the Code review page shows every review, with its findings. A delivery's details show the review of the pull request it opened. Each completed review counts as one review on your statement; reviews are priced through your package.