I have to uncouple my project lifecycle of sonarqube server lifecycle. Both have long cycle that can interfere. A typical use case is that QA of a version of my project lasts several months. During this period, I need to manage in configuration the tools I use for the qualification. Due to safety critical constrains, any change need a full QA, that is to say several months.
So, I need to master/fix the result of an analysis even if anything changes on the sonarqube server that is managed by IT team.
I know that we can use a copy of sonar way quality profile. That’s do a great part of the job. With that we can choose when to change the set of rules.
But we still have the risk that a new version of a plugin language detects an issue that the previous one do not see.
So, is it possible to choose the plugin language version when I launch the scan ?
Welcome to the community!
It’s not possible to do what you’re after. Language analysis is embedded in SonarQube and the only “version” available is the one that comes distributed with SonarQube.
In a safety-critical system it seems like this would be a benefit…? I understand that it would mess up your record keeping, but isn’t finding and fixing more subtle problems a good thing?
I have not used SonarQube in years, since we are using SonarCloud nowadays, so my knowledge might be outdated. The plugins are part of the server itself so the versions need to be consistent between the server and the runners. As long as SonarQube and the plugins stay the same on the server side, the analysis will stay consistent.
In your case you might have to only upgrade when your lifecycle is complete.
On the other hand I have to agree with @ganncamp that if your are concerned about security you should not avoid being notified of improved security analysis. This is how companies like Western Digital or Casey end up with disastrous results.
Our org is ISO and SOCK 2 certified and our security analysis toolchains are not under high level of scrutiny. Maybe if you were using SonarCloud where you just provide the vendor and where you can show the auditors you have no control over version, that would work better for you?
Thank you for your reply Ann and Stephane even it doesn’t fit the use I described.
I also agree that finding more issues is better.
Let’s try to change our clients way of working and explain them that’s finding bugs is better than masking eyes with the hands refusing to see the existing code and its potential bugs ;).