Bitbucket Cloud Warning w/ Build

bitbucket

(Nico) #1

I get a warning w/ analysis which puzzles me a bit as I already tried to provide UUIDs (previously those were just labels/names).

I get warnings like these:

Pull request decoration did not happen. Configuration missing to decorate the Bitbucket Cloud pull request: BitbucketCloudPrConfiguration{owner='{XXXX8ad6-XXXX-4075-95dc-XXXX06dcXXXX}', repository=null, id=2013, headSha='XXXX100e9a8c3f50dd35da0cb2bfffe7e59XXXX', triggerCommitSha=null}

I guess this has to do w/ the values whcih are null here, so some pointers would be great.

Additionally I was asking myself if those values need/can be provided as CLI parameters or must they be provided as environment variables.

I currently use command line parameters. The reference documentation I use is https://sonarcloud.io/documentation/analysis/pull-request/ .


screenshot of an earlier warning with which I’ve tackled so far.


(Michal Duda) #2

Hi Nico,
You don’t need to provide anything if you use Bitbucket Pipelines. Otherwise you need to provide sonar.pullrequest.bitbucketcloud.repository as a CLI parameter to the scanner in the same manner you provided sonar.pullrequest.bitbucketcloud.owner (it looks like the owner was properly recognized).


(Nico) #3

Well that was a bash script in a Bibbucket Coud Pipeline extension pipeline script and I do need to set the CLI parameter otherwise this is not recognized.

And it works! Turned out there was a little mistake and I missed a letter for a CLI parameter. As the parameter name was wrong then, the repository was still null. Just a typo.

Thanks a lot for your feedback, this was very helpful for me to spot the error!


(Nico) #4

@Michal_Duda This now worked very fine for some days, but there was a little change which I don’t understand.

At first the quality gate for the code coverage on new code did mark the build red - IIRC this was another suggestion which earlier didn’t work - but more recently, the build does not get red any longer even when the quality gate is not matched.

I also see a warning about a certain commit not being found during analysis:

Unable to find the commit ‘8e63…3740’ during the analysis

(shortened hash by me)

Maybe you can share some comments.

And if there is an option/setting to make the quality gates active on Bitbucket Cloud Pull Requests regarding the code coverage metrics, please let me know in specific.

Thanks a lot for all your efforts!


(Michal Duda) #5

If that warning shows up it means the pull request wasn’t decorated. Can you check if the the commit with hash from the warning really exists in your pull request?


(Nico) #6

I’ve checked that a couple of times, and it never does. The warning therefore is not lying.

Could it be that this is b/c the analysis runs within the pull-request trigger’ed pipeline? AFAIK on Bitbucket Cloud within the Pull Request Pipeline temporarily a merge w/ the target branch is done so that analysis can run on the expected product if the pull request would be merged. That hash most likely only exists within the Git repository where the pipeline runs and not in Bitbuckets main repository.

Let me know if this information is of any use or you need to know more.


(Nico) #7

And another small question if you don’t mind: What exactly is the decoration? I always see the widget (which also greatly improved btw.), but as you ask that, I wonder if the decoration is the number of Builds and the list of them within the popup/dialog.


(Michal Duda) #8

Hi Nico,

I think your theory is correct. You will probably need to manually provide sonar.pullrequest.bitbucketcloud.triggerCommit parameter to the analysis and pass an existing commit hash that triggered the analysis to it.

Normally Bitbucket Pipelines users shouldn’t have to do that as sonar.pullrequest.bitbucketcloud.triggerCommit should be pulled from the Bitbucket Cloud environment just like all the other parameters (like already mentioned sonar.pullrequest.bitbucketcloud.repository and sonar.pullrequest.bitbucketcloud.owner). I’m not sure why it doesn’t work for you, it would be easier to say if you provide your bitbucket-pipelines.yml configuration.

What exactly is the decoration?

Pull request decoration is the process of adding additional information to pull request by SonarCloud directly in your ALMs UI. In case of Bitbucket Cloud, pull request decoration just means adding a Quality Gate status icon, number of issues on your pull request in Bitbucket Cloud UI and a link to the analysis details in SonarCloud.


(Nico) #9

Thanks for all the feedback. I just saw it now working flawlessly w/o any changes on my end.

Could it be that this is not an issue with a branch pull request which is on top of the target branch so that it would/could be merged fast-forward? (FF means the PR HEAD commit stays).

Also could it be that the branch name makes a difference? The ones w/ errors were with slashes, like feature/test-pull-request-1.

Normally Bitbucket Pipelines users shouldn’t have to do that as sonar.pullrequest.bitbucketcloud.triggerCommit should be pulled from the Bitbucket Cloud environment just like all the other parameters (like already mentioned

Yes, so which Docker image you suggest to use for the analysis?

Here for the pipeline file:

	- step:
		name: sonar-scanner (pr)
		image: ciricihq/gitlab-sonar-scanner:3.0.0
		size: 2x
		script:
		  - dist/scripts/build/sonar-scan

And the sonar-scan is:

#!/bin/sh
#
# sonar scanner bitbucket pipelines runner
#
# usage: dist/scripts/build/sonar-scan
#
set -eu
IFS="$(printf '\n\t ')"

scanner()
{
	echo "$(basename "${0}"): sonar-scanner" "${@}"
	sonar-scanner "${@}"
}

if [ -z "${BITBUCKET_PR_DESTINATION_BRANCH-}" ]; then
	# standard branch
	echo "$(basename "${0}"): https://sonarcloud.io/project/issues?branch=${BITBUCKET_BRANCH}&id=example&resolved=false"
	scanner \
		-Dsonar.branch.name="${BITBUCKET_BRANCH}" \
		-Dsonar.branch.target="master" \
		#
else
	# pull request
	echo "$(basename "${0}"): https://sonarcloud.io/project/issues?id=example&pullRequest=${BITBUCKET_PR_ID}&resolved=false"
	scanner \
		-Dsonar.pullrequest.key="${BITBUCKET_PR_ID}" \
		-Dsonar.pullrequest.base="${BITBUCKET_PR_DESTINATION_BRANCH}" \
		-Dsonar.pullrequest.branch="${BITBUCKET_BRANCH}" \
		-Dsonar.pullrequest.provider=bitbucketcloud \
		-Dsonar.pullrequest.bitbucketcloud.repository="${BITBUCKET_REPO_UUID}" \
		-Dsonar.pullrequest.bitbucketcloud.owner="${BITBUCKET_REPO_OWNER_UUID}" \
		#
fi

The sonar.pullrequest.bitbucketcloud.triggerCommit is indeed not yet part of it. Good point!

Thanks again for all your feedback.


(Michal Duda) #10

I would not recommend running the scanner from a docker image since that is what probably causes the issues with detecting Bitbucket Pipelines environment. Also Bitbucket Pipelines now support pull requests natively so it’s better to use that instead of doing checks in the script.

Instead of using that docker image I recommend using an official SonarCloud Scan Bitbucket Pipe. You can check the example project that uses it for analysing branches and also pull requests. The exception to this is if you use MSBuild, Maven or Gradle. In that case you should use a dedicated scanner and we do have some examples for these cases too. If you use the pipe or the scanners directly in the pipeline, there should be no need to provide all of the pull request and branch parameters.


(Nico) #11

First of all this is as well within naively supported pull request on Bitbucket Pipelines and secondly, I think it’s not too far off to guess that a Pipe is also using a Docker Image. Which is great b/c this is what I originally asked for: Which Docker image does Sonarcloud recommend to run the analysis on Bitbucket Cloud Pipelines?

(We have policy to run the build locally as well for what we recycle the bitbucket pipelines yml configuration.)


(Nico) #12

@Michal_Duda Your hint on sonar.pullrequest.bitbucketcloud.triggerCommit is golden, I now see the decoration on non fast-forward pull requests as well as set to BITBUCKET_COMMIT environment parameter (a.k.a environment variable) for the pull request analysis.


(Michal Duda) #13

First of all this is as well within naively supported pull request on Bitbucket Pipelines and secondly, I think it’s not too far off to guess that a Pipe is also using a Docker Image. Which is great b/c this is what I originally asked for: Which Docker image does Sonarcloud recommend to run the analysis on Bitbucket Cloud Pipelines?

You’re right in assuming that SonarCloud Scan Pipe is also using a Docker Image but Pipes have some additional features compared to any other containers: they are easier to use in Bitbucket Pipelines and they have access to the Pipeline execution environment by default. Technically you can run the pipe image locally but it won’t work correctly unless you emulate the execution environment of Bitbucket Cloud.


(Nico) #14

Yeah, I also did a bit of my homework and read the pipes description twice. So thanks for sharing the link. I’ll take a look and check how pipes can be directly support on our end, I think it’s feasible and I like the idea of these. It’s basically a script w/ the container and some parameters pluis the Bitbucket Cloud Pipeline Extension environment.

Thanks again for all your feedback!