autonomousapps / autonomousapps/gradle-best-practices-plugin
[Feature Request] Add different Severity levels to issues
- Dominant language
- Kotlin
- Stars
- 197
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
Right now, the plugin treats all issues equally, which means we can't add issues that should be surfaced as warnings instead of errors.
My current thinking is to create a `Severity` enum that gets added as a required field to the `Issue` sealed type. Seeing as some best practices can have use-cases where they don't necessarily apply, and in the spirit of treating them as guidelines as opposed to strict rules, maybe that severity should have a default value of `Warning`, and issue authors can override that when contributing new ones.
The `ConfigurableLogger` class would also need to be made aware of this change, and _maybe_ the surfaced warning messages would need to be slightly reworded to reflect this severity level and make users aware of the fact that they can add specific issues to their baseline given that they have appropriate reasons for breaking tradition at call sites where a guideline doesn't apply. Maybe this is a slippery slope though? I don't know.
Contributor guide
Research direction
Start by reading the Issue sealed type and ConfigurableLogger to map how issues are represented and surfaced today. Decide the intended severity defaults and override behavior before changing the model, then verify that errors and warnings are clearly distinguished and that existing issue handling remains consistent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100