Do "Analyze a project with GitHub Action" instructions reflect best practice for Gradle builds?

Context: We’re building Java projects with Gradle, and we are in the process of migrating our CI builds from Jenkins to GitHub Actions.

In SonarCloud web UI (Project > Administration > Analysis Method) it is possible to generate an example build workflow to use as a starting point for GitHub Actions.

I have some concerns that the example provided by SonarCloud may not reflect best practice. I’ll explain below.

For Gradle, the suggestion is like this:

  1. Update build.gradle to have this:
plugins {
  id "org.sonarqube" version ""

sonar {
  properties {
    property "sonar.projectKey", "**********"
    property "sonar.organization", "****"
    property "", ""
  1. Create or update .github/workflows/build.yml:
name: SonarCloud
      - develop
    types: [opened, synchronize, reopened]
    name: Build and analyze
    runs-on: ubuntu-latest
      - uses: actions/checkout@v3
          fetch-depth: 0  # Shallow clones should be disabled for a better relevancy of analysis
      - name: Set up JDK 17
        uses: actions/setup-java@v3
          java-version: 17
          distribution: 'zulu' # Alternative distribution options are available
      - name: Cache SonarCloud packages
        uses: actions/cache@v3
          path: ~/.sonar/cache
          key: ${{ runner.os }}-sonar
          restore-keys: ${{ runner.os }}-sonar
      - name: Cache Gradle packages
        uses: actions/cache@v3
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle') }}
          restore-keys: ${{ runner.os }}-gradle
      - name: Build and analyze
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Needed to get PR information, if any
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        run: ./gradlew build sonar --info

The build configures caching for Gradle (Cache Gradle packages step) explicitly. However, my understanding is that this is discouraged - and that previously gradle-build-action was the recommended way to set up Gradle, and now it is the setup-gradle action.

Another question is about caching of ~/.sonar/cache folder - is it safe to reuse the cache across both mainline branch, and pull request build branches? For example, setup-gradle action by default only writes to cache from mainline branch builds, and pull request builds only read from cache.

Edit: A colleague pointed out that actions/cache@v3 is also deprecated - v4 is now the latest.

1 Like


There’s a lot here, and we try to keep it to one topic per thread. Otherwise it can get messy, fast.

I’m not a Gradle expert, so I’m going to flag this part of your post for more expert eyes:


Hello @grimsa,

Thanks for reaching out. I think this Example is indeed outdated and setup-gradle is now a preferred way to configure Gradle.

Just note that the key purpose of this example is to show how to execute a sonar task. For your projects, you might nee d different stages and different configurations, etc

Anyway, thanks for the feedback, we will update the docs.


1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.