Reducing Bitbucket pipeline costs - running SonarCloud on all PRs

[plsoucy-tapclicks (Pierre-Luc Soucy)]

I’m evaluating whether it makes sense for us to run SonarCloud on all our pull requests. Right now, I’m not sure, as the Sonar scan takes about 12 build minutes each time it runs, and the Bitbucket pipeline build minute cost is significant even after just a week of using this.

1. Is there an easy way to run the scan only when files in the scanned directories are modified? We currently scan our PHP code in certain directories only, so pull requests that consist of front-end changes in different directories only should not require a full Sonar build. I realize we can probably implement our own build avoidance logic here, but it would be great if there was a setting (or plan for one) in SonarCloud to skip/shorten the scan if no relevant files were modified.

2. Is there a way we could run the scan on demand on pull requests? We can run the scan on demand on specific branches, but when we do that, Sonar does not seem to have knowledge of a destination branch and therefore reports statistics compared to master, even when the PR is from a branch that was not based off of master. If there is a way to run on demand either on branches (with knowledge of the base branch, so we only see differences based on that) or on pull requests (I don’t think BitBucket currently has the option), I’d like to know

3. Any suggestions to speed up the build based on this config would be welcome.

We’ll see whether we run builds on all PRs, daily builds on master/develop only, or not use Sonar at all based on this and feedback from our team.

Current bitbucket-pipelines.yml (kept only relevant info for Sonar):

image: node:10.15.1

clone:
  depth: full

pipelines:
  custom:
    sonar:
      - step:
          size: 2x
          caches:
            - sonar
            - docker
          script:
            - pipe: sonarsource/sonarcloud-scan:1.1.0
              variables:
                DEBUG: "false"
          services:
            - docker
  pull-requests:
    '**':
      - step:
          size: 2x
          caches:
            - sonar
            - docker
          script:
            - pipe: sonarsource/sonarcloud-scan:1.1.0
              variables:
                DEBUG: "false"
          services:
            - docker    
definitions:
  services:
    docker:
      memory: 7128
  caches:
    sonar: ~/.sonar/cache  # Caching SonarCloud artifacts will speed up your build

Thanks!

[mickaelcaro (Mickaël Caro)]

Hi @plsoucy-tapclicks and welcome to the community !

Sorry for the delayed answer.

@plsoucy-tapclicks

Is there an easy way to run the scan only when files in the scanned directories are modified? We currently scan our PHP code in certain directories only, so pull requests that consist of front-end changes in different directories only should not require a full Sonar build. I realize we can probably implement our own build avoidance logic here, but it would be great if there was a setting (or plan for one) in SonarCloud to skip/shorten the scan if no relevant files were modified.

The analysis will highlight new code for sure, but we don’t have yet this kind of mechanism. I would rather suggest to split your build into multiple ones, targeting the big parts of your project, where you are sure that it will only trigger the relevant build based on the changed you made. (this is known as path filter on Azure DevOps, not sure that this feature exists on BB though)

@plsoucy-tapclicks

Is there a way we could run the scan on demand on pull requests? We can run the scan on demand on specific branches, but when we do that, Sonar does not seem to have knowledge of a destination branch and therefore reports statistics compared to master, even when the PR is from a branch that was not based off of master. If there is a way to run on demand either on branches (with knowledge of the base branch, so we only see differences based on that) or on pull requests (I don’t think BitBucket currently has the option), I’d like to know

The main problem we have is that for the majority of builds, there are variables that we rely on to fill the target branch, main branch, … that are only filled when the build has been triggered automatically, so you might need to setup those variable kind of manually (or define them in the yaml to be sure they will be set and picked up). You can see those variables in the “Scanner context” on each background task in the dedicated menu (Administration → Background task) in your project.

HTH,
Mickaël