CI Pipeline - Separate Analysis / QualityGate steps

TL;DR:
How can I split SonarCloud Analysis and QualityGate, so after marking failed QualityGate issues as “Resolved” I don’t have to re-run the analysis but can continue my CI Pipeline?

Hi Team,

I’ve introduced SonarCloud into an existing, quite large project, so naturally SonarCloud is picking up a lot of old bugs from years ago. We don’t have time to go back and re-architect our entire code ( 1167d effort), but we’d like SonarCloud to pickup issues in new code.

When making changed to an existing file, we often get alerts for “Too many arguments for function” and things like this, failing the quality gate. I don’t want to exclude those rules, as they’re useful for new development. Instead I’d like my devs to review any Blocker and Critial issues and mark them as “Won’t fix”.

After marking a few issues in SonarCloud as “Won’t fix”, we don’t want to have to re-run the entire SonarCloud analysis, instead I just want to re-run the QualityGate, so it can see those few issues have been marked as “Won’t fix” and the deployment can go ahead. I’ve read this recommendation somewhere here on the Forum.

This seemed like a good idea and thankfully the Devs have agreed to give SonarCloud another chance (They’ve been quite annoyed at the increased pipeline time since the start).
I’m afraid if I now have to tell everyone, that e.g. after marking 2 failed QualityGate Codesmells as “Won’t fix” they’ll have to re-run the entire scan, they’ll want to drop SonarCloud completely.

Please help me,
how I can achieve this separation between analysis and QualityGate.
When we re-run the QualityGate after marking issues as resolved I’m getting the same result as before resolving them. E.g.
✖ Quality Gate failed
- New Critical Issues: 2 (is greater than 0)

Here’s the relevant parts from my bitbucket-pipelines.yml

definitions:
  services:
    docker-with-6gb-memory:
      memory: 6144
      type: docker
  caches:
    sonar: ~/.sonar/cache
  steps:
    - step: &SonarCloudAnalysis
        name: SonarCloud Analysis
        clone:
          enabled: true
          depth: full
        size: 2x
        caches:
          - sonar
        services: [docker-with-6gb-memory]
        script:
          - pipe: sonarsource/sonarcloud-scan:1.4.0
    - step: &SonarCloudQualityGate
            name: SonarCloud Quality Gate
            script:
              - pipe: sonarsource/sonarcloud-quality-gate:0.1.6
master: # Master branch release
  - parallel:
      - step: *SonarCloudAnalysis
      - step:
          name: "Build Master for PROD"
          .........
  - step: *SonarCloudQualityGate

Hey there.

Ideally, you are running analysis on your pull requests, meaning you can fix the issues before they make it to your master branch.

When you decorate your Pull Requests in Bitbucket Cloud based on SonarCloud analysis, changes that you make to those issues will update the status in Bitbucket Cloud and allow you to merge (without rerunning analysis).

There’s no getting around needing to re-run analysis of your master branch if the Quality Gate changes SonarCloud side.