Hi,
We have more than 300 microservices projects with differents profiles. We would like to set these profiles by configuration. Since the sonar.profile is deprecated, what solution do we have ?
Thanks
PS : we use Sonar 5.6.7
Hi,
You should be able to use web services, api/qualityprofiles/add_project will do the job.
Regards.
Hi,
So it means to replace fully sonar.profile, we have to create a task somewhere to update dynamically the profile associated to a project. It’s seriously too complex for a such simple request.
I met exactly the same issue but with branches. It was so easy to just put in your build.xml or pom.xml the name of the profile. Why depreciate this property?
A nice replacement would be to add the possibility to associate dynamically a project to a profile according to its key (like permission).
1 Like
Hi,
Imagine you have a project that uses 4 different languages. Which language should sonar.profile=foo apply to? All of them? What if there’s not a foo profile for one of the languages?
And that’s why the parameter is deprecated; because it’s not such a simple request.
Ann
Hi,
No it’s a project only in Java. The point is we create a new project for each new branch. But each team can have a different profile. So if set the default profile for Team 1, Team 2 profile will be wrong for each new branch.
The solution is already implemented for the the security settings. According to the key you can give dynamically rights to an user. I expect the same behavior for the default profile. A default profile per key.
If you ask why we don’t use the branch plugin. The answer is simple: last time we tried it, code coverage was not available for short branches. It’s a no go for us.
Hi,
Well, sonar.profile is only deprecated, so it still works. However, it’s been deprecated for nearly four years, so…
Also, I should point out that you can provision a project and then configure it before the first analysis.
Ann
So you don’t have any date where sonar.profile will be removed? In such case, indeed we can consider to use it.
I personally feel it’s long past time to remove it, but there’s no real impetus. It’s not blocking or breaking anything AFAIK. That said, it is deprecated, so it could go away in any future version. There have been four years and counting of “warning”.
Ann
Tetienne,
If you want coverage information and are already creating new projects per branch… why not just use the branch plugin but use long-lived branches rather than short lived?
Outcome is the same: one time sync of issues (which you must get with a new project) but also coverage metrics.
Colin
1 Like