Pull-Request decoration overwrites existing builds

We’re using Sonarcloud integration for Bitbucket Cloud repository and CI/CD with Azure DevOps.
We’ve set up pull-request validation builds. Sonarscanner analisys takes too much time, so we’ve split our PR-validation to two builds:

  1. Regular build+test run to validate that code actually builds and tests pass
  2. Sonar build - to perform static analysis and provide pull-request page with all the code metrics needed.
    So now we have problem with build statuses in Bitbucket cloud.
    First build has ‘report build status’ checked in Azure DevOps, so after every run we see 1 of 1 passed and we understand, that build and tests passed. The second build has this option off. But it still reports its status trough analyzer itself, because we’ve set it up to decorate our pull-requests.

So later the second build finishes and it OVERWRITES build statuses: we now see 1 of 2 builds passed
image
First link targets to Azure DevOps sonar build (second build from above two). Second link targets to sonarcloud branch overview.
First build link is lost. So if something goes wrong - we’re forced to search trough Azure DevOps pipelines results to find that FIRST build and see what gone wrong (second build sometimes fails only because it were killed by timeout - because analysis build is really slow).

Is there any way to preserve already existing build statuses whenever sonarcloud reports itself to Bitbucket cloud?

Hi,

Are the 2 builds triggered automatically with BitBucket (did you set something on the triggers tab of the pipeline settings in Azure ? )

By the way, which component of the analysis takes times ? Do you have a big solution ?

Thanks.

Mickaël

Yes, both builds area trigered by Azure DevOps ‘Pull-requests validation’ feature.

Not any - ~70k lines of c# code. Regular build takes <1 minute to finish. Build with analysis enabled takes about 10 minutes. And since we have to build and then run tests - dotnet test .. ignores previously built projects and builds all the needed projects again, for 10 minutes, then it runs tests… And then azure task of parsing test coverage result takes another amount of time because of many files generated. So whole sonar pipeline for pull-request takes somewhere near 25+ minutes to complete.
It is not so bad to had these sonar pipelines slow, because we’ve separated em to dedicated queue - so regular builds complete fast and sonar ones go in background.
But the fact, that it overwrites regular build result gives us some troubles.

If you want your dotnet test task to not build again the solution, you can at least run it with the --no-build flag, it may be convenient in your case.

I think that while 2 build are triggered by the Pull Request Validation, the webhook that connects to BitBucket behaves like it overrides the status of the build.

I’ll try to make some tests on my side to confirm / infirm that.

Thanks !

Mickaël

I cannot use --no-build.
We have some projects in solution, that are not linked to test projects, so if we run build for test projects - not all application projects are built and analyzed. If we build only application projects and then run test with --no-build - then test projects are not built so test not ran.
So looks like we need to build tests, then initialize sonarscanner, then build projects, then run tests with --no-build… Maybe we’ll try later :slight_smile:

The main problem is not there anyway.
Two builds are trigered by bitbucket webhook. One of’em has report build status OFF. So Azure DevOps itself DOES NOT report sonar’s build status to bitbucket. Looks like It is made by sonarcloud itself in pull-request decoration feature. While it adds scanner statistics to pull-request. Also it overwrites existing build statuses :frowning:

I just made some tests, and here’s my statement.

No matter which one of the two builds (or both) has “report build status” ON, the latest build will override the build status on BitBucket.

I think this is easily understandable by checking Webhook on BitBucket side, only one Webhook request is done against Azure DevOps, with the same key, so, by design, and given this topic :https://help.appveyor.com/discussions/problems/20032-the-bitbucket-build-status-webhook-isnt-being-used-correctly : this is the expected behavior.

Mickaël

Hmm, I’ve found that both these builds were using same default build-numbering template, so that could result in same key values taken for both reporters. I’ll check it…

Nope.
Those are two different build definitions so they have different build numbers so they do not match. So the question is what is used as a key for build report in both cases and how to see it in bitbucket cloud

I found some extra doc for that kind of scenario, but i don’t know if it’s the same with the integration between Azure DevOps and BitBucket

https://developer.atlassian.com/server/bitbucket/how-tos/updating-build-status-for-commits/

https://confluence.atlassian.com/bitbucketserverkb/commit-build-status-is-always-red-even-if-other-builds-succeed-779171240.html

I tried to deactivate the report build status on both build, and the last failing seems to not override anymore the first one, but that’s kind of weird.

And, by the way, both build that i setup and test were not include any SonarCloud task, so that might be not our mistake :slight_smile:

Mickaël

You mean that even disabled report build status option still shows build status in butbucket pull-request?
Thats weird.o_O

I’m not surprised since it appears to be a GitHub / Azure Repos specific feature https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/pipeline-options-for-git?view=azure-devops#report-build-status-azure-pipelines-tfs-2017-and-newer

Not exactly. I remember posting build statuses from gitlab, bamboo, teamcity to gitlab and bitbucket.So it is pretty common feature