feature: Make bitbucket build-status optional

[ThibautMarechal]

Hi,

This change adds the ability to skip the build-status publishing that currently blocks pull-request merges. The functionality is redundant when using Bitbucket’s native feature to block pull-requests based on a Code Insight condition (see screenshot below).

This PR addresses the following issue: #1097.

I’m not a Java developer, so there may be a more elegant way to implement this. I also didn’t find any existing configuration in the repository that I could replicate for this functionality.
Any guidance or suggestions for improvement would be greatly appreciated.

[mc1arke]

This isn't something that appears to exist in Sonarqube's documentation, so we're diverging from how they're configured. Do they have a property they offer for allowing a similar configuration?

[ThibautMarechal]

To be honest, The Sonarqube's documentation don't mention submitting any build status, only code insight.
https://docs.sonarsource.com/sonarqube-server/10.7/devops-platform-integration/bitbucket-integration/bitbucket-server-integration#preventing-pull-request-merges-when-the-quality-gate-fails

[ThibautMarechal]

After some digging, I found that the feature of blocking a PR from code insight was released in the version 6.9 of Bitbucket.
If I do an additional http call to get the version of bitbucket, and based on that version only submitting a build-status if it's lower than 6.9 ?
The initial issue don't mention any bitbucket version at all.

[dkeitzel]

I agree on the sentiment that the native 'Code Insights' mechanism should be used to indicate the status of a quality gate and whether it should block merging. This isn't in line with other ALM integrations, but is in line with the official SonarQube documentation, as @ThibautMarechal pointed out.

Well, at least for the Server edition of Bitbucket. As it turns out the behavior is different between the Server edition and the Cloud edition. Bitbucket Server uses Code Insights, Bitbucket Cloud uses failed builds.

I assume the reporter of #893 was using the Cloud edition of Bitbucket. One could argue #998 introduced a regression for all Bitbucket Server users.

I propose implementing the quality gate handling depending on the actual ALM type. There is ALM.BITBUCKET and ALM.BITBUCKET_CLOUD.

Furthermore I suggest using "Code Insights" exclusively and not using failed builds at all for ALM.BITBUCKET. This is available since Bitbucket Server version 6.9 (year 2009) on wards, which should be sufficient.

What do you think?

[adrianwarowny]

Good idea it may help to workaround my issue: #1171

[Lauri-Nomme]

+1

Thanks for implementing this, 100% support making SQ -> BB build-status optional.
The PR #998 indeed introduced a regression for us across multiple teams and we're currently working this around with removing the Minimum successful builds Merge Check on BB side, configuring Required builds with the necessary build keys that should actually block merges and having the systems reporting those builds generate stable build keys.

So, quite the hassle, would be nice having this disabled for BB server (or configurable) on the SQ side to remove the workarounds and have the old behavior back.