Issues

A repository's Issues tab lists all of the issues that Quality has found in your default branch. Issues are listed in descending order of remediation time, and can be filtered by Category, Plugin, Severity, and Source.

Clicking on the link below an issue will take you to the Code tab for that file, where you can drill down into the details for the specific issue.

Issue Statuses

In some cases, an issue that Quality identifies can benefit from additional, manual assessment to confirm its validity. For these cases, Quality allows developers to mark any issue with one of 3 different statuses (Confirmed, Invalid, Wontfix) as well as restoring the default status (Open or New).

If Quality's GitHub PR status integration is enabled, marking a new issue as Invalid or Wontfix means the issue will not count toward the new issue count on the pull request, and won't contribute to failing the status. Marking an issue as Confirmed or New (or leaving the default status of new) means the issue will result in a failing status. This allows developers to exercise their judgment into which issues should fail the Code Climate status of an open pull request.

The full list of statuses and their meanings is below.

Adding an issue status works the same way for existing (Open) issues as well as New issues. In this example, the pull request workflow is used.

After visiting the pull request page, hovering over an issue title reveals the issue status menu.

Clicking the issue status menu provides the list of available statuses. Here, "Wontfix" is selected.

An optional reason can be provided.

Once created, issue status details can be viewed by hovering over the status label. Details include who made the change, when the change was made, and, if provided, the change reason. In this example, the status of "Wontfix" caused the pull request state to update to "Passed."

📘

Pull Request Approvals

To restrict the ability of certain users to change an Issue's Status, check out our doc on PR Approvals.

Issue Severity

By default, each issue is given a severity (info, minor, major, critical, or blocker) describing the potential impact of the issue found. Issues with a severity of INFO will not fail a Pull Request. Issues of any other severity will fail a Pull Request.

Users can override the default severity levels for specific engines. For example, if you'd like to use the FIXME engine, but don't want FIXME issues to fail your pull requests, you can add the following snippet to your .codeclimate.yml:

plugins:
  fixme:
    enabled: true
    issue_override:
      severity: info

FIXME issues will be reported to Quality and shown on the pull request page, (as well as the Issues list), but won't cause your PRs to fail (i.e. "turn red").