Is it possible to cache gradle daemon to speed up ephemeral CI/CD runs?

[AkselAllas]

In a persistant VM I can get my jib build process down to 6-12 sec thanks to Gradle daemon already running.

In an ephemeral CI/CD Docker container (Github Actions) my build takes 1min29 sec due to Gradle daemon needing to start up.

Would it be possible to somehow cache this Gradle daemon process in Github actions?

[chanseokoh]

Based on what you said, I don't really think it's due to the Gradle daemon starting up. Are you caching Gradle and Maven artifacts? You can use actions/cache.

[AkselAllas]

I have tried actions/cache and gradle-build-action and setup-java

Every result is roughly 1min30sec

Example of uses:

    - name: Setup Gradle
      uses: gradle/gradle-build-action@v2

      - name: Cache Gradle packages and Google Jib cache
        uses: actions/cache@v3
        with:
         path: |
          ~/.gradle
          ~/.cache/google-cloud-tools-java/jib
         key: ${{ runner.os }}-gradle-${{ hashFiles('**/build.gradle.kts') }}
         restore-keys: ${{ runner.os }}-gradle

[joschi]

@AkselAllas How much time of the 1m30s is spent in waiting for the VM to spin up, start the build container, and fetching the configured JDK?

It should be clear that a persistent VM with modest hardware and all files already on disk or even in memory (disk buffer) executes processes way faster than an on-demand VM in which you have to install the runtime environment, download and extract the cache, compile/build changed files.

For reference: https://github.com/gradle/gradle/issues/20449

[mpeddada1]

Thanks for sharing this reference, @joschi