Gradle option `--parallel` has no affect when running on GitHub

[tglaeser]

Using gradle/gradle-build-action to run Gradle with switch --parallel seems to have no affect compared to without it. E.g.

name: Run Gradle on PRs
on: pull_request
jobs:
  gradle:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
    runs-on: ${{ matrix.os }}
    steps:
    - uses: actions/checkout@v3
    - uses: actions/setup-java@v3
    - uses: gradle/gradle-build-action@v2
    - name: Execute Gradle build
      run: ./gradlew build --parallel

will result in the same performance as without --parallel.

Is this as expected? Anything that can be done about that?

[bigdaz]

There's nothing in the gradle-build-action that would be directly impacting this. If this is indeed the case, it's more likely due to the number of CPUs being detected on the runner, since this will impact the default parallelism of a Gradle build.

A few things you could try:

1. Compare the performace running with and without --parallel, without using the gradle-build-action
2. Try setting --max-workers=X since this will override the default, which is based on the number of CPUs detected on the machine.
3. Generate (and share) a Gradle Build Scan so you can visualize the parallelism of your build.

[tglaeser]

Thanks. I actually did (1) and (2), but on my local machine only. Now here the numbers from the CI machine:

gradle clean dependencyReport build --parallel --max-workers=8

^ 3m 58s

gradle clean dependencyReport build

^ 5m 31s

jobs:
  integration:
    steps:
      - uses: gradle/gradle-build-action@v2
        with:
          arguments: clean dependencyReport build --parallel --max-workers=8

^ 5m 48s

jobs:
  integration:
    steps:
      - uses: gradle/gradle-build-action@v2
        with:
          arguments: clean dependencyReport build

^ 8m 44s

Generally, it seems that execution via the GitHub Gradle action adds quite some overhead compared to the direct execution from the command line.

[bigdaz]

Try splitting your workflow with a separate "Setup Gradle" step as demonstrated in the first example in the README: https://github.com/gradle/gradle-build-action#use-the-action-to-setup-gradle. This will (almost) completely separate the overhead of the gradle-build-action (like saving/restoring the Gradle User Home) from any overhead on the Gradle build execution itself.

You'll then have timing for the different steps which should provide some more insight.

[bigdaz]

If the actual Gradle execution is significantly slower, then a Build Scan is the best way to diagnose what's going on.

[tglaeser]

I see; thanks. Unfortunately, this did not make any difference whatsoever. I'm also hesitating to do the Build Scan as this repository is private hosted on GitHub Enterprise.

[bigdaz]

I see; thanks. Unfortunately, this did not make any difference whatsoever.

I'd be interested to see the actual numbers of this experiment. Can you share the timing for comparing with and without the gradle-build-action?

eg

jobs:
  without-build-action:
    steps:
      - name: "Run Gradle"
        run: ./gradlew clean dependencyReport build
  with-build-action:
    steps:
      - name: "Setup Gradle"
        uses: gradle/gradle-build-action@v2
      - name: "Run Gradle"
        run: ./gradlew clean dependencyReport build
  with-build-action-and-cache-disabled:
    steps:
      - name: "Setup Gradle"
        uses: gradle/gradle-build-action@v2
        with:
          cache-disabled: true
      - name: "Run Gradle"
        run: ./gradlew clean dependencyReport build

Note that I'm interested in the overall timing for each Job, as well as the difference between the different "Run Gradle" steps. Any extra information would be useful to determine what is the overhead of applying the gradle-build-action. Once this picture is clearer, we could see if --parallel has any differential impact.

[tglaeser]

I'd be interested to see the actual numbers of this experiment.

OK, I did run this twice, following are the numbers from the second run. Each job ran on it's own dedicated actions runner of identical spec.

without-build-action: steps:

• name: "Run Gradle" 8m 59s with-build-action: steps:
• name: "Setup Gradle" 0s
• name: "Run Gradle" 8m 59s with-build-action-and-cache-disabled: steps:
• name: "Setup Gradle" 0s
• name: "Run Gradle" 9m 1s

[tglaeser]

Adding --parallel --max-workers=8 to the 3 "Run Gradle" steps reduces the runtime to 5m 57s ± 1s .

[bigdaz]

Thanks so much for taking the time to get these numbers. My interpretation is that the gradle-build-action is adding very little overhead to the Gradle execution times, which is what I expect.

Adding --parallel is providing some benefit, but the runner hardware is likely a limiting factor.

[tglaeser]

Thanks for spending the time on your side.

Thinking a little more about this, I'm starting to think that the limiting factor is probably the network bandwidth. Our GHES is hosted in Europe while the runners are hosted in the US.

Thanks again, feel free to close the ticket.