Skip to content

Latest commit

 

History

History
45 lines (30 loc) · 2.81 KB

metadata.adoc

File metadata and controls

45 lines (30 loc) · 2.81 KB
Raw

Rule Metadata

This document describes how metadata.json should be structured.

title, type, tags, remediation, and defaultSeverity

These fields are described in the SonarQube documentation.

quickfix field

Every active rule that is not a security hotspot must specify the availability of a quick fix for its issues. metadata.json must feature a quickfix field with one of the following values:

  • unknown: the feasibility of producing a quick fix is not evaluated.

  • infeasible: it is not feasible to propose a quick fix for any of the issues, for whatever reason.

  • targeted: it is possible to implement quick fixes for this rule, but none are implemented right now.

  • partial: some of the issues produced by the rule propose a quick fix, but not all.

  • covered: all the issues produced by the rule propose a quick fix.

ℹ️

A covered rule is still not guaranteed to provide a quick fix for a particular issue (for instance, if a fix location would be inside a macro expansion or in a different file from the issue location). The rule is said to have a partial quick fix only if there exists a family of issues that cannot have a quick fix.

For instance, on one hand, if a rule detects two functions that are dangerous to use, A and B, and A has an obvious replacement (and therefore a quick fix) while B does not, the field should be set to partial.

On the other hand, if a quick fix could be easily proposed for both A and B, but the fix location might be inside a macro expansion, or in a different file from the issue location (and hence not feasible given the current SonarLint capabilities), this should not prevent the rule from being tagged as covered.
💡

You can update the quickfix field using this GitHub Workflow: https://github.com/SonarSource/rspec/actions/workflows/update_quickfix_status.yml

code field

The code field is an object that contains information related to the clean code taxonomy. It is an object with two required properties:

  • impacts: A nested object that is treated as a mapping from a software quality to a level ("INFO", "LOW", "MEDIUM", "HIGH" or "BLOCKER"). Note that at least one software quality has to be specified. The current list of allowed software qualities is "MAINTAINABILITY", "RELIABILITY" and "SECURITY".

  • attribute: A single clean code attribute that the rule aims to achieve. This has to be one of the following values: "FORMATTED", "CONVENTIONAL", "IDENTIFIABLE", "CLEAR", "LOGICAL", "COMPLETE", "EFFICIENT", "FOCUSED", "DISTINCT", "MODULAR", "TESTED", "LAWFUL", "TRUSTWORTHY", "RESPECTFUL".