-
Notifications
You must be signed in to change notification settings - Fork 100
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.
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
Add support for multiple ignore-* rules in configuration file #66
Comments
Hi, thanks for your interest! It's actually both a limitation of the ini format as well as the way gitlint handles rules: it can only have a single instance of each rule configured. I believe that makes sense, because you can't have e.g. 2 different title-max-length rules defined without causing ambiguity. I actually did think about your case when writing the ignore-by-* rules in the last gitlint release, but wanted to keep things simple at the time since it was the first iteration. Also, I believe the simple (but somewhat bad-looking) workaround is to just write a more complex regex that includes all your simpler regexes: regex=((<regex1>) | (<regex2>) | ... | (regexN)) I considered making the regex=<regex1>,<regex2>,...,<regexN> But decided against it because you can't unambiguously parse that list (the commas might be part of the regex instead of the list-separators). Also, syntax-wise, this is almost the same as doing Long story short, I don't think supporting multiple of these rules is a quick fix, so if possible I'd recommend going with my suggestions above. I might look into this in the future, but as often, it might take me a few or more months (this is a hobby project and I tend to work on it for a few days about 2-3 times a year). |
Thank you for your quick answer @jorisroovers! I came to the same conclusion and used a more complex regex. But doing so exclude the possibility to ignore a specific rule for a particular regexp: we are constrained to ignore an aggregation of all rules we want to ignore. As I am using YAML a lot these days, I think switching the configuration to this file format would add more flexibility. But it's a huge refactoring... |
Unfortunately YAML alone wouldn't fix this, it also has to do with how gitlint stores rules internally (only 1 instance of each rule can be active at once). I don't think we necessarily need to support multiple of the same rules though. For example: [ignore-by-title]
regex1=<regex1>
ignore1=title-max-length,body-min-length
regex2=<regex2>
ignore2=all While I agree that we YAML would allow us to do this using nicer syntax, I think these number-based For backwards compatibility we'd just internally map Interested to hear your thoughts :-) (Again, probably won't actually work on this for a while, but definitely something I'll consider doing at some point.) |
True, that why I've said that it would be deep refactoring. I like your proposal, let's do this! Nothing hurries, let's keep in touch and keep up the good work! 💪 |
2+ years later... I just implemented 'Named Rules' which allows users to have multiple of the same rule active at the same time, like so: # .gitlint file
[ignore-by-title:first-instance]
regex=(.*)ignore(.*)
ignore=all
[ignore-by-title:second-instance]
regex=(.*)foobar(.*)
ignore=B6
[ignore-by-title:thisCanReallyBeWhateverYouWant]
regex=(.*)hurdur(.*)
ignore=T2,T3 Of course it's possible to create conflicting rules this way, but that's up to the user to make sure that doesn't happen. This should solve this use-case :) This will go out as part of 0.14, somewhere in next few weeks. |
- 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.
Hi there 👋 Thank you for providing this amazing project to the community!
I recently stumbled upon a disturbing issue: we cannot define multiple
ignore-by-title
sections in the.gitlint
configuration. It means that I cannot define different rules to ignore given a particular regex.Did I missed something?
Is this a limitation of the ini/cfg format?
The text was updated successfully, but these errors were encountered: