Issues

​

The Issues Tab

​

Category-wise issue distribution

On the left-hand side, you’ll find a breakdown of all issues by category, and the ‘Recommended’ tab displays the most critical issues that require immediate attention.

In the main section, individual issues are listed on cards that display their titles, categories, and total occurrences within the repository. You can filter this list by category or analyzer to focus on specific issues.

​

Sorting Issues

You can sort the order of the displayed issues with the following options:

• Most frequent: Sort in decreasing order of the number of occurrences of an issue (issues with the most occurrences appear first).
• Least frequent: Sort in increasing order of the number of occurrences of an issue (issues with the least occurrences appear first).
• First seen: Show the oldest detected issues first.
• Last seen: Show the newly detected issues first.

​

Autofix™

With Autofix™, you can quickly generate fixes for hundreds of code health issues across all files in your repository and apply them as a new pull request or commit to an existing one with just a few clicks.

When you open an issue from the dashboard that has Autofix™ support, you’ll see the Autofix™ button at the top. Click on it and select the files you want to apply Autofix™ to.

DeepSource will then generate the fixes, which typically take a few seconds. Once you’ve verified the fixes, simply click the ‘Create pull request’ button, and DeepSource will automatically create a pull request for the issue’s fixes in your repository.

​

Filter by Autofix™

Instead of looking around for issues that have an Autofix™ available, you can directly filter them out by selecting the Filter by Autofix™ option. While it’s active, it’ll have a green indicator.

​

Searching for issues

If you have a particular issue in mind to fix, finding it quickly using the Search bar is your best option. The Search bar can be used to look for specific issues based on keywords from the issue title, or some code present in the issue.

​

The Issue occurrence page

The Issue Occurrence page displays all occurrences of a selected issue in the codebase and provides contextual code to help understand it. Clicking on any issue directs you to this page. On the right, you’ll find a detailed description of the issue, which is particularly helpful if you haven’t encountered it before and need guidance on how to resolve it.

​

Ignoring issues

There can be several reasons why you would want to ignore an issue and prevent it from popping in the Issues tab after every analysis. Some of the obvious reasons are:

• The issue is intentional or irrelevant
• The team don’t want to fix the issue in the immediate future
• The issue is a false-positive

Here are the ways to ignore an issue:

​

Ignore issues in file(s)

• On the issue occurrence page, click on the ‘Ignore this issue’ button on the top right corner.

• You’ll see the three options for ignoring an issue:

  • For a file pattern: You would want to ignore an issue for files that match a pattern: say you don’t care about documentation issues in an internal package — all files matching contrib/utils/*.py. You can now ignore the issue for a specific pattern by clicking Ignore this issue → For a file pattern, and then entering the file pattern. All occurrences of this issue that match the file pattern provided will be removed, and the rule will take into effect from the subsequent analysis.

    • For all test files: If the test patterns are specified in the .deepsource.toml file, DeepSource will use this information to filter out a number of issues that don’t make sense in test files, but do so in the application code. You can ignore an issue for all the test files in the repository. Click Ignore this issue → For all test files This will remove all occurrences of an issue in the specified test files. If there are no test patterns specified in the .deepsource.toml file, you’ll get a prompt that tells you no test patterns are defined in the repository’s deepsource.toml.
    • For all files: If you decide you don’t particularly care about an issue, you can ignore it for all files in the repository. Click Ignore this issue → For all files. This will remove all occurrences of an issue in the repository, and ignore the issue from the subsequent analysis.

​

Ignore an occurrence of an issue

On the issue description page, click on the ban button on the top right corner of a particular occurrence of an issue. You’ll see the following menu:

• You can ignore a particular occurrence of an issue if you think that is intentional. To permanently silence an issue, you can use skipcq rule, read more about it below.
• Ignore an issue if you think it is a false-positive.
• If there are multiple occurrences of an issue in a file that you want to ignore, you choose the last option to ignore all the occurrences.

​

False-positives

A false-positive is an issue detected by DeepSource that is simply invalid or incorrect. False-positive issues are detected due to the flawed detection logic. In most cases, if an issue is flagged incorrectly, it’s because of the limitations of the analyzer. If you come across one in your codebase, you should report it. This will remove the occurrence of that issue, and also notify our engineering team, who can incorporate this feedback into making analyzers more reliable, and less noisy.

​

Reporting a false-positive

If you believe you’ve come across a false-positive, you can report it directly from the dashboard:

• To ignore a particular occurrence of an issue, click on the ban button on the top right corner of that occurrence and select ‘This is a false-positive’ from the menu.

• A pop-up window appears with a text box where you have to option to enter the details about the false-positive; click on the ‘Confirm and ignore’ button to submit the report.

​

Ignore issues

Although we make every effort to minimize false positives in our code analyses, there may still be instances where it is necessary to permanently ignore certain issues.

For example, there may be a function that has arguments that are not used anywhere in the function.

def return_as_is(param, an_unused_param):
    return param

This will raise the issue Unused argument, with DeepSource issue code PYL-W0613. However, if the extra argument exists for the sole purpose of API consistency, it is better to ignore this issue. In order to silence this issue permanently in code, use the skipcq: keyword.

def return_as_is(param, an_unused_param):  # skipcq: PYL-W0613
    return param

​

Silencing a specific issue

Add skipcq: as a comment with the issue’s short-code at the end of the line, or on the line above it to silence the issue.

input = 10  # skipcq: PYL-W0622

# skipcq: PYL-W0622
input = 10

​

Silencing multiple issues

To silence multiple issues on a line, add a comma separated list of issue short-codes after the skipcq: keyword.

def function(input, an_argument_not_used):  # skipcq: PYL-W0622, PYL-W0613
    pass

# skipcq: PYL-W0622, PYL-W0613
def function(input, an_argument_not_used):
    pass

​

Silencing all issues on a line

To silence all issues that could be raised on a line, use the keyword skipcq in the comment corresponding to the line.

except Exception:  # skipcq
    pass

# skipcq
except Exception:
    pass

​

In conjunction with existing comments

Add skipcq at the end of the comment for the line.

class Klass:
    def __init__(self):
        pass

    def func(self, x):  # This function does not use `self`. Hence an issue will be raised. Lets ignore it. skipcq
        return x ** 2

If the skipcq comment is placed above the line, place as many comments or newlines between the skipcq keyword and the concerned line as needed.

class Klass:
    def __init__(self):
        pass

    # skipcq
    # This function does not use `self`.
    # Hence an issue will be raised. Lets ignore it.
    def func(self, x):
        return x ** 2

​

Universality

While all the examples above are for Python, the skipcq keyword can be used for all analyzers.

This is the general format:

a line of code that raises an issue <comment identifier> skipcq: <issue code 1>, <issue code 2>

For example, to silence an issue on a line of Go code:

x := true
// The next line will raise an issue stating that negating a boolean twice is pointless.
// But we want to keep it, and not have any issues raised by DeepSource. Hence, `skipcq`
y := !!y // skipcq: SSC-SA4010