Version used 842
Currently we have the metric for new coverage but it seems to be not working. In the sonar qube it is showing the overall coverage but not the code coverage for new lines in pull request.
I have found some information that it is causing issue because there is no scm in the properties file .So I added the bottom lines to fix it in the sonar-project.properties file
sonar.scm.enabled=true
sonar.scm.provider=git
Now I’m facing How to fix not inside a git work tree. issue
So for this I added “./” at the front in sonar.sources and sonar.tests. Ex sonar.sources = ./src/directory
Even then I’m facing the same issue
Hi Akash,
Let’s rule out the obvious questions first: are you sure the file path is actually inside a git tree? If you type a command like git log <filepath> do you get some history or an error about the file not being in the working tree? If the latter, you’re probably not actually operating on a proper git clone and should revisit how you’ve checked out the code.
Our scanner is usually pretty good about detecting when we’re within the context of a git repo, so I’m surprised if you have to enable this manually.
I’m currently making changes to this sonar-project.properties file. I went to the directory of that file and opened the git bash. I ran this git log sonar-project.properties. I see a history of recent commits and don’t see any error.
To be clear, I was recommending you do this for the file path that was featured in your error screenshot in the first post, not the sonar-project.properties file.
It is not showing any particular file. Its saying the entire project is “not inside a git working tree”. This happened after adding the scm properties to sonar-project.properties file. Earlier we were not having this issue.
The issue started on “Why sonar cube is not showing the coverage for new lines in the pull request even though it has all the metrics for new code coverage in sonar_gate_profile.xml”
I also have few questions regarding sonarcube ?
- How can I test sonarcube code coverage in my local from Inetllij IDE
- Can you explain how does jenkins picks up the properties from sonar-project.properties file
I have no idea what this file is that you’ve referenced. This is not a standard file format used by SonarQube and we do not support a mechanism for specifying a Quality Gate as XML to pass to SonarQube. The Quality Gate must be configured within the SonarQube UI itself and associated with your project. Will you confirm that the Quality Gate associated with your project in the UI contains a condition for coverage on new code?
You cannot. SonarLint is available to bring Sonar analysis into your IDE but it does so one file at a time. Since enforcing coverage is done on a whole-project basis it requires a full build and analysis involving the Sonar scanner and SonarQube server. Let’s keep the discussion focused on your main concern.
Jenkins by itself does nothing with this file. The sonar-scanner (or our Scanner for Gradle, Maven, or .NET) must be involved in the project pipeline for analysis to occur and it is the scanner which will look for the properties file and use the values it finds.
Back to your original issue and considering the other questions you’ve asked, let me emphasize a few points:
- A PR analysis will not properly differentiate new code unless SCM is detected and we can see the difference between the PR branch and target branch via git refs present in the cloned repo on the local filesystem
- Given the issue in your first post where forcing the SCM to git resulted in errors, I suspect your root issue here is that you’re not invoking the analysis from the root of a properly cloned git tree.
- Since you mentioned jenkins, I suggest you study our Jenkins documentation and follow it closely. It may be worthwhile to start over based on one of our examples and adapting to your project.
Will you confirm that the Quality Gate associated with your project in the UI contains a condition for coverage on new code?
Yes, We have a condition for new code coverage which is set to “less than” 80%. If I’m right the condition is to decline the pull request which don’t have less than 80% of code coverage.
It should show a new coverage tab for a new PR after the build triggered from jenkins besides the overall coverage in the sonarqube UI but this is not happening. I’m not sure where exactly the issue is.
I suspect your root issue here is that you’re not invoking the analysis from the root of a properly cloned git tree.
How can I check this and also what must be the solution to fix it
