How does SonarQube expect me to use the sonar.projectVersion property?

sonarqube

(Thomas A. F. Thorne) #1

Is there an expected workflow around how SonarQube expects or requires the project version to be used? I populate the property on the fly when I call the sonar-scanner with:

-define sonar.projectVersion=`git describe --abbrev=0 --match [0-9]\.[0-9]\.[0-9]`

This generates tag descriptions like 0.0.1, 0.0.2, and so on. As you can see, I use Git as my version control system and something along the lines of semantic versioning.

My version number to appears in SonarQube starting on the day I tag the new version and continues until I tag the next version. To me, that implies that the version is continuing to accumulate errors which is not what is really happening.

I suspect what I should be doing is using something more like git describe --match [0-9]\.[0-9]\.[0-9] --dirty although this would create a new version for every commit which is a bit much. So perhaps something that generates tags more like 0.0.1 for The tagged changeset and 0.0.1-g for any that come after it until 0.0.2.

I am working on C++ project with GNU Make based builds. SonarQube analysis is run from a GitLab CI job which uses the build-wrapper-linux-x86 build wrapper around our call to make. Analysis of the master branch, short-lived branches and other long-lived branches all seem to work as expected.

My question is only about the version numbering schemes and expected behaviour of the SonarQube interface as a result.


(Thomas A. F. Thorne) #2

Having looked into what git can output, I plan to update my projectVersion setting command to:

git describe --match [0-9]\.[0-9]\.[0-9] | grep -Eo "^([0-9]*\.)*[0-9](-[0-9]{1,}-g){0,1}" | sed 's/-[0-9]\{1,\}-g/+/g'

This will set the version to 0.0.2 on the tagged changeset only and then change the version to 0.0.2+ on the next changeset. SonarQube should then retain the details of my versioned released for longer and have a running update of the latest development work.