Clarify the usage of RuboCop's generated and manual todo yaml
The following discussion from !49972 (merged) should be addressed:
-
@splattael started a discussion: (+1 comment) According to https://docs.gitlab.com/ee/development/contributing/style_guides.html#resolving-rubocop-exceptions and the added description of
.rubocop_manual_todo.yml
we would enable any👮 with offenses count > 15 - did I get it right?If so, should we then move all cops (with offenses > 15) into the
.rubocop_manual_todo.yml
then and enable them?🤔 (a genuine question)Ideally, we want to always enable new introduced cops, exclude current offenses (and fix them incrementally in follow-up MRs) to make sure ware not introducing new offenses. (Example !49770 (merged)).
Now, with these cops being disabled (
Enabled: false
) it seems we are not only not tracking the remaining offenses but also allowing new offenses to sneak into our codebase (see line 9). I think most cops in.rubocop_todo.yml
with a high amount of offenses are not really actionable😞 Moreover, I was wondering if we could create one rubocop YAML per rule (and include them into
.rubocop.yml
dynamically with ERB support) to minimize friction of a single file.
Not really, they are kind of already enabled if they have an offense exception list in
.rubocop_todo.yml
, else there would be no need to even deal with the exception list and the cop would be enabled. This only concerns itself about if the cop is enabled and offenses count > 15, then we'd put them in the manual file.The decision on whether or not to enable cops is outside of the scope here. We are only concerned with 'how do we work towards resolving exceptions for a cop that has a large exception list and still allow a general auto-generation of the todo file to work'
Moreover, I was wondering if we could create one rubocop YAML per rule (and include them into
.rubocop.yml
dynamically with ERB support) to minimize friction of a single file.There really shouldn't be too much friction in the
manual
todo file and ideally, git should be able to reconcile diffs in it fairly easily. I fear that if we do a file per cop, it could introduce a lot of noise - file wise.However, we could definitely iterate on that idea if you like as a follow-up?