Rule Specification
As long as you stick with simple rules that are similar to the sample user-defined rules (see the examples directory), gitlint should be able to discover and execute them. While clearly you can run any python code you want in your rules, you might run into some issues if you don't follow the conventions that gitlint requires.
While the rule finding source-code is the ultimate source of truth, here are some of the requirements that gitlint enforces.
Rule class requirements¶
- Rules must extend from
LineRule
,CommitRule
orConfigurationRule
- Rule classes must have
id
andname
string attributes. Theoptions_spec
is optional, but if set, it must be a list of gitlint Options. CommitRule
andLineRule
classes must have avalidate
method.- In case of a
CommitRule
,validate
must take a singlecommit
parameter. - In case of
LineRule
,validate
must takeline
andcommit
as first and second parameters. ConfigurationRule
classes must have anapply
method that takeconfig
andcommit
as first and second parameters.- LineRule classes must have a
target
class attributes that is set to eitherCommitMessageTitle
orCommitMessageBody
. - User Rule id's cannot start with
R
,T
,B
,M
orI
as these rule ids are reserved for gitlint itself. - Rules should have a case-insensitive unique id as only one rule can exist with a given id. While gitlint does not enforce this, having multiple rules with the same id might lead to unexpected or undeterministic behavior.
extra-path requirements¶
- If
extra-path
is a directory, it does not need to be a proper python package, i.e. it doesn't require an__init__.py
file. - Python files containing user-defined rules must have a
.py
extension. Files with a different extension will be ignored. - The
extra-path
will be searched non-recursively, i.e. all rule classes must be present at the top levelextra-path
directory. - User rule classes must be defined in the modules that are part of
extra-path
, rules that are imported from outside theextra-path
will be ignored.