I want to create a version on a specific scan, the latest scan, and have it persist on that scan. I have a project where I created a version using the Sonarqube UI on the latest scan. On the next run of Sonarscan a new scan appears in the activity but the version I created that was on the previous scan now exists on the latest scan. The version name can be edited, but the version can not be deleted. Here are two sequential pictures showing what I mean. The only difference in these two pictures is Sonarscan ran on the project. I did not move the version myself. What am I doing wrong?
If you insist on keeping a version label for just that project scan/snapshot and persisting it, you can click on the gear icon next to the snapshot and click on “Create Version” (or “Create Custom Event”) to type in the version you want. The latest snapshot on November 19, 2020 9:08AM will propagate the 1.11.0-dev version with each subsequent snapshot. Here’s an example:
On November 19, 2020, 2:59 PM, I had the dont change me version snapshot, but at 3:00 PM the version continued forward. I then clicked on the gear icon on the 2:59 PM snapshot and manually added My First Version version label and created a custom event called 3rd scan. On the next 2 subsequent scans, the dont change me version label advanced for each snapshot.
@Joe, sorry for not replying sooner. I understand the behavior you described with the “don’t change me version” above, and that’s exactly what I don’t understand, or said differently don’t like.
Here’s a hypothetical use case:
We make our last change to a SW component
Our final build executes and runs Sonarscan
We see the new scan show up on the activity tab for the project
We see that this scan passed the quality gate
We decide this is the version we are going to publish
We click on the gear icon to create a “1.0” version on that latest scan.
We start work on 1.1.
We make a change/build/scan related to 1.1
I look at the activity for this project and now my 1.0 version is no longer on the original “1.0” scan. It is now on the latest scan and will continue to move forward to the latest each time a scan occurs. I now have lost my record of which scan was the 1.0 version.
This just seems counterintuitive to me, but it is exactly what you exemplified as expected behavior in your response, so what am I missing? It seems like you are saying I have to wait for my first “1.1” scan to complete, and then I can go back one scan and apply the “1.0” version to the previous scan, and then it will persist on that scan. That doesn’t make sense to me.
Apologies for this delayed answer. I see your problem now: the sonar.projectVersion is being used as a mark for confirming quality gate passing but subsequent scans are not setting it for the one you want.
Regarding your use case:
(Below are my opinions and thus perhaps not the best perspective, so take with a grain of salt.)
For your use case, I suggest you do not use the Activity UI to interact with the project version. The project version should ideally change from within your project, not the UI, since a project version typically follows the project lifecycle, not the Sonar scan history. See Analysis Parameters for other analysis parameters that can track a project’s lifetime.
So that means, at the bold step above (“We make a change/build/scan related to 1.1”), you should add the Sonar analysis parameter sonar.projectVersion=1.1 so that the New Code Period can use 1.0 project version as the one to compare 1.1 project version to. Please read our New Code Period documentation for more details on this setting. By default, we use “Previous Version” globally and “Previous Version” at the project level.
I believe you wanted to establish a project version with a passing quality gate, but the project itself doesn’t get this feedback and can’t keep track of this history, so each subsequent Sonar scan progresses forward. Project version should be defined as the project’s state, not Sonar scan state.
Thus, the only time you should modify anything on the Activity UI:
Adding a custom event (like a special comment or annotation to underscore the Sonar scan result)
Correcting a project version mistake
You should not interact with this screen otherwise if you ensure that project version is defined by each Sonar scan, which can easily be done with sonar-project.properties or at the sonar-scanner command line or the like.
As an alternative, in SonarQube 8.6 at least, you can choose various New Code Periods:
Previous version
Specific analysis (available at branch level in Developer Edition and higher, otherwise project level for Community Edition)
Reference branch
Number of days
The “Specific analysis” option might work for you too, so you can test this one out, if you don’t intent on changing your current workflow.
To get to that option, go to the project dashboard > Project Settings > New Code. Then click on the gear icon on the far right-hand side of the branch of interest. Click Edit. Then select which method of analysis for New Code Period you want.
I’m experiencing this as well and this explanation just doesn’t make sense to me. I can’t wrap my head around why you would want the version associated with an analysis to automatically move to future analyses?
For our workflow, we use conventional commit messages to determine the next release version. We run a sonar scan of every commit in CI but we don’t know at the time of running the scan what the final release number will be.
My planned solution was to have our CI tool annotate the final analysis with the version number at the time that it’s actually being published but that doesn’t work because the previously published version number re-assigns itself to every analysis from a pre-release build.
I would ideally like to look at the activity graph and see: “In v1.0.0, we had 8 code smells but in v1.0.1 we reduced it to 5 code smells.” But the way it currently works, it would actually be “In the last pre-release build before shipping v1.0.1, we had 5 code smells and I can’t actually see how many code smells we had when v1.0.0 shipped.”
Am I just completely misunderstanding this feature?
@Mike_Andersen I agree with you. Based upon what Joe recommended above, we setup a temporary repo and project to figure out how make versions work for us. Ultimately I feel we are doing a bit of “gymnastics” to have the right versions on the correct SQ activity items.
Consider a case where you have a single branch where you are scanning on every commit and sometime later you will apply a version tag to in your CM tool that you want to match up to an activity entry on the project (i.e. after you know it passes SQ scanning, your SQA testing, etc.). BTW, SQ APIs exist for knowing the GIT hash for an activity entry. You want to set up the New Code Period to be “By Version” and your release process is applying those versions on SQ activity items. Then you never have to go back and set your New Code Period in SQ again. Your process makes it happen. That’s what we needed.
Here’s the step by step procedure we ended up verifying worked for our needs. This is all done through the web API. Nothing in the UI.
Run a scan and at scan time set the version to “latest”
Observe in the UI that the “latest” version is on the latest scan
Run a scan and at scan time set the version to “latest”
Observe in the UI that the “latest” version is on the latest scan, version on N-1 is empty
Use a separate script that access the API to set the latest scan version to “1.0”
Observe in the UI that the “1.0” version is on the latest scan
Run a scan and at scan time set the version to “latest”
Observe in the UI that the “latest” version is on the latest scan
Observe in the UI that the “1.0” version is on the previous scan
Run a scan and at scan time set the version to “latest”
Observe in the UI that “latest” version is on the latest scan, nothing is on the N-1 scan, and “1.0” is on the N-2 scan
Observe in the UI that the New Code Period starts at version “1.0” activity entry
Use a separate script that access the API to set the latest scan version to “1.1”
Observe in the UI that the “1.1” version is on the latest scan
Run a scan and at scan time set the version to “latest”
Observe in the UI that the “latest” version is on the latest scan
Observe in the UI that the “1.1” version is on the N-1 scan
Run a scan and at scan time set the version to “latest”
Observe in the UI that the “latest” version is on the latest scan, nothing is on the N-1 scan, and “1.1” is on the N-2 scan
Observe in the UI that the New Code Period starts at version “1.1” activity entry
