Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow multiple instances of the same rule #113

Closed
jorisroovers opened this issue Nov 27, 2019 · 1 comment
Closed

Allow multiple instances of the same rule #113

jorisroovers opened this issue Nov 27, 2019 · 1 comment
Labels
enhancement User-facing feature enhancements
Milestone
0.14.0

Comments

@jorisroovers
Copy link
Owner

jorisroovers commented Nov 27, 2019 •
edited
Loading

We should allow multiple instances of the same rule to be active at the same time.

This would properly solve use-cases like the one described in #66.

The way I think we can incorporate this in the current codebase and way of configuring gitlint, is by allowing users to optionally specify a unique rule identifier, like so:

[title-must-not-contain-word:my-rule-identifier]
words=hello,bye

[title-must-not-contain-word:extra-words]
words=foo,bar

Note that it's up to the user to make sure they don't create conflicting rules.

I've already created an experimental implementation of this in the multiple-rule-instances branch and it seems to work.
However, I don't really like the way that implementation complicates the code-base - it's hacky.

Instead, I think we should properly introduce the concepts of RuleCollection, RuleInstance (=a unique instantiation of a rule class) and RuleQualifier (=rule class id + rule instance id).

This issue will be used to track ongoing work related to this. As always, no specific timelines :-)
@jorisroovers jorisroovers added the enhancement User-facing feature enhancements label Nov 27, 2019
jorisroovers added a commit that referenced this issue Nov 27, 2019
@jorisroovers
RuleCollection to manage active rules
233fa4c 
Rules are now managed by the `RuleCollection` class instead of by `LintConfig`
directly. This provides a cleaner seperation of concerns and provides
part of the basis for future work related to supporting multiple
rule instances.

This relates to #113.
@jorisroovers jorisroovers mentioned this issue Apr 1, 2020
Closed
jorisroovers added a commit that referenced this issue Sep 25, 2020
@jorisroovers
Named Rules
0a3ffaf 
Named rules allow users to have multiple of the same rules active at the same
time, which allows them to enforce the same rule multiple times but with
different options.

Implements #113
Relates to #66
@jorisroovers jorisroovers mentioned this issue Sep 25, 2020
Merged
jorisroovers added a commit that referenced this issue Sep 25, 2020
@jorisroovers
Named Rules (#150)
7beb266 
Named rules allow users to have multiple of the same rules active at the same
time, which allows them to enforce the same rule multiple times but with
different options.

Implements #113
Relates to #66
@jorisroovers jorisroovers added this to the 0.14.0 milestone Oct 6, 2020
@jorisroovers
Copy link
Owner Author

Will be released as part of 0.14.0

jorisroovers added a commit that referenced this issue Oct 24, 2020
@jorisroovers
0.14.0 release
c359748 
- IMPORTANT: Gitlint 0.14.x will be the last gitlint release to support Python
  2.7 and Python 3.5, as both are EOL which makes it difficult to keep
  supporting them.
- Python 3.9 support
- New Rule: title-min-length enforces a minimum length on titles
  (default: 5 chars) (#138)
- New Rule: body-match-regex allows users to enforce that the commit-msg body
  matches a given regex (#130)
- New Rule: ignore-body-lines allows users to ignore parts of a commit by
  matching a regex against the lines in a commit message body (#126)
- Named Rules allow users to have multiple instances of the same rule active at
  the same time. This is useful when you want to enforce the same rule multiple
  times but with different options (#113, #66)
- User-defined Configuration Rules allow users to dynamically change gitlint's
  configuration and/or the commit before any other rules are applied.
- The commit-msg hook has been re-written in Python (it contained a lot of
  Bash before), fixing a number of platform specific issues. Existing users
  will need to reinstall their hooks
  (gitlint uninstall-hook; gitlint install-hook) to make use of this.
- Most general options can now be set through environment variables (e.g. set
  the general.ignore option via GITLINT_IGNORE=T1,T2). The list of available
  environment variables can be found in the configuration documentation.
- Users can now use self.log.debug("my message") for debugging purposes in
  their user-defined rules. Debug messages will show up when running
  gitlint --debug.
- Breaking: User-defined rule id's can no longer start with 'I', as those are
  reserved for built-in gitlint ignore rules.
- New RegexOption rule option type for use in user-defined rules. By using the
  RegexOption, regular expressions are pre-validated at gitlint startup and
  compiled only once which is much more efficient when linting multiple commits.
- Bugfixes:
 - Improved UTF-8 fallback on Windows (ongoing - #96)
 - Windows users can now use the 'edit' function of the commit-msg hook (#94)
 - Doc update: Users should use --ulimit nofile=1024 when invoking gitlint
   using Docker (#129)
 - The commit-msg hook was broken in Ubuntu's gitlint package due to a
   python/python3 mismatch (#127)
 - Better error message when no git username is set (#149)
 - Options can now actually be set to None (from code) to make them optional.
 - Ignore rules no longer have "None" as default regex, but an empty regex -
   effectively disabling them by default (as intended).
- Contrib Rules:
 - Added 'ci' and 'build' to conventional commit types (#135)
- Under-the-hood: minor performance improvements (removed some unnecessary
  regex matching), test improvements, improved debug logging, CI runs on pull
  requests, PR request template.

Full Release details in CHANGELOG.md.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement User-facing feature enhancements
Projects
None yet
Milestone
0.14.0
Development

No branches or pull requests
1 participant
@jorisroovers