Swift Coverage - User error or a Genuine Bug

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    - SonarQube 10.4.1
    - SonarScanner CLI 5.0.1

  • how is SonarQube deployed: zip, Docker, Helm
    - Docker

  • what are you trying to achieve
    - Coverage on swift code

Hi All,

We are trying to apply coverage to our Swift code, however SonarQube is flagging this particular file having 0% coverage although llvm-cov flags it as 98.9%. What we want to know is whether this is a user error or a genuine bug within SonarQube.

The following code is marked as 0% while in the report file provided to SonarQube is marked as 98.9%:

extension Service where Self: <Name>{
Uncovered code
    func request() throws -> URLRequest {
        guard let url = {
            var components = URLComponents()
            components.scheme = "https"
            components.host = server
            components.path = path
            return components.url
        }() else { throw ServiceError.cannotMakeValidURL }
        var request = URLRequest(url: url)
        request.httpMethod = Self.httpMethod
        try annotateRequest(request: &request)
        return request
 108|       |extension Service where Self: <Name>{
  109|       |    // default query to nil
  110|     15|    var queryItems: [URLQueryItem]? { nil }
  111|       |
  112|     16|    func request() throws -> URLRequest {
  113|     16|        guard let baseUrl, let url = {
  114|     16|            var components = URLComponents.init(url: baseUrl, resolvingAgainstBaseURL: false)
  115|     16|            components?.scheme = "https"
  116|     16|            components?.path = path
  117|     16|            components?.queryItems = queryItems
  118|     16|            return components?.url
  119|     16|        }() else { throw ServiceError.cannotMakeValidURL }
  120|     16|        
  121|     16|        var request = URLRequest(url: url)
  122|     16|        request.httpMethod = Self.httpMethod
  123|     16|        
  124|     16|        try annotateRequest(request: &request)
  125|     16|        
  126|     16|        return request
  127|     16|    }

As you can see the function has been through 16 runs which means it’s full covered

The command we use is:

2024-05-31 11:39:54,297 [STDOUT] (53276 started) "<PATH TO SONARSCANNER>/bin/sonar-scanner" "-X" "-D" "sonar.host.url=<URL>" "-D" "sonar.projectKey=ProjectKEY" "-D" "sonar.projectBaseDir=<ROOT>" "-D" "sonar.verbose=true" "-D" "sonar.login=****" "-D" "sonar.c.file.suffixes=-" "-D" "sonar.objc.file.suffixes=-" "-D" "sonar.cpp.file.suffixes=-" "-D" "sonar.inclusions=**/*.swift" "-D" "sonar.swift.coverage.reportPaths=sonarqube-coverage.report" "-D" "sonar.coverage.exclusions=Project/Project docs/UI/**/*.swift" "-D" "sonar.sources=Project/Project docs,Project/AppClient,Project/Crypto,Project/Services"

sonar.swift.coverage.reportPath is the correct analysis parameter, rather than sonar.swift.coverage.reportPaths (note the final s isn’t present in the correct parameter). You’ll find the correct analysis parameter also documented here

Hi @Colin,

I’ve changed the name of the parameter (bear in mind the old parameter is giving the same results as the new name) but the same issue still occurs. Also just to give a bit more information, the analysis output states that 70% of the project has been covered so it is picking up the coverage report, but doesn’t seem to translate it within the output as some bits are not being covered although they should be. Any other recommendations please?

Hey there.

I do intend to come back to this thread, but I didn’t have the chance this week.

Hey again @hus90

In these situations it’s almost always the case that the coverage report doesn’t look as expected (even if, for example, in some HTML version of the report it shows files/lines as covered).

Could you share the coverage report here (sonarqube-coverage.report), as well as the name of the trouble file, and DEBUG analysis logs (sonar-scanner -X)?

Hi @Colin

Thanks for reaching back. I took your advice and went through the entire coverage report and it turned out to be a user error where we got 2 files confused up as they had pretty identical paths.

Thanks for everything

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.