We’re running Azure DevOps Server 2020 Update 1.1 with SonarQube extension version 5.8.0
We have a hook from BitBucket Server that kicks off a pipeline in Azure DevOps. The hook sets variables in the Azure DevOps pipeline to indicate which BitBucket PR we’re building, the source branch, and the destination branch.
##[error]Caused by: A pull request analysis cannot have the branch analysis parameter ‘sonar.branch.name’
The problem is that the SonarQube task always sets sonar.branch.name. Normally, this is desired behaviour, but in our case, we’d like to manually set the SonarQube pull request parameters and have sonar.branch.name not be set.
Is this possible, or is these some way to unset sonar.branch.name?
@ganncamp Thanks, Ann I think we’re talking past each other a bit, so I’ll wait for the expert attention on the original question. Thanks again for your replies!
No need to set these variables if you are using the SonarQube Azure DevOps extension, it will take care of this automatically.
For the sonar.branch.name, unfortunately if the default branch of your repo is something else that “master” or “refs/heads/master”, we will not detect it, as we don’t currently have a mechanism to fetch the real one from your BB server.
When we open a pull request in BitBucket Server, we run an Azure DevOps pipeline that builds the branch and commit of the BitBucket pull request.
When we build in Azure DevOps, we’d like to tell SonarQube that we’re building for a pull request, not a branch.
The problem is that the SonarQube Azure DevOps extension automatically configures the build as a branch build, instead of a pull request build, because it doesn’t know that the reason that we kicked off the Azure DevOps pipeline is because a pull request was opened in BitBucket
Do you have any suggestions for working around this?
Ideally, we’d like to be able to tell the SonarQube Azure DevOps extension to not automatically set the sonar.branch.name variable.
@mickaelcaro No, it’s not automatically triggered: The pull request is created in BitBucket Server, and we invoke the Azure DevOps build pipeline via a POST webhook.
The pipeline is using the classic editor, but we could switch to YAML if that would let us work around this issue
The pre-requisites to that though is that you have to setup a connection between your BB server and Azure, when creating your pipeline, there are multiple options on “where you code is”, choosing bitbucket there will allow you to setup that connection.
We don’t really support manual configuration for these specific use cases (analyzing a PR) over the extension itself.
@mickaelcaro Wow, that screenshot looks like exactly what we’re looking for! It appears that Azure DevOps supports triggers for BitBucket Cloud but not BitBucket Server, though
What are the chances of getting an `Automatically configure source branch/PR" option added to the Azure DvOps BitBucket extension? If we had that option and could turn it off, we could set the PR configuration ourselves
Ah, truly sorry about this ! I’m afraid if Microsoft doesn’t support it, It will be hard to do it on our side since we are relying on their webhooks/trigger.
I’m afraid you will probably have to use the Sonar analysis itself, without the extension, and detect on the pipeline if you are within a PR or not to fill in the correct properties. Is that something doable for you ?
@mickaelcaro Is there any way to get the path to the SonarQube executable? (e.g. D:\_vstsAgent\fe0vmc18237-SL1\_wk\_tasks\SonarQubePrepare_15bsadfca1-basd2f-4a2a-a403-89b77a063157\5.8.0\classic-sonar-scanner-msbuild\SonarScanner.MSBuild.exe)