Commits follow Conventional Commits
git/conventional-commits@v1
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.
| Id | git/conventional-commits |
| Version | v1 |
| Category | git |
| Default severity | error |
| Interpreter | python3 |
| Timeout | 60 seconds |
| Violations tolerated | 0 |
| Collects | git |
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.
| 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. | 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
{
"guardrails": {
"failOn": "error",
"comment": true,
"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 and must name something when it is given, a ! before the colon marks a breaking change, and the colon is followed by a space and a description. A body starts one blank line after the description, and a breaking change described in the footer is written 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 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/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.