I had the same question: we’re using Git tags for versioning so reading those or the matching Github releases would be a nice improvement over “version not provided”, or really even just using the commit ID.
thanks for raising the question! Setting the version is currently not supported with AutoScan. If you don’t mind, I’d like to dig into what you would expect.
From what you say, the version of your code is currently in your package.json file. Let’s say it’s version “1.2.3”. What you also say is that this version also exists as a tag on Git, which definitely makes sense given the way versions are usually managed in the JS world.
Ideally, what would you expect to see instead of “version not provided”? I guess “1.2.3”?
Would you expect AutoScan to automatically guess this? (from the latest Git tag in the master branch for instance, or from the package.json file) Or would you want to have a way to set it manually? (to control the value)
I would already be happy if the sonar.projectVersion tag would be supported in .sonarcloud.properties? We update that file on each release with the new version.
I would also like sonar.projectVersion to be supported in .sonarcloud.properties. Lately I use bumpversion to handle versioning. It is quite straight forward to configure bumpversion to also update the version in file .sonarcloud.properties. Though, not every commit/push would have a unique version. So, it could be that when a new version X.Y.Z is found in .sonarcloud.properties it would be shown as X.Y.Z. For subsequent scans in which the version does not change, it would be shown as X.Y.Z-scan2, X.Y.Z-scan3 …
It would be great for our teams if the version automatically pulled from package.json as we keep an updated version # in the package file for all changes.