This is a suggestion for the “ignore rules” section – the screen that shows which rules should be ignored for which files. Currently, the page shows the rule being ignored and the affected files. It would be helpful to show the actual affected source code. Without seeing the code, it’s difficult to evaluate whether the rule is being ignored legitimately.
It will also be helpful to see the affected files, for rules that apply to more than one file, and, for a specific rule, the count for each file (how many times the rule is being ignored).
The above information would be helpful in evaluating whether the ignore rule is valid, and whether its scope is appropriate.
The use case is: one of our user’s team member has gone through the entire code base and resolved the warnings reported by DeepSource (originally, there were over a thousand). They resolved them either by fixing the problem in the source code, or by adding an ignore rule. The maintainer’s job now is to go through the ignore rules and review them: make sure they aren’t sweeping anything serious under the rug. With the current UI, that’s hard to do, because it does not give them enough information to make a good decision.
The ignored rules have context about the scope already. We have four kinds of ignored rules at the moment:
Ignored for the entire repository: This is a blanket rule to effectively prevent an issue from being reported at all across the repository.
Ignored for all test files: This prevents an issue from being reported in the test files, as declared in the test_patterns property in the configuration file.
Ignored for a specific file pattern: This prevents an issue from being reported in all files matching a particular glob pattern.
Ignored for a particular file: This prevents an issue from being reported in a particular file.
The user’s problem in question can be potentially solved in two parts:
For cases 1 and 3 above, the files affected are already obvious or explicitly stated in the UI. We can show the affected files in cases 2 and 3. This information is enough for the maintainer to triage whether the issue is valid or not.
The suggestion for showing the code’s context is not feasible because there can potentially be an arbitrary number of occurrences matching a particular rule, and it would be impractical for the user to make use of such a list in any way.
In the upcoming role-based access control (RBAC) release, the ability to ignore rules by creating ignore rules from DeepSource’s dashboard can be restricted so that the maintainers can grant this permission to only trusted people. This is similar to the “Maintainer” user permission on GitHub — which allows a user to take administrative / potentially destructive actions.