Analyze your repository with GitHub Actions
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:
- Define the
SONAR_TOKEN
environment variable in your repository by setting up a GitHub Secret. TheSONAR_TOKEN
identifies and authenticates you to SonarQube Cloud. The tutorial will provide the precise value for your specific account. - Set the essential analysis parameters,
sonar.projectKey
,sonar.organization
, andsonar.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).
- In the
- 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:
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-wrapper
required 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
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?