SonarQube7.2 and BitBucket Integration

SonarQube
, ,
1

We are new to SonarQube, so we are starting with version 7.2. We have TeamCity setup to do branch analysis and can view the results on SonarQube’s page.

We are a company that does not use Cloud-based products… so no SonarCloud, no BitBucket Cloud. Both are stand-alone server versions within our network.

We installed the plugin for BitBucket to link our pull requests to SonarQube. With the default setup, we get an error saying that branches can’t be found. This seems to make sense, with a seeming history that SonarQube used to do branches as different projects.

So we go to change the setting to use the “New Branching Feature” but then the BitBucket plugin gives me an error that the server doesn’t support the new branching feature (I need SonarQube 6.2+ and the branching plugin).

My understanding is that the branching plugin is no longer separate but part of 7.2. (Developer edition). Could it be this change that is confusing the plugin on BitBucket? Do I need to change/add anything to my SonarQube server? I’m not sure where to look next so I can explore ideas from anyone willing to help.

2

Hi Michael,

Which plugin precisely are you using ? On-prem Bitbucket integration is not supported natively by SonarQube, and for 3rd-party plugin it might be worth you also reach out to the plugin maintainers for good insights.

I can confirm that. Provided you installed the Developer Edition (or higher) package, than branch support is built-in.

1 Like
3

Yes, we are using https://marketplace.atlassian.com/apps/1212735/sonar-for-bitbucket-server

And as it turns out, there was an update within the last week. The update got us much farther to functioning.

Now my only issue is that “Open Issues” are showing up as a Quality Gate error even though I don’t have that condition in my Quality Gate. The vendor is working with us on that issue.

1 Like
4

So the Bitbucket Plug-in is using the following API Call:

GET http://servername:9000/api/measures/component?additionalFields=periods,metrics&metricKeys=alert_status,quality_gate_details&componentKey=REDACTED&branch=feature%2FCdaRemoval

The quality_gate_details metric key, in the Documentation, says this is the proper metric to understand the Quality Gate failures.

But the return of this call give something like this:

{
	"component": {
		"id": "AWTczLf1bKSkiycwvaZ_",
		"key": "REDACTED",
		"name": "REDACTED",
		"qualifier": "TRK",
		"measures": [
			{
				"metric": "alert_status",
				"value": "ERROR"
			},
			{
				"metric": "quality_gate_details",
				"value": "{\"level\":\"ERROR\",\"conditions\":[{\"metric\":\"open_issues\",\"op\":\"GT\",\"error\":\"0\",\"actual\":\"5\",\"level\":\"ERROR\"},{\"metric\":\"reopened_issues\",\"op\":\"GT\",\"error\":\"0\",\"actual\":\"0\",\"level\":\"OK\"}],\"ignoredConditions\":false}"
			}
		],
		"branch": "feature/CdaRemoval"
	},
	"metrics": [
		{
			"key": "alert_status",
			"name": "Quality Gate Status",
			"description": "The project status with regard to its quality gate.",
			"domain": "Releasability",
			"type": "LEVEL",
			"higherValuesAreBetter": true,
			"qualitative": true,
			"hidden": false,
			"custom": false
		},
		{
			"key": "quality_gate_details",
			"name": "Quality Gate Details",
			"description": "The project detailed status with regard to its quality gate",
			"domain": "General",
			"type": "DATA",
			"qualitative": false,
			"hidden": false,
			"custom": false
		}
	],
	"periods": [
		{
			"index": 1,
			"mode": "previous_version",
			"date": "2018-07-27T14:00:34-0400"
		}
	]
}

In the value you see “Open Issues” with a target of 0. But my quality gate (nor the default) in SonarQube does not contain this check.

image
image.png905×251 12.1 KB

What can I configure on SonarQube to return only the measures in my Quality Gate? Does anyone know where the Open Issues measure is coming from?

5

And the answer is here. Which is frustrating. Why have a Quality Gate if it doesn’t gate anything? I suppose now I have to make everything a long-lived branch to make SonarQube useful. :frowning:

6

Hi Michael,

Thanks for the follow-through. Quick note on this:

Making everything a long-lived branch in SQ, when it’s not what that is in real-life, is likely to result in other frustrations (short-lived branches have their own set of cool features around issue synchronization when merging etc.). At this stage I would very much rather recommend that you share your feedback transparently, and open up a proposal on the [Deprecated] Suggest new features category. We’re very much open to discuss anything, and it’ll also be an opportunity to get inputs from the community overall on this topic.

And just FYI, you’ll surely be interested to read MMF-1369 (Real Quality Gates for PRs and short-lived branches), which is only at the ideation phase right now, and which can definitely fuel further discussions in [Deprecated] Suggest new features !