Improve "Granular" Setting / Possibility to pin a Deepsource version

Feature Requests
1

Hi.

IISC the current status of DS is that once new checks are added, or existing ones are extended/improved, this behavior is rolled out directly to all new checks. I had a few PRs, where this lead to the DS check failing b/c it reported issues that

  • weren’t a direct cause of the changed lines
  • hadn’t been reported before

Note that the “Granular” setting is supposed to prevent this, but apparently this doesn’t always work. Here is an example, where DS reports issues for the ClassName.check_update method, while the PR only changed the docstring of the class. A similar case in the same PR is here.

It would be nice, if the “granular” setting would be improved.

Additionally, I would find it desirable to be able to pin a specific DS version (eg via .deepsource.toml#version), which prevents new changes in the DS system to apply directly. This would

  1. help eliminate many of the above issues
  2. allow devs to apply new issue-fixes concisely to the whole code base by bumping the version & addressing revealed changes - instead of discovering them bit by bit in each PR.

Looking forward to your feedback :slight_smile:

2 Likes
2

Thanks for your feedback, @Bibo-Joshi!

When we add new checks to an analyzer or improve existing checks to fix false positives, they’re immediately rolled out to all new analysis runs. I understand how this can be undesirable if you have long-standing PRs and new issues popping up after a new commit is made. We can probably refine the behavior to avoid reporting new issues if they’re not strictly in the changeset.

The config file version field isn’t intended for this, but I understand how a “versioning” mechanism could help. In principle, we’d like to solve this implicitly without you having to change any versions.

I’ve noted your feedback internally, and I’ll get back with more details in this thread once we have triaged this and have an action item. :raised_hands:t3:

1 Like