Must-share information (formatted with Markdown):
which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
SonarQube Community Edition V7.7
SonarQube Scanner 220.127.116.112 or SonarQube Scanner 18.104.22.1687
what are you trying to achieve
I want to use the sonarqube quality gate to intercept code submissions that do not meet the requirements, so my project will run sonar many times, so how do I view all the indicators of a previous version?
what have you tried so far to achieve this
I have tried using the branch plugin to accomplish this, but can different branches be compared by sonar.properties file configuration?
For example: I save A commit as branch A and B commit as B, then I hope B can use A as the leak period for code quality comparison.
For PRs only current state is available. If you’re talking about previous analyses of Long-lived branches, you can’t easily get the old values from the UI, but you can use web services if you really need them (but why?).
BTW, the current version is 8.2 and the current LTS is 7.9.2. You should upgrade at your earliest convenience.
Our submissions are frequent. It is possible that developer A submitted the first time and generated sonar data a. Developer B then submitted a submission to generate Sonar data b. Then A will not be able to see the details of his sonar index, such as: adding coverage lines; I considered using branches to store different commits, but this way I ca n’t compare the added code;
If Dev A and Dev B are working on the same branch/PR, then what they need to see is the current, cumulative state. If they’re working in different branches, and thus with different PRs, then they do need to be differentiated at analysis.
Sorry, but I don’t understand what you mean here.
We use Gerrit as the source code management work. When the code is pushed to the temporary branch, sonar will be triggered, that is, based on the base code, A submits file a, which will generate the coverage of file a. When B submits a file b based on base at the same time, then only the coverage of file b can be seen on sonar, and the sonar data submitted by A is covered;
If you’re not already on Developer Edition($), using PR analysis to keep these branches off of each other, then that sounds like what you need.