Adding the SonarQube analysis to your GitHub Actions workflow
SonarScanners running in GitHub Actions can automatically detect branches and pull requests being built, so you don't need to pass them as parameters to the scanner specifically. See Branch analysis and Pull request analysis for more information.
To analyze your projects with GitHub Actions, you need to:
- Configure your workflow YAML file.
- You can fail the workflow if the quality gate fails.
- Commit and push your code to start the analysis.
The System Administrator must have set up the connection to the SonarQube Server at the global level: see Setting up the connection to SonarQube for GitHub Actions workflows.
Configuring your .github/workflows/build.yml file
This section shows you how to configure your .github/workflows/build.yml
file.
Set up your workflow according to your SonarQube edition:
- Community Edition: Community Edition doesn't support multiple branches, so you should only analyze your main branch. You can restrict analysis to your main branch by setting it as the only branch in your
on.push.branches
configuration in your workflow YAML file, and not usingon.pull_request
. - Developer Edition and above: GitHub Actions can build specific branches and pull requests if you use
on.push.branches
andon.pull-requests
configurations as shown in the examples below.
Click the scanner you're using below to expand the example configuration:
The errors “Missing blame information…” and “Could not find ref…” can be caused by checking out with a partial or shallow clone, or when using Git submodules. You should disable git shallow clone to make sure the scanner has access to all of your history when running analysis with GitHub Actions.
For more information, see the GitHub Actions Checkout README.
SonarScanner for Gradle
Note: A project key might have to be provided through a build.gradle
file, or through the command line parameter. For more information, see the SonarScanner for Gradle documentation.
Add the following to your build.gradle
file:
Write the following in your workflow YAML file:
SonarScanner for Maven
Note: A project key might have to be provided through the command line parameter. For more information, see the SonarScanner for Maven documentation.
Write the following in your workflow YAML file:
SonarScanner for .NET
Write the following in your workflow YAML file:
SonarScanner CLI
You can easily set up a basic configuration using the SonarQube Scan GitHub Actions:
- To analyze C and C++ code, use the SonarQube Scan for C and C++ GitHub Action. It contains steps required for C/C++ SonarCloud analysis, making the workflow simpler.
- To analyze other languages, use the SonarQube Scan GitHub action
You'll find the GitHub Actions and configuration instructions page on the GitHub Marketplace.
Failing the workflow when the quality gate fails
You can use the SonarQube quality gate check GitHub Action to ensure your code meets your quality standards by failing your workflow when your Quality gate fails.
If you do not want to use the SonarQube quality gate Check Action, you can instruct the scanner to wait for the SonarQube quality gate status at the end of the analysis. To enable this, pass the -Dsonar.qualitygate.wait=true
parameter to the scanner in the workflow YAML file.
This will make the analysis step poll SonarQube regularly until the quality gate is computed. This will increase your workflow duration. Note that, if the quality gate is red, this will make the analysis step fail, even if the actual analysis itself is successful. We advise only using this parameter when necessary (for example, to block a deployment workflow if the quality gate is red). It should not be used to report the quality gate status in a pull request, as this is already done with pull request decoration.
You can set the sonar.qualitygate.timeout
property to an amount of time (in seconds) that the scanner should wait for a report to be processed. The default is 300 seconds.
Was this page helpful?