Add support for multiple ignore-* rules in configuration file
See original GitHub issueHi 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?
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Ignore Rules - JFrog Documentation
Ignoring Violations Examples; Viewing Ignore Rules and Info; Deleting an Ignore Rule; Searching for Ignored Violations; REST API Support. Page ...
Read more >Add Ignore Rules - Trellix Product Documentation
Add Ignore Rules You can select a particular alert and configure an ignore rule. If necessary, you can create a new ignore rule...
Read more >Configuration Files - ESLint - Pluggable JavaScript Linter
ESLint supports adding shared settings into configuration files. Plugins use settings to specify the information that should be shared across all of its...
Read more >Configuration | Stylelint
The .stylelintrc file (without extension) can be in JSON or YAML format. You can add a ... Each rule configuration fits one of...
Read more >Ignoring files, folders, or code - Semgrep
To ignore blocks of code for a particular rule, enter its rule-id as follows: nosemgrep: RULE_ID . To ignore multiple rules, use a...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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:
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.
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! 💪