Setting Up SonarQube Code Quality Checks in GitHub Actions

SonarQube analysis in GitHub Actions runs after tests complete and uses the Quality Gate API to either pass or fail the build based on code quality thresholds. The setup involves SonarCloud (hosted) or a self-hosted SonarQube instance, the Maven/Gradle SonarQube plugin, and a token stored as a GitHub secret.

Analysis configuration

• Add sonar.projectKey, sonar.organization (SonarCloud), and sonar.host.url to sonar-project.properties at the repository root — this avoids cluttering the mvn command with many -D properties and makes the configuration visible in the repository
• The SonarQube token goes in GitHub Secrets (SONAR_TOKEN); mvn sonar:sonar -Dsonar.token=${{ secrets.SONAR_TOKEN }} injects it for a single command without it appearing in logs
• Run mvn verify sonar:sonar in one command so JaCoCo executes and produces the coverage report before the sonar goal reads it — the coverage report must exist at analysis time; running sonar in a separate step after a step that did not produce the exec file reports zero coverage

PR decoration

• For pull requests, pass sonar.pullrequest.key=${{ github.event.pull_request.number }} and sonar.pullrequest.branch=${{ github.head_ref }}; SonarCloud annotates the PR with inline comments on changed lines that introduce issues
• PR analysis runs against only the changed code, not the full project — the Quality Gate for a PR checks new code quality, not the full project baseline; this is the intended behavior and makes the gate meaningful on incremental changes

Quality Gate results

• The GitHub Actions SonarQube Quality Gate action (sonarsource/sonarqube-quality-gate-action@master) polls SonarQube after analysis and fails the step if the gate status is not OK
• Without the quality gate check step, analysis runs but never blocks the workflow — teams see the results in SonarQube but nothing stops a merge; add the quality gate action and make the CI job a required status check to close that gap