Hi, we have a bunch of composite builds in our rep...
# community-support
g
Hi, we have a bunch of composite builds in our repository, and want to set up the gradle cache to make them faster. when we run our PR checks, each project runs the same build cache setup logic. since establishing the environment where we run (is it on CI? is it on desktop? is it in a docker container? which branch is it? etc.. ) can take some time, i am looking into options on how to just do just once, and not run those checks for every project... now it seems that i can calculate what i need, and store it with
System.setProperty
- and if i do, every other project can just check if the property is set, and if it is, use it, and not do the calculations. this actually works, the checks run only once, yay. however this solution feels a bit hacky, as it is kind of circumventing gradle to pass along the information. the question is, are there some alternatives that are better for this use case? we are currently using
8.11.1
- is this solution still going to be viable in later releases?
a
I'm curious about the time these checks are taking. Are they that significant? How much time are you trying to save per build?
Aside from that, using
System.setProperty
is probably fine, even if it's not 'idiomatic Gradle'. If you wanted another option I'd suggest using a shared BuildService. (Just watch out for https://github.com/gradle/gradle/issues/17559!) The BuildService can compute the values once and then share them across subprojects (though not across included builds).
Alternatively, you could create an init script that computes the values once and then stores the values into each project, e.g.
project.extensions.add("isCi", false)
. (I'm not sure how it'd work with included builds though.)
g
it's a handful of seconds total, and that's kinda fine on a CI build, but very not fine on the developer's laptop... 😕 ill go ahead with the system property for now, as we have included builds and not subprojects.
a
I understand, it would definitely be beneficial to avoid that. Do your projects have configuration cache enabled? That should avoid re-computing the values.
g
unfortunately no, we still use a lot of stuff that are not supported by the configuration cache 😕