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,CommitRuleorConfigurationRule - Rule classes must have
idandnamestring attributes. Theoptions_specis optional, but if set, it must be a list of gitlint Options. CommitRuleandLineRuleclasses must have avalidatemethod.- In case of a
CommitRule,validatemust take a singlecommitparameter. - In case of
LineRule,validatemust takelineandcommitas first and second parameters. ConfigurationRuleclasses must have anapplymethod that takeconfigandcommitas first and second parameters.- LineRule classes must have a
targetclass attributes that is set to eitherCommitMessageTitleorCommitMessageBody. - User Rule id's cannot start with
R,T,B,MorIas 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-pathis a directory, it does not need to be a proper python package, i.e. it doesn't require an__init__.pyfile. - Python files containing user-defined rules must have a
.pyextension. Files with a different extension will be ignored. - The
extra-pathwill be searched non-recursively, i.e. all rule classes must be present at the top levelextra-pathdirectory. - User rule classes must be defined in the modules that are part of
extra-path, rules that are imported from outside theextra-pathwill be ignored.