Skip to content

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 doesn't gather anything itself. It relies on the collectors below, which the CLI runs once per build before any check, and reads what they found from GUARDRAIL_FACTS. If a collector collects nothing, this guardrail is skipped, not failed.

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 inputs, passed straight through to the collector. Setting one in buildnote.json changes what is collected, and two guardrails configured the same way share a single 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
maxLinesMaximum number of lines the range may add and remove combined.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 that are each small enough to read. Review quality drops sharply as more lines are put in front of a reviewer, and an approval on a change nobody could read makes review a control that exists on paper only.

If the lines are unavoidable (a generated file, a lock file, a formatting pass or a mass rename), list those paths in ignore so only the lines a reviewer reads are counted. Otherwise, raise maxLines for that run instead of removing the guardrail, so the exception stays visible.

Binary files have no line count and are not counted.

More in git ​

  • git/author-identity-domain. Every commit in the build range was authored and committed with an email address on a domain your 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, including 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 contains no commit whose subject says it was never meant to be merged.
  • git/work-item-reference. Every commit in the build range, or the branch it is on, references the change record it belongs to.

All 7 git guardrails

Buildnote Limited
Registered in England and Wales, Reg: 16140412