I am currently using the Community Edition v 9.8.1 and it is deployed via the latest docker image (sonarsource/sonar-scanner-cli:latest). I hope within the near future I will be using the Developer Edition.
The goal I am trying to achieve is to provide code to SonarQube that would instruct it on which rules it should run for an analysis.
I understand Quality Profiles can be customized to run analysis using specific rules ahead of time. Is SonarQube capable of being told “we have these specific design practices that reflect these specific rules, use these rules during the scan”?
You’ll need to configure your profiles ahead of time and then either set them as the language defaults, or explicitly assign them to the projects of interest.
Would there be any chance to programmatically create projects and assign them to quality profiles by leveraging the SonarQube Web api? For example, use the api to create a new project, create a new Quality Profile and establish which rules are active, and then add the newly created project to the new custom QP?
Yes, you could certainly script this with the Web API. But surely you don’t want a profile-per-project?
And BTW, the best way to master the API is to perform the desired action via the UI and eavesdrop to see which calls the UI made to accomplish the action.
Ann,
Thank you for you for responding. I was able to find that guide in an earlier post and it has been very helpful. So thanks for sharing that as well.
After talking to our chief architect, best case scenario is we would have the ability to vary the Quality Profile by branch. This would be due to a variety of design practices that projects/branches would have to adhere to. I’m not entirely sure what you all at SonarQube believe is best practice for your product but I’m hoping there would be a possible solution to what we’re hoping to accomplish. I’m looking forward to you and your teams perspective on something like this.
SonarQube simply isn’t designed that way. Could you help us understand why you’d want to apply different criteria to a branch than to main?
Is this about monorepos?
If you really must do this (really? must you?) then you’ll have to do some heavy scripting:
job starts
block all other analyses of project branches / PRs
API call to update project’s Quality Profile
perform analysis…
receive webhook confirming analysis completion
API call to reset project’s Quality Profile(?)
unblock other analyses
I’ll be honest and say that I’m not sure that you would actually have to wait until you received the webhook before resetting the profile and unblocking other analyses. It’s not clear to me when the profile contents are pulled & applied - it’s never mattered before.
Good morning! I had a feeling that would be the type of response I would get. In this unique situation we were thinking that within a project, certain branches would have to adhere to different design practices (which is how we would determine the Quality Profile). But based on your response we won’t be doing this.
Would the profile-per-project approach be less complicated? Would it be an approach that wouldn’t steer too far away from SonarQube best practices? I’m new to working with SonarQube and have enjoyed learning about it’s capabilities so far, but understand the challenge of implementing an approach to achieve our teams goals.
Starting from a fairly generic goal of “write code that’s at least as good as the previous release and doesn’t introduce new bugs or vulnerabilities”… That’s what the Clean as You Code methodology is best at. The idea here is that you apply the same standards to everyone - both Quality Profiles* and Quality Gates**.
So you put everyone on the same Quality Gate, and everyone on the same Quality Profile. Or you create a base profile and allow teams to extend it by adding rules (like a rule about which line { goes on).
And then you hold everyone to the standard that new code is “clean” before it’s released.
In the end, it’s simple enough that the hard part is understanding - and convincing others - that that’s really all you need to do: make sure today’s commit is clean.
Does that seem like it will fit? Help?
Ann
* Making variances only when teams use different frameworks or conventions (which line { goes on is an easy example).
** Variances show up here when e.g. one team integrates with external systems and the code can’t be reasonably checked with unit tests.
It does… and I relayed that information to the appropriate channels. So now I’m just waiting to hear what the decision would be. I’m still trying to wrap my head around how all of it (particulars on my side of things) will come together. That way I feel I have a better understanding of how exactly we can leverage SonarQubes capabilities most effectively.
I still have a lot to learn and look into. I do appreciate your assistance. Once pieces start to fall into place I may reach out with additional questions if that’s okay.
I think I understand the reason the reasoning behind your answers in regards to the questions I had about Quality Profiles above. So I assumed one Quality Profile included all rules for all languages. I understand now that each language has it’s own Quality Profile (I think I overlooked this detail when looking at the docs).
So I just want to make sure, if we deactivate a rule for a particular language in a Quality Profile and then the scanner runs an analysis using that Quality Profile, only the rules that are active are used in the analysis. However, since the Quality Profiles for the other languages are say still set to default as the Sonar Way, those Profiles will also be used and those active rules will be included in the analysis?
I also understand that it is possible to also prevent specific rules from being applied to specific files by providing the appropriate parameters in the sonar-scanner.properties file?
I think I am finally starting to understand some of the finer details which is great. As always, I appreciate your time.
For each language there’s a default profile. Out of the box, it’s a built-in profile (there’s at least one for each language). But you can create all the profiles you like and set one of them as the default for a language. Note that build-in profiles aren’t editable, but they can be copied or extended.
And yes, rule activations are per-language. It’s common that a non-language-specific rule is implemented across many languages. In those cases, you can search the rules page by the rule key and find all the iterations. From there you can enable / disable as you like.
You can do it in the properties file, but it’s fiddly. Much cleaner to do it via the UI.
If the unwanted cases are few enough, it might be sufficient to simply mark the relevant issues Won’t Fix, again via the UI.
