Sonar cloud and Bitbucket - Enabling code coverage on PR changes

I have a bitbucket pipeline where I included the sonar pipe cloud scan:

  username: _json_key
  password: '$GCR_JSON_KEY'

  max-time: 45 # Allow a pipeline to run for 45 minutes max

  depth: full       # include the last 100 commits

      memory: 2048  
    sonar: ~/.sonar/cache  # Caching SonarCloud artifacts will speed up your build

    - step: &run-sonarcloud-analysis
        name: Run SonarCloud analysis
        size: 2x
          - docker
          - sonar
          - docker
          - pipe: sonarsource/sonarcloud-scan:1.4.0
              DEBUG: "true"
              SONAR_SCANNER_OPTS: "-Xmx1600m"
    - step: *run-sonarcloud-analysis

    '**': #this runs as default for any branch not elsewhere defined
      - step: *run-sonarcloud-analysis

I have a bunch of unit tests and making reports with pytest-cov. The idea is that sonar cloud can identify in a Pull Request new changes to be readed as a coverage.

But when I create the Pull Request and see in the sonar, I can see more lines mentionedin the coverage which ones are not part of the Pull Request. For example, the only file changed in this PR is the, but I am seeing a lot of other files considered in the coverage.

Why is happening this?

On the other hand, I see I am not including as an arguments in EXTRA_ARGS parameter, attributes considered as mandatory like:, sonar.projectKey and sonar.organization despite that I am able to contact my sonar project from the pipeline.

Any orientation here, will be appreciated.

Hey there.


It looks like you’re performing a branch analysis rather than a pull request analysis – you should be able to leave out sonar entirely (and any other arguments) and receive an analysis of your pull request.

Because your project targets SonarcCloud and is bound - no other arguments are required.

@Colin looks like it is working now. Thanks.

I have the feeling that currently there are some parameters that are not necessary or when we apply them, they disable other functionalities like the sonar.pullrequest.* ones, since it disables the automatic checking for PR and so on.
Is there a documentation section where we can see how to play around this parameters and when use them in such as these situation?

@bgarcial I guess my starting question is… why did you think you had to set at all? Was it documented somewhere alongside the pipe? Old habit from another CI-based configuration?

I think our estimation is… since everything should work properly out of the box without customization (especially for Bitbucket Pipelines), why document the customization (which when working properly, really comes to an internal detail)?

From experience, even if we beg users not to use a property (because things just work without it, or it is automatically configured), some users see something they can customize and they inevitably think they must.

You’ve raised a great point under the go for the simplest perspective to get done things. I also see the explanation here

And yes, sometimes it could happen because implicitly we think in having under control (confguration in this case) as much we can. Also to realize why things have the behavior we are experiencing.

Thanks for your orientation :slight_smile:

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