which versions are you using ( * Community Edition
v9.9.7 (build 96285), Scanner, and any relevant extension)
how is SonarQube deployed: zip
what are you trying to achieve - want to run scan on SVN revision specific files only
what have you tried so far to achieve this - i could do it using sonar.inclusions. But we have to manually get the filenames along with their path in the required format.
Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!
Hi,
We are trying to achieve the ability to scan only the revision specific files using SVN revision number. (tried using sonar.svn.revision / sonar.scm.revision property).
But it is still indexing all the files in the project base directory.
any advice to achieve this is much appreciated.
Please let us know.
here is the scan logs for reference:
C:\cm32\ERP_R12\Standard\Webservices\src\xxxx-field-rest-api>sonar-scanner -Dsonar.projectVersion=1.0 -Dsonar.java.binaries=. -Dsonar.projectKey=testkey22 -Dsonar.projectName=xxxx-field-rest-api -Dsonar.java.source=8 -Dsonar.scm.provider=svn -Dsonar.scm.revision=197879 -Dsonar.analysis.cache=false
Picked up JAVA_TOOL_OPTIONS: -Djava.vendor="Sun Microsystems Inc."
INFO: Scanner configuration file: C:\Users\vsk\Local work\Downloads Folder\sonar-scanner-cli-4.7.0.2747\sonar-scanner\bin\..\conf\sonar-scanner.properties
INFO: Project root configuration file: NONE
INFO: SonarScanner 4.7.0.2747
INFO: Java 11.0.14.1 Eclipse Adoptium (64-bit)
INFO: Windows 11 10.0 amd64
INFO: User cache: C:\Users\vsk\.sonar\cache
INFO: Scanner configuration file: C:\Users\vsk\Local work\Downloads Folder\sonar-scanner-cli-4.7.0.2747\sonar-scanner\bin\..\conf\sonar-scanner.properties
INFO: Project root configuration file: NONE
INFO: Analyzing on SonarQube server 9.9.7.96285
INFO: Default locale: "en_US", source code encoding: "UTF-8"
INFO: Load global settings
INFO: Load global settings (done) | time=279ms
INFO: Server id: AYeQ773lu12RoBn4l2rg
INFO: User cache: C:\Users\vsk\.sonar\cache
INFO: Load/download plugins
INFO: Load plugins index
INFO: Load plugins index (done) | time=73ms
INFO: Load/download plugins (done) | time=930ms
INFO: Process project properties
INFO: Process project properties (done) | time=1ms
INFO: Execute project builders
INFO: Execute project builders (done) | time=2ms
INFO: Project key: testkey22
INFO: Base dir: C:\cm32\ERP_R12\Standard\Webservices\src\xxxx-field-rest-api
INFO: Working dir: C:\cm32\ERP_R12\Standard\Webservices\src\xxxx-field-rest-api\.scannerwork
INFO: Load project settings for component key: 'testkey22'
INFO: Load project settings for component key: 'testkey22' (done) | time=115ms
INFO: Load quality profiles
INFO: Load quality profiles (done) | time=66ms
INFO: Load active rules
INFO: Load active rules (done) | time=2082ms
INFO: Load analysis cache
INFO: Load analysis cache | time=49ms
INFO: Load project repositories
INFO: Load project repositories (done) | time=87ms
INFO: Indexing files...
INFO: Project configuration:
INFO: 846 files indexed... (last one was RESTModel/src/ca/xxxx/field/punchlists/view/PmPunchListSubnoteViewImpl.java)
INFO: 1542 files indexed
INFO: Quality profile for java: Custom JavaSql
INFO: Quality profile for json: Sonar way
INFO: Quality profile for xml: Sonar way
INFO: ------------- Run sensors on module xxxx-field-rest-api
INFO: Load metrics repository
INFO: Load metrics repository (done) | time=50ms
Terminate batch job (Y/N)? y
C:\cm32\ERP_R12\Standard\Webservices\src\xxxx-field-rest-api>svn diff -r 197878:197879 --summarize
M RESTModel\src\ca\xxxx\field\projectchecklists\util\ProjectChecklistUtil.java
M RESTModel\src\ca\xxxx\field\common\xxxxGeneralFunctions.java
M RESTModel\src\ca\xxxx\field\relateddocument\view\RelatedDocumentViewImpl.java
M RESTModel\src\ca\xxxx\field\notifications\views\v1\NotificationsRowImpl.java
M RESTModel\src\ca\xxxx\field\notifications\views\v1\NotificationsImpl.java
M RESTWebService\src\ca\xxxx\field\rest\contacts\ws\v1\Contacts.java
M RESTWebService\src\ca\xxxx\field\rest\projects\ws\v1\ProjectPhoto.java
C:\cm32\ERP_R12\Standard\Webservices\src\xxxx-field-rest-api>
SonarQube is meant to index all the files in the project – that’s the default behavior. In some cases, incremental analysis mechanisms can speed up analysis, but not by preventing all files from being indexed.
If you want to analyze only files changed in the changeset, you would have to adjust your analysis scope, as you mentioned.
What’s your goal in doing this? Performance? Something else?
Thank you for the response. Our goal is to run the scan on only files which were updated in a specific commit (revision number). And report the issues reported only on the newly updated lines of code.
As of now we are using sonar.inclusions property to manually supply the updated files to the command to restrict the scope.
Can we not just pass the revision number to the scan command to pickup only those files belonging to that commit only?
And could you also explain this logs please
18:18:30.823 DEBUG: SCM revision ID '189264'
18:18:30.858 DEBUG: **Getting relative path from SCM root is not supported by svn provider**
I guess that is a result of the property — -Dsonar.scm.revision=189264
Is that possible? If the answer is yes, guide me how?
SonarQube Community Build is built to scan the main branch of projects. Anything extra you do to analyze only those files changed in a changeset… is not a use-case we’re building it for. In any case, if you really need to you can adjust sonar.inclusions.
Developer Edition, which supports branch and PR analysis, would allow you to analyze these changesets either as Pull Requests or branches with only the code in your changeset represented as New Code.
This is just a DEBUG message that is thrown anytime the SVN SCM provider is used. Nothing to worry about.
Thank you Colin for clarifying the use case. But regarding the logs, I am sure those logs are showing up only when we use the property sonar.scm.revision=189264 in the sonar-scanner command.
My question is that, when it is able to read the SCM revision number supplied, but why is it unable to find/list the files to be included in the scan?
Are saying it is useful/available only starting from Developer Edition?
Setting sonar.scm.revision adds metadata to the analysis record in SonarQube, but it does not affect the process of identifying which files to include in the scan, or deciding which files are “new”. SonarQube is designed to analyze all files within a branch, and then:
SonarQube can utilize the project’s New Code Period to distinguish between “New Code” and “Overall Code”:
In the Community Edition, this applies to the main branch of the project (which consists of all code merged into the target branch). From a specific baseline (based on repo versioning, or a number of days), all code after that is considered “New”, and displayed separately in the branch overview
In the Developer Edition and higher, the New Code Period can be set based on a reference branch to differentiate new code from overall code in branch analyses based on SCM data (SVN is asked for a list of changed files between the two branches)
In the Developer Edition and higher Pull Request analysis shows only lines that have been changed in a given changeset. While SVN doesn’t really support pull requests, there is a fallback mechanism in SonarQube to compute changed lines when SCM data doesn’t provide this info.
In the Community Edition, you will need to fiddle with the Analysis Scope to display only the results for files changed in a changeset.
To clarify, we are currently able to scan only the updated files in a specific SVN revision by using svn log -r 189264 -v to list the updated files along with their paths. We format this list of files and supply them as an input to the sonar.inclusions property, which successfully limits the scan to just those specific files.
However, I am looking for a more streamlined approach that allows us to achieve this directly by specifying the revision number, for example, using -Dsonar.scm.revision=189264.
My main objective is to understand if there is a built-in, standard way in the SonarQube Community Edition to scan only the updated files without needing to pre-process the file list manually. I’d like to know if the sonar.scm.revision parameter is expected to function this way or if this feature is available only in higher editions. Additionally, if there’s a recommended best practice for this scenario in the Community Edition, I’d appreciate any insights.
Basically, I want to avoid reporting older issues dated back to years and focus only on the LOC changes introduced after a specific date or within a specific date range. My goal is to identify new issues on recent changes without re-scanning or re-reporting existing issues that have been in the codebase for years.
Thank you for clarifying the behavior of sonar.scm.revision and the other available option sonar.inclusions in the Community Edition.
I understand that the New Code Period helps identify new issues, but it seems to still scan all files, not just the updated ones.
However, my primary question remains: is there a built-in, standard way to avoid manual steps when scanning only the updated files (e.g., based on specific revisions or date ranges) without having to pre-process the file list?