Run gradle build in external CI but publish PR comments in Azure DevOps

SonarQube Cloud
1
  • ALM used (GitHub, Bitbucket Cloud, Azure DevOps): Azure DevOps
  • CI system used (Bitbucket Cloud, Azure DevOps, Travis CI, Circle CI): Bitrise
  • Languages of the repository: Java/Kotlin

We currently run Android app builds using Azure DevOps self-hosted agents. Our pipeline is running in Azure Pipelines and essentially consists of

  • SonarCloud Prepare Analysis task
  • Gradle build - using standard Android Gradle tasks + JaCoCo
  • SonarCloud Run Code Analysis task
  • SonarCloud Publish Quality Gate Result task

We are in the process of trying to migrate the Gradle build only to Bitrise. We will still have VCS and PRs in Azure DevOps, but the actual build will be run in Bitrise. An Azure Pipeline will be linked to the PR build, and this will trigger the Bitrise workflow and check the result.

We are a bit stuck on how to integrate with SonarCloud with the new setup. Some options we have considered are:

  • Retain the “Prepare Analysis”, “Run Code Analysis” and “Publish Quality Gate Result” tasks on Azure DevOps, but using the output of the Gradle build which was run on Bitrise
    • We are able to download artifacts from the Bitrise build into the Azure Pipeline working directory. But we are not sure which artifacts we would need to download in order to make the SonarCloud tasks work. I know we could say “just the entire contents of the build directory”. But to give some context, the build directory after a build is around 1.72GB in size as it includes a lot of intermediate artifacts that Sonar likely doesn’t use. We can see, for example from the logs, it is using /build/intermediates/classes/… - this directory is only 34MB in size. So that would be a huge difference. We don’t know if Sonar might use other directories but it is likely to be a lot less than the entire 1.72GB build directory
    • Even if we could get this option to work, it is not ideal as we want to run Sonar through Bitrise if possible, hence the below two options
  • Remove the SonarCloud tasks from Azure DevOps entirely, and run the SonarScanner directly from Bitrise, using the approach described at Other CIs | SonarQube Cloud | Sonar Documentation and SonarScanner for Gradle | SonarQube Cloud | Sonar Documentation
    • It seems to assume that the SonarScanner will be directly integrated into the Gradle build, which is not the case currently. As I mentioned above, our Gradle build just uses standard Android build tasks + JaCoCo. I don’t know if we would have to refactor our Gradle build to use Sonar tasks in order to use this way
    • Is it able to still publish PR comments to Azure DevOps? If so I am not sure how this is achieved as it’s not mentioned in the docs
  • Similar to above but running the SonarScanner CLI directly in the Bitrise pipeline
    • I am not sure if this is the closest equivalent to the Azure DevOps tasks we currently use. SonarScanner CLI | SonarQube Cloud | Sonar Documentation is saying “The SonarScanner CLI is the scanner to use when there is no specific scanner for your build system” which may not be exactly true as we are using Gradle. Having said that, when looking at the pipeline logs in Azure DevOps, I can see that internally it is indeed running the sonar-scanner CLI command directly
    • Similarly to above, I am not sure how or if we could publish PR comments to Azure DevOps using this way
2

Hi,

Your ability to decorate PRs in ADO is actually independent of where you run analysis. PR decoration happens server-side, and is about where the SonarQube Cloud project is bound.

This is the way.

If you build with Gradle, you should analyze with Gradle. It does require a little configuration but it’s fairly light weight.

The only real caveat here is that you’ll lose the automatic detection from the environment of the branch/PR values, so you’ll need to set those parameters explicitly when they’re needed.

 
HTH,
Ann

3

Hi Ann,

Thanks a lot for your responses. However I have just run a build using SonarQube Gradle plugin on Bitrise. The build succeeded, and the issues are displayed on sonarcloud.io (via the “Pull Requests” screen), but the Azure DevOps PR was not updated with the PR comments for each issue found. How can I troubleshoot this?

Thanks again,
Adam

4

Hi Adam,

Is the SonarQube Cloud project connected to ADO?

Are there any warnings on the screen?

 
Ann

5

Hi Ann,

Which screen would that be?

Yes, the SonarCloud project remains connected to ADO, and SonarCloud still publishes PR comments for builds done within an Azure Pipelines run (using the “Prepare Analysis Configuration”, “Run Code Analysis” and “Publish Quality Gate Result” tasks from the ADO SonarCloud extension). However, as I mentioned earlier, we’re trying to move away from that solution.

Thanks,
Adam

6

Hi Adam,

Do you see warnings anywhere in the SonarQube Cloud UI?

 
Thx,
Ann

9

Hi Ann,

No I don’t see warnings anywhere in the SonarQube Cloud UI. And SonarCloud continues to work normally for CI runs from Azure Pipelines as per my previous message.

I wonder what the “Publish Quality Gate Result” ADO task does? That seems to be the one which actually publishes the PR comments. It is separate from “Prepare Analysis Configuration” task (which downloads the scanner and creates the properties) and “Run Code Analysis” task (which runs the scanner). I have tried downloading the scanner manually and running it, and I get the same result that the issues are visible on sonarcloud.io but not on the PR itself. So I feel there might be some missing step which does the same as whatever the “Publish Quality Gate Result” task does.

Thanks,
Adam

10

Hi,

The Publish Quality Gate task puts the QG results into your pipeline, so you can stop the pipeline if the Quality Gate fails. It’s (unfortunately) entirely unrelated to showing the analysis results in the PR.

I’ve flagged this for more expert eyes.

 
Ann

11

Hi Ann,

As per your earlier advice, I have set the sonar.pullrequest.key, sonar.pullrequest.branch and sonar.pullrequest.base properties in my Gradle build (and similarly when I ran the standalone Sonar Scanner). However I just noticed that in sonar-scanner-azdo/src/common/latest/prepare-task.ts at master · SonarSource/sonar-scanner-azdo · GitHub (the ADO task) you are setting several additional properties not mentioned in your docs, such as sonar.pullrequest.vsts.instanceUrl, sonar.pullrequest.vsts.project and sonar.pullrequest.vsts.repository (VSTS being the “old” name for ADO). Could these be making the difference? If so, how can I know what to set them to?

Thanks,
Adam

14

Hi Ann,

I was able to find the values of sonar.pullrequest.provider, sonar.pullrequest.vsts.instanceUrl, sonar.pullrequest.vsts.project and sonar.pullrequest.vsts.repository by logging them out in an Azure Pipelines run. After adding those properties to my CI config, I was able to run the build with PR decoration from my external CI. So my issue is now resolved :slight_smile:

Thanks,
Adam

15

Hi Adam,

I’m glad you worked through this and thanks for sharing your solution! I know this will be helpful for others.

 
:star_struck:
Ann