Task 3: Pull Requests and the Approver

In this task main stops taking changes directly: a change reaches it only through a pull request that passes its checks and has an approval.

• The approver is pr-reviewer, the GitHub App from the Git Collaboration course: a stand-in for a senior team member.
  • On a real team, a person reads every pull request, and approves only a change they judge right.
  • pr-reviewer never reads the code: it requests changes once, waits for a push, then approves, so you practise the round of a review.
• In a pair, the other student approves as well: either approval is enough to merge, and the author's own never counts.

Give pr-reviewer access to the repository

A GitHub App is installed on your account, and works only in the repositories you give it: give it devops-project, and nothing else.

• In a pair, the repository's owner does this: the app is installed on the owner's account.

Add the reviewer's configuration

The app reads its instructions from .github/reviewer.yml, and only from main.

1. Copy the file from team-rep into your repository:

   1$ mkdir -p .github
   2$ curl -fsSL -o .github/reviewer.yml https://raw.githubusercontent.com/YuvalShaul/team-rep/main/.github/reviewer.yml
   

   Its settings, under comments explaining each:

   1rounds: 1
   2merge: never
   

   • rounds: 1: it requests changes once, and approves on the next push.
   • merge: never: the merge button stays yours.

2. Commit it, and push it to main:

   1$ git add .github/reviewer.yml
   2$ git commit -m "Configure pr-reviewer"
   3$ git push
   

• Do it before you protect main: afterwards the file reaches main only through a pull request, reviewed by an app with no configuration.
• A pull request that edits the file changes nothing until it merges: the rules it is judged by come from main.

Protect main

A branch protection rule on main, the classic kind the Git Collaboration course sets up in its Branch protection chapter. GitHub's newer rulesets do the same job on another screen; use the classic rule, since you know its page.

1. Settings → Branches → Add branch protection rule, branch name pattern main.
2. The course's three settings:
   • Require a pull request before merging;
   • Require approvals: 1, under it;
   • Do not allow bypassing the above settings: without it you, the owner, are an admin, and admins are exempt.
3. Two settings the course did not need, because it had no pipeline:
   • Require status checks to pass before merging, and pick the jobs of pr.yml by name: lint, unit-tests, integration-tests, security, image-build.
   • Require branches to be up to date before merging: the pull request's checks then ran on the code that lands on main, so the merge workflow need not test it again.
4. Save changes.

• A check is in the list only after it has run once: the pull request you opened in Task 2 is what put them there.
• A check's name is its job's name. A matrix job adds its value, unit-tests (3.13), and each of those is a check of its own to require.
• A required check that never runs blocks the merge forever. If a later task gives pr.yml a paths: filter, a pull request changing only the README waits for checks that never start.
• Force pushes to main are blocked by the rule as it is: it allows them only when you tick the box that does.

Push to main, and read the refusal

• A direct git push to main is refused. TODO: the error text.

Open a pull request, and wait for the approver

• The checks run, the merge button stays blocked.

• pr-reviewer requests changes. Answer with a commit, an empty one if nothing needs changing, and push it:

  1$ git commit --allow-empty -m "Answer the review"
  2$ git push
  

• pr-reviewer approves, and the merge button works.

• Merge: the merge workflow runs.

The empty pipeline is now complete: every event runs its jobs, and the gate holds.