Skip to content
BETAGuardrails are in beta. The library, the configuration format and the CLI command can still change.

Guardrails / git

The change is few enough lines to review

git/changed-lines-budget@v1

The build range adds and removes few enough lines that a reviewer can read the whole change before approving it.

Idgit/changed-lines-budget
Versionv1
Categorygit
Default severityinfo
Interpreterpython3
Timeout30 seconds
Violations tolerated0
Collectsgit

Collectors

This guardrail gathers nothing itself. It depends on the collectors below, which the CLI runs once per build before any check, and reads what they found out of GUARDRAIL_FACTS. A collector that collects nothing skips this guardrail rather than failing it.

CollectorGathersInputs it is given
gitThe repository, HEAD, the remotes, and every commit between the base ref and HEAD with its message, author, parents, and the files the range changed with the lines it added and removed to each.baseRef

The inputs above are this guardrail's own, passed straight through. Configuring one in buildnote.json changes what is collected, and two guardrails configured the same way share the one collection.

Configuration

json
{
  "guardrails": {
      "failOn": "error",
      "checks": [
          {
              "use": "git/changed-lines-budget@v1",
              "severity": "info",
              "with": {
                  "baseRef": "origin/main",
                  "maxLines": "500",
                  "ignore": ""
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

InputDescriptionDefaultEnvironment variable
baseRefRef the range starts at. The commits checked are <baseRef>..HEAD.origin/mainGUARDRAIL_INPUT_BASEREF
maxLinesMost lines the range may add and remove together.500GUARDRAIL_INPUT_MAXLINES
ignoreComma separated globs excluded from the count, for generated files and lock files a reviewer does not read line by line.``GUARDRAIL_INPUT_IGNORE

How to fix

Split the change, or land it as a stack of pull requests each small enough to be read. Review quality falls off sharply with the number of lines put in front of a reviewer, and an approval on a change nobody could read is a control that exists on paper only.

Where the lines are unavoidable — a generated file, a lock file, a formatting pass, a mass rename — name those paths in ignore so the ones a reviewer reads are what is counted, or raise maxLines for that run rather than removing the guardrail, so the exception is visible.

Binary files carry no line count and are not counted.

More in git

  • git/author-identity-domain. Every commit in the build range was authored and committed by an address on a domain the organisation controls.
  • git/changed-files-budget. The build range changes few enough files that a reviewer can hold the whole change in their head.
  • git/conventional-commits. Every commit message in the build range follows the Conventional Commits specification: the subject line, the blank line before the body, and the BREAKING CHANGE footer.
  • git/no-merge-commits. The build range contains no merge commits.
  • git/no-wip-commits. The build range carries no commit that says it was never meant to be merged.
  • git/work-item-reference. Every commit in the build range, or the branch it is on, names the change record it belongs to.

All 7 git guardrails

Buildnote Limited
Registered in England and Wales, Reg: 16140412