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.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
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.