grceng.academy
YAML lab 40 bonus XP

Encode review as branch protection

Start labRead the room

Objectives

"We already have change control: every change has a Jira ticket, and the tech lead approves his own PRs because he wrote the code and knows it best."

A ticket is a record of intent; branch protection is the enforcement. Write the repository governance record so the review requirement is enforced by the platform and evidenced by its API.

Repository facts

repo: acme/platform    default branch: main

Current state: protection disabled, 41 direct pushes to main
last quarter, CODEOWNERS file absent, one reviewer who is
usually the author.

Evidence sources available: github-api | jira-api | confluence
Conventional CODEOWNERS location: .github/CODEOWNERS

Checks the server runs (5)

  • Protection applies to the branch that ships
  • At least one approval required
  • Authors cannot approve their own change
  • History and direct pushes are locked down
  • Evidence comes from the enforcing system

Check names are all you see here: the expectations that decide pass or fail, and the reference solution, stay on the server.

Step-by-step hints

The guided walkthrough, in full. It is free: no XP cost, and it does not touch the paid hint ladder or the reveal gate.

  1. Step 1

    Re-read the brief and name the trap

    Two claims are doing the damage: that a ticket is a control, and that expertise substitutes for independence. Independence is the whole point of review: it is not a comment on anyone's competence.

  2. Step 2

    Protect the branch that matters

    The starter protects a branch that is not the one being deployed. Read the fixture for the default branch and use that.

    Protection applies to the branch that ships

  3. Step 3

    Require, then require independence

    First set a non-zero approval requirement. Then ask the separate question: does the platform count the author's own approval towards it? One flag in the starter answers yes today.

    Also point at the file that decides who is qualified to be that reviewer, using the conventional location from the fixture.

    At least one approval requiredAuthors cannot approve their own change

  4. Step 4

    Close the side doors

    An approval requirement is only as strong as the paths that bypass it. Two boolean fields in the starter let someone change the shipped branch without a reviewed pull request, and one of them also lets history be rewritten after the fact.

    Rewritable history means your evidence about what was approved is not evidence.

    History and direct pushes are locked down

  5. Step 5

    Evidence from the enforcer

    Ask which system can prove the rule was in force and that a given merge satisfied it. A ticket tracker records what people intended to do; only the platform that refused the push can prove what it refused.

    Evidence comes from the enforcing system

Rules summary

  • XP on pass

    40 bonus XP the first time every check goes green.

  • Paid hints

    2 available. Each costs 25% of the lab XP (about 10 XP).

  • Reveal solution

    Scores 0 XP and unlocks only after 3 check runs.

  • Attempt cap

    60 check runs per learner. The runner warns you in the last 10.

  • Drafts

    Your editor content is saved in this browser, so a reload will not lose work.

  • Walkthrough

    Always free and never penalised: use it before spending a hint.