46 lines
2.8 KiB
Plaintext
46 lines
2.8 KiB
Plaintext
ifdef::env-github[]
|
|
:tip-caption: :bulb:
|
|
:note-caption: :information_source:
|
|
endif::[]
|
|
= Rule Metadata
|
|
|
|
This document describes how `+metadata.json+` should be structured.
|
|
|
|
== `title`, `type`, `tags`, `remediation`, and `defaultSeverity`
|
|
|
|
These fields are described in the https://docs.sonarqube.org/latest/extension-guide/adding-coding-rules/#coding-rule-guidelines[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.
|
|
|
|
[NOTE]
|
|
====
|
|
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`.
|
|
====
|
|
|
|
[TIP]
|
|
====
|
|
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 (`"LOW"`, `"MEDIUM"` or `"HIGH"`). 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"`.
|