SONARIAC-1892 Modify rule S6975: Fix how to fix it section split #4604
Conversation
|
|
| === Code examples | ||
|
|
||
| ==== Compliant solution |
There was a problem hiding this comment.
I think these missing titles is why the content is not displayed on the Sonar rules website (but is still somehow display everywhere else, the parsing logic must be different)
There was a problem hiding this comment.
It will be good to document in our Xtranet how to write rules. Especially, how it should be defined for IaC technologies that have 2 formats(json/bicep, json/yaml, yaml/properties).
| @@ -0,0 +1,53 @@ | |||
| == How to fix it in ARM Templates | |||
There was a problem hiding this comment.
I'm not sure if arm.json is a good name for the file as ARM is a name of technology. The suprorted languages are Bicep and JSON, so IMO the files should be rename to json.adoc
There was a problem hiding this comment.
Indeed! I followed the convention we were already using, I will update every other file then.
Should I also update the header? In Microsoft's documentation, ARM templates seem to imply that it's JSON, and Bicep is not defined as an ARM template, but the line seems blurry. I'd rename it "How to fix it in JSON Templates" (without mentioning ARM to keep it shorter; ARM is already implied by the rule language) and keep "How to fix it in Bicep."
What do you think?
| access: 'Allow' | ||
| protocol: '*' | ||
| destinationPortRange: '*' | ||
| sourceAddressPrefix: '*' |
There was a problem hiding this comment.
Consider adding Noncompliant comment.
See: https://github.com/SonarSource/rspec/blob/444c23805989cba3ebdd79d578388f8f6626f596/docs/description.adoc
noncompliant lines should always be highlighted with the corresponding comment “// Noncompliant” optionally followed by some explanation) if that is clearer
There was a problem hiding this comment.
It's kinda hard to add Noncompliant comments to both code examples you mentioned because it's actually a combination of multiple lines that makes it non-compliant. I'll look into it, see what's possible and how we're dealing with similar situations to be consistent 😉
| properties: { | ||
| permissions: [ | ||
| { | ||
| actions: ['*'] |
There was a problem hiding this comment.
Consider adding Noncompliant comment
| === Code examples | ||
|
|
||
| ==== Compliant solution |
There was a problem hiding this comment.
It will be good to document in our Xtranet how to write rules. Especially, how it should be defined for IaC technologies that have 2 formats(json/bicep, json/yaml, yaml/properties).
Review
A dedicated reviewer checked the rule description successfully for: