Adding the SonarQube Community Build analysis to your GitHub Actions workflow
Once you have created your project in SonarQube Community Build, you can add the SonarQube Community Build analysis to your GitHub Actions workflow:
- Configure the project analysis parameters.
- Add the analysis to your GitHub Actions workflows.
- Commit and push your code to start the analysis.
Considerations about upgrading to GitHub Action v4
v3.1.0
and below of the GitHub Action are based on Docker: at every execution of the action, a dedicated docker container is spawned.
The advantage of using container are primarily:
- Isolation, since the SonarScanner gets only access to the directory where the project is checked out.
- Full control of the environment where the SonarScanner is executed, in terms of required utilities such as
wget
andkeytool
.
The use of Docker comes, however, with multiple disadvantages regarding SonarQube analysis:
- Issues with analyzers requiring access to a system-level directory, such as cache of dependencies in Java or Dart.
- Issues with DockerHub rate limit on peak workload scenarios.
- Requirement by GitHub to run as root user.
- Support for Docker-based actions limited to Linux - no support of Windows nor MacOS.
v4
removes the Docker dependency, making the action composite. The action now runs in the environment of the runner executing the GitHub workflow.
Prerequisites
From GitHub Action version v4
- If your runner is GitHub-hosted, all required utilities should be already provided by default.
- If your runner is self-hosted, ensure that the following utilities are installed and available in the
PATH
:unzip
,wget
orcurl
.
If your SonarQube uses certificates
If you use the sonarqube-scan-action for your GitHub Action and your SonarQube Server has certificates that need to be recognized by the GitHub runner, you'll need to set the SONAR_ROOT_CERT
environment variable in GitHub (See Managing the TLS certificates on the client side).
Configuring the project analysis parameters
For general information, see Analysis parameters and the respective SonarScanner section: Maven, Gradle, NET, CLI, and NPM.
The setting of sonar.token
and sonar.host.url
is specific to GitHub Actions: With GitHub Actions, you can configure these parameters through GitHub secrets. This may be done at the global level by the global System Administrator, or at the project level by the Project Administrator as explained below (it makes sense to store the server URL at the global level).
Setting the Server URL and the token in GitHub secrets
The parameters used in GitHub Actions workflows to connect to the SonarQube Community Build (Server URL and token) should be securely stored in GitHub secrets: see GitHub's documentation on Encrypted secrets for more information.
To store the authentication token at the project level:
- In the SonarQube Community Build UI, generate a SonarQube Community Build token for your project.
- Create a repository secret in GitHub with:
- Name: SONAR_TOKEN
- Value: the token you generated in the previous step.
To store the SonarQube Community Build URL at the project level:
- Create a repository secret in GitHub with:
- Name: SONAR_HOST_URL
- Value: <sonarQubeServerURL>
Configuring the build.yml file
This section shows you how to configure your .github/workflows/build.yml
file.
SonarQube Community Build 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 using on.pull_request
.
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:
plugins {
id "org.sonarqube" version "3.5.0.2730"
}
Write the following in your workflow YAML file:
name: Build
on:
push:
branches:
- main # the name of your main branch
pull_request:
types: [opened, synchronize, reopened]
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: Set up JDK 17
uses: actions/setup-java@v1
with:
java-version: 17
- name: Cache SonarQube packages
uses: actions/cache@v1
with:
path: ~/.sonar/cache
key: ${{ runner.os }}-sonar
restore-keys: ${{ runner.os }}-sonar
- name: Cache Gradle packages
uses: actions/cache@v1
with:
path: ~/.gradle/caches
key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle') }}
restore-keys: ${{ runner.os }}-gradle
- name: Build and analyze
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
run: ./gradlew build sonar --info
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:
name: Build
on:
push:
branches:
- main # the name of your main branch
pull_request:
types: [opened, synchronize, reopened]
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: Set up JDK 17
uses: actions/setup-java@v1
with:
java-version: 17
- name: Cache SonarQube packages
uses: actions/cache@v1
with:
path: ~/.sonar/cache
key: ${{ runner.os }}-sonar
restore-keys: ${{ runner.os }}-sonar
- name: Cache Maven packages
uses: actions/cache@v1
with:
path: ~/.m2
key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
restore-keys: ${{ runner.os }}-m2
- name: Build and analyze
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
run: mvn -B verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar
SonarScanner for .NET
Write the following in your workflow YAML file:
name: Build
on:
push:
branches:
- main # the name of your main branch
pull_request:
types: [opened, synchronize, reopened]
jobs:
build:
name: Build
runs-on: windows-latest
steps:
- name: Set up JDK 17
uses: actions/setup-java@v1
with:
java-version: 1.17
- uses: actions/checkout@v2
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: Cache SonarQube packages
uses: actions/cache@v1
with:
path: ~\.sonar\cache
key: ${{ runner.os }}-sonar
restore-keys: ${{ runner.os }}-sonar
- name: Cache SonarQube scanner
id: cache-sonar-scanner
uses: actions/cache@v1
with:
path: .\.sonar\scanner
key: ${{ runner.os }}-sonar-scanner
restore-keys: ${{ runner.os }}-sonar-scanner
- name: Install SonarQube scanner
if: steps.cache-sonar-scanner.outputs.cache-hit != 'true'
shell: powershell
run: |
New-Item -Path .\.sonar\scanner -ItemType Directory
dotnet tool update dotnet-sonarscanner --tool-path .\.sonar\scanner
- name: Build and analyze
shell: powershell
run: |
.\.sonar\scanner\dotnet-sonarscanner begin /k:"example" /d:sonar.token="${{ secrets.SONAR_TOKEN }}" /d:sonar.host.url="${{ secrets.SONAR_HOST_URL }}"
dotnet build
.\.sonar\scanner\dotnet-sonarscanner end /d:sonar.token="${{ secrets.SONAR_TOKEN }}"
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 and C++ SonarQube 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 Community Build quality gate Check Action, you can instruct the scanner to wait for the SonarQube Community Build 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 Community Build 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).
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?