To be clear, you ran two successive analyses with no sonar.projectVersion (so, the default value), and you saw issues that were “new” for the first analysis get moved out of “new” for the second one?
Could I have a screenshot of the left column of your Activity tab, redacted as necessary?
Thanks for the screenshots. They’re very helpful, particularly the one I didn’t ask for () that shows a QG change with no issue change (and no version change).
I had assumed that something would jump out at me from your screenshot, but nothing does.
Do you still have access to the analysis logs from those last two runs? Could you post them here, redacted as necessary?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
SCM provider autodetection failed. Please use "sonar.scm.provider" to define SCM of your project, or disable the SCM Sensor in the project settings.
These prerequisites are listed for PR analysis, but they’re generally applicable. Can you make sure they’re in place? In particular, I think we need to hit this point first:
The CI/CD host’s local repository contains valid repository metadata (e.g. the .git folders have not been removed).
Our results are much streamlined now.
We still see an issue with the scans. It lists all issues of the FrontEnd, even if the files are not part of the present PR.
But it is working fine for Backend code. I am attaching logs of the run. new 94.txt (59.7 KB)
Thanks for pointing to it.
I turned it on. But I got
No SCM system was detected
The checkout had .git folder as hidden. I tried the following:
Adding parameter -Dsonar.scanner.excludeHiddenFiles=false
Tried making git folder visible.
The issue persisted, so I added parameter -Dsonar.scm.provider=git
But getting Not inside a Git work tree: /usr/src
Tried addressing it with -Dsonar.projectBaseDir=“$PWD” but got stuck with
Error during SonarScanner CLI execution java.lang.IllegalStateException: Project home must be an existing directory: /home/bamboo/bamboo-agent-home/xml-data/build-dir/abc-A-JOB1
Yes, most systems will treat a file or directory named with a leading . as hidden by default. This is why Git puts its configs in a “dot directory” - to not clutter the visual representation with its metadata. That shouldn’t have any bearing on whether or not analysis can find that data.
Let’s talk about your project structure. Where is the .gitinfo directory located in relation to where you’re kicking off analysis from? Is it in the same directory? The directory above? Below? Because it needs to be right there in the directory analysis is fired from.
So, .git is at root (pwd).
Analysis is being triggered from root (pwd).
Codes to be scanned are passed as volume. -v "$PWD/A_Backend:/usr/src/Bwwwbackend"
You’re mapping in 3 different directories. I assume you’re trying to assemble a source tree under the assumption that analysis will run from /usr/src and see all 3 directories you’ve mapped under it. However, you then set
-Dsonar.projectBaseDir="$PWD"
Which tells analysis to run from $PWD which… probably doesn’t make sense as a reachable address to the Docker image. Hence the
Now, back to the complaint:
Based on the 3 volumes you’re mapping in to the Docker command, do I correctly guess that this is actually 3 difference checkouts that you’re trying to analyze together as one project?
A few side notes on the rest of your configuration:
-Dsonar.scm.provider=git
You don’t need this. If analysis isn’t able to pick this up from the environment, telling it explicitly won’t do any good.
This should be picked up automatically from the environment. Once you get your SCM metadata sorted out, that is.
You’ve got exactly the same set of exclusions in both places. Since sonar.exclusions wholly omits the files from analysis, there’s no put in also omitting those same files from coverage consideration. You can drop sonar.coverage.exclusions.
You need to map in your checkout directory as the /usr/src directory. Just once. Just that top-level directory. If there are things in that directory you were trying to omit with your elaborate volume mapping, then that’s where your exclusions should come in.
) that shows a QG change with no issue change (and no version change).
