https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# configuration-cache
s
This message was deleted.
v
Did you set an encryption key?
m
Yes I did, generated it with;
Copy code
openssl rand -base64 16
Using sample job:
Copy code
- name: Run ktlint
        uses: gradle/actions/setup-gradle@v3
        with:
          gradle-home-cache-cleanup: true
          cache-encryption-key: ${{ secrets.GRADLE_CACHE_ENCRYPTION_KEY }}
          arguments: ktlintCheck
v
Hm, no idea then, didn't play with that yet. Maybe you could publish the CC report as artifact and then have a look at what caused the cache miss. 🤷‍♂️
👍 1
j
@Marcin Robaczyński you likely need to cache the 
build-conventions/build
folder. You should be able to tell the gradle build action to add it to the list of cache directories
m
Thanks @Jason Pearson - did try it some time ago and unfortunately I'm still missing something: https://github.com/gradle/actions/issues/21
Basically tends to result with
Copy code
Calculating task graph as configuration cache cannot be reused because an input to plugin 'org.gradle.groovy-gradle-plugin' has changed.
j
It looks like you were trying to cache a subfolder of build, you really do need to cache the entire build folder for it to work.
Ran into the same issue in September
m
Sorry the snippet I posted over there contains only a subset indeed - I did try however with caching the entire thing:
Changing path to 
build-conventions/build/
either successfully reuses the configuration or fails with:
j
ah I see - hrm
feels like its missing part of the gradle user home, will check my lists
v
But shouldn't the action just support it now without extra configuration besides the encryption key?
j
the convention plugin case required some extra caching rules before the env variable, that’s still a special case from what I can see
v
Building convention plugins should be skipped when the CC is reused, shouldn't they?
j
🤷 all I know is that CC gets invalidated when that build directory is missing and specifically mentions file system inputs + the name of the build convention plugin module. Skipping building them makes sense if CC is reused, but if they’re also an input it breaks CC reuse.
m
It seems like build-logic is compiled first and only then the configuration phase runs
💯 1
j
Fwiw my experience in this area is strictly with Kotlin DSL Gradle. Could be that Groovy build convention plugins don’t have this issue
v
It seems like build-logic is compiled first and only then the configuration phase runs
Would really wonder. Probably more what Jason said, that the files must be there for CC to be reusable. If CC is reused, build logic building is also skipped like practically everything else before execution phase, also including settings script execution, init script execution, ....
j
^ that jives with what I’ve seen
The full list of directories we were caching with Gradle 8.4-rc3 back in September with Kotlin DSL Gradle build scripts + convention plugins:
Copy code
// Hack for CC with keystore
~/.gradle/caches/<gradle.version>/cc-keystore

// Gradle Kotlin DSL
~/.gradle/caches/<gradle.version>/kotlin-dsl
~/.gradle/caches/<gradle.version>/generated-gradle-jars

// Seems required for Configuration Cache dependency inputs
~/.gradle/caches/modules-2
~/.gradle/caches/jars-9

// Maybe not needed?
~/.gradle/caches/transforms-3

// Project .gradle dependency-accessors and other undefined things
<project-dir>/.gradle/<gradle.version>

// The configuration cache entry
<project-dir>/.gradle/configuration-cache

// convention plugins
// safe to delete the `kotlin` dir in build, not needed for CC
<project-dir>/<build-convention-dir>/build
So @Marcin Robaczyński looks like you should try adding the 
.gradle/<gradle-version>
dir and see if that helps, I’m now remembering something about the dependency-accessors folder within that which ended up being necessary. Figured this out with trial and error deleting folders and seeing if CC reuse happened
👍 1
3 Views
Open in Slack
PreviousNext
Powered by