Start FreeLog in
SonarQube Cloud | Advanced setup | CI-based analysis | Github Actions for SonarQube Cloud

Analyze your repository with GitHub Actions

On this page

To configure an analysis of your project using GitHub Actions, you should follow the in-product tutorial when creating a new project. When it's time to Choose your Analysis Method during setup, simply select With GitHub Actions. You can also access the tutorials for an existing project by going to Your Project > Administration > Analysis Method.

The tutorial will walk you through the precise steps to set up the analysis but the basic steps are these:

  1. Define the SONAR_TOKEN environment variable in your repository by setting up a GitHub Secret. The SONAR_TOKEN identifies and authenticates you to SonarQube Cloud. The tutorial will provide the precise value for your specific account.
  2. Set the essential analysis parameters, sonar.projectKeysonar.organization, and sonar.host.url. The tutorial will be populated with the correct values for your specific account. These parameters are set differently depending on your project type:
    • In the pom.xml for Java Maven projects.
    • In the build.gradle file for Java Gradle projects.
    • In the SonarScanner command line for .NET projects.
    • In the sonar-project.properties file for other types of projects. You can also add additional analysis parameters to further specify your analysis details (See Analysis Parameters).
  3. Create the .github/workflows/build.yml file that defines the steps of your build. In addition to the usual steps that build your project, you need to invoke the SonarScanner to perform the analysis of your code. This is done differently depending on your project type:
    • A Maven plugin for Java Maven projects.
    • A Gradle plugin for Java Gradle projects.
    • A dedicated .NET scanner for .NET projects.
    • The SonarQube Cloud GitHub Action for C and C++. 
    • The SonarQube Cloud GitHub Action for other projects. The tutorial will provide the specific details for your project type.

The example below shows how you could set up a yml file for a single project.

GitHub Actions for SonarQube Cloud

 The workflow, usually declared in .github/workflows/build.yml, looks something like this:

name: My Test Single Project
on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  sonarqube:
    name: SonarQube
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0  
      - name: SonarQubeScan
        uses: SonarSource/sonarqube-scan-action@v4
        env: 
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

Users have reported that when working with GitHub Actions reusable workflows, your SONAR_TOKEN is not intrinsically passed to the reusable workflow. Even though your SONAR_TOKEN is defined in the source repository, GitHub Actions will output the SONAR_TOKEN value with asterisks (which make it look like it is working as expected), when in fact it is not reusing the value.  

When setting up your GitHub reusable workflow, we recommend using the GitHub feature secret: inherit to completely remove the intrinsic sending of your SONAR_TOKEN.

GitHub Actions for C and C++

This GitHub Action installs the latest versions of sonar-scanner and build-wrapperrequired for C/C++ SonarQube Cloud analysis making the workflow simpler. 

See the GitHub Action readme for more information.

Failing the workflow when the quality gate fails

SonarQube Cloud adds the quality gate status as a GitHub check. You can set up your workflow to fail when the GitHub check is marked as failed.

Analyzing Monorepo Projects: Build Configuration

The example below shows how you could set up a yml file for multiple projects in a monorepo. If you want to analyze a monorepo that contains more than one project ensure that you specify the paths to each sub-project for analysis in your build file. 

To ensure that your monorepo works as expected, you need to build each project in the monorepo separately with a unique project key for each one. 

GitHub Actions .yml file

name: My Test Monorepo Project
on:
  push:
      branches:
      - main
      paths:
      - 'lambdas/test/**'
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  sonarqubeScan1:
    name: SonarQubeScan1
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0  
      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@v4
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        with:
          projectBaseDir: repo1/
          
  sonarqubeScan2:
    name: SonarQubeScan2
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0  
      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@v4
        env: 
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        with:
          projectBaseDir: repo2/

Troubleshooting

Scanner cannot resolve file paths in test coverage report

When using GitHub Action, the SonarScanner fails to resolve the paths within the test coverage report and raises the warning "Could not resolve <n> file paths in <file>". 

You may resolve this problem by switching off relative_paths=True in the coverage settings.  


Was this page helpful?

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Creative Commons License