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.