Is it possible to add "eco-conception" tag on existing built-in rules ? about ecocode HOT 6 OPEN

check if possible to add tag ("eco-conception" for example) to an existing rule

• Sonar web site : yes possible. to do that : go to a specific rule page, click on down arrow near existing tag, next chose new tag and click on checkbox
• Programmatically :
  • question on Sonar Community : https://community.sonarsource.com/t/add-tag-to-built-in-rule-within-a-custom-plugin/75122
  • ideas :
    • https://stackoverflow.com/questions/39486244/how-to-get-rules-and-their-params-with-value-sonarqube-plugin-api
    • https://www.bitegarden.com/sonarqube-project-tag
    • https://stackoverflow.com/questions/47555745/is-there-a-way-to-pass-tags-to-sonarqube-via-maven-command-line
    • https://community.sonarsource.com/t/adding-tags-to-a-project-via-analysis-properties/3985/20
    • https://stackoverflow.com/questions/36918526/is-it-possible-to-update-add-a-tag-to-a-sonarqube-rule-or-issue-from-within-a-pl

check if possible to change severity of an existing rule

• Sonar web site : yes possible. to do that : we have to create a new profile inherited from default "sonar way" profile and then on specific rule page, wh can change severity
• Programmatically : TODO DDC

from ecocode.

Hi,

it's actually what i'm doing on my sonarqube server.
I create new profile "green" for each language. It can be exported as xml file. Other team using other sonarqube can import this custom profile.
BUT , if if there is new rule on sonarqube (because you have done update sonarqube), you have to update the profile.

One solution, i was thinking to do a script using API to create from scratch the profile (and update it?).
Sonarsource uses scripts ps1 to solve this kind of issue.

Modify severity is another feature with low value. Not sure have to be done.

from ecocode.

Hi @Silicoman ,
thank you for ideas.

indeed, in Sonarqube community forum (please see question link above), the SonarQube community manager gave us this answer also.
For me, this is not an optimized solution, because after plugin installation, we must execute a batch to initialize the environment. This is a possible solution but not the "top" solution for me. If the plugin do it automatically, it's better.

I agree with you regarding "severity modification" : maybe an other subject.
But, the purpose of this issue is to test possibles automatics actions that the plugin could do.
After that, we will discuss internally if we do them or not.

regards.

from ecocode.

After discussion with Sonar source developers, here are their answers :

First answer (from SonarQube community manager) :
Hey there. Are you sure a custom plugin is the right way to go, rather than using the Web API (documentation linked in the footer of your instance).

Second answer (from SonarQube developer) :
Hi, this doesn’t seem to be achievable with current Plugin API. You can do what you want with the rules your plugin define but not with the rules other plugins define. The work-around would be to call SonarQube Web API from inside your plugin, to achieve what you want, but this doesn’t seem in general as a clean, good practice.

To conclude : the best practice is to use SonarQube API after installation of ecocode plugin.
To do this, we have to develop an installation process :

• 1/ install plugin into SonarQube
• 2/ call SonarQube Api to add ecoconception tag to all rules that we want (an internal list ?)

Question : do you have to create a new one profile (like @Silicoman example), or change default profile ?
According to me, creating a new profile isn't the best idea because one project could be only affected to only one profile and not several profiles. Thus, we can't at the same time and for one project, check several profiles (the personal profile and our ecoconeption profile)

from ecocode.

Hi @dedece35 ,

I think we should keep it simple at first, documenting the process to add ecoconception tag, and documenting how to add this tag in a new profile. That way users can create specific profile for ecocode or modify their custom profile.

An internal list all rules is a good idea, firstly based on performance rules on Sonar, and we could test it with ETSdiff when possible to keep good rules.

I am a bit frustrating too that we cannot automate the process, but a good documentation can do the job. And all users will not have the same configuration, with the same base rules set (depending on Sonar version).

from ecocode.

@MP-Aubay

good idea, I agree with you to keep simple in the first time and describe the process in documentation with different use cases.
I will work to complete documentation.

from ecocode.