Guardrails / git

Commits follow Conventional Commits

git/conventional-commits@v1

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.

Id	git/conventional-commits
Version	v1
Category	git
Default severity	error
Interpreter	python3
Timeout	60 seconds
Violations tolerated	0
Collects	git

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.

Collector	Gathers	Inputs it is given
git	The 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

{
  "guardrails": {
      "failOn": "error",
      "checks": [
          {
              "use": "git/conventional-commits@v1",
              "severity": "error",
              "with": {
                  "baseRef": "origin/main",
                  "types": "feat|fix|chore|refactor|test|docs|build|ci|perf|style|revert"
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

Input	Description	Default	Environment variable
baseRef	Ref the range starts at. The commits checked are <baseRef>..HEAD.	origin/main	GUARDRAIL_INPUT_BASEREF
types	Types accepted before the colon, as a regular expression alternation.	feat|fix|chore|refactor|test|docs|build|ci|perf|style|revert	GUARDRAIL_INPUT_TYPES

How to fix

Rewrite each offending commit message as type(scope): description, for example fix(api): reject expired tokens. The scope is optional, but if you give one it must name something. A ! before the colon marks a breaking change, and the colon is followed by a space and a description. The body starts after one blank line, and a breaking change described in the footer is written as BREAKING CHANGE: <description>, in uppercase. See the Conventional Commits specification.

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/changed-lines-budget. The build range adds and removes few enough lines that a reviewer can read the whole change before approving it.
• 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