Gradle home cache in Git repository?

Hi Guys,

I’ve hit a snag in our development related to the gradle home cache and would like to know if what I’m trying to do simply isn’t possible, or if there’s an alternate way to go about it.

To give you some background, we build dynamically generated Android apps on a server (multiple build servers and build jobs), which results in thousands of different apps being built. The Android builds are initiated from a java app which does some initial work which then calls the generated project’s gradle wrapper (gradle isn’t installed on the server). The generation of the project is a combination of gradle and ant scripts. Only the final compiled app (.apk) is saved when the build completes.

The goal was to provide the gradle cache (gradle home cache) as a component of our product’s git repository so that each app’s dependencies don’t have to be downloaded every time a build is performed since there will be a finite set of dependencies that would be required by apps built with our product. The cache would be populated manually on a linux system containing the same folder structure and all of the possible dependencies required and committed to the git repo before deploying the product. This would occur every time a service release was required/deployed.

So what I’ve done is defined a folder in the repository to serve as the gradle home and used that for the build process by passing it’s location using --gradle-user-home. All works well except that I’ve noticed that this folder’s contents changes on every new build, in particular, new folders are created in:

/gradle_home/caches/2.8/scripts/

And the modules lock file changes:

/gradle_home/caches/modules-2/modules-2.lock

I’m not really sure of the full effects or what kind of issues would result from it, but I suppose one possibility would be to ignore the modules-2.lock change, and delete the contents of “/gradle_home/caches/2.8/scripts” after each build, leaving the modules there.

So is there some way to go about having a gradle home cache that doesn’t change with every app’s build after it has been initially populated? Again, the goal is simply to prevent having to download the dependencies every time for every app. Any help or guidance would be greatly appreciated.

Darryl

From what I understand you are trying to create an offline repository. One option you have is to create the repository programmatically with the help of the Artifact Query API. This gist should give you an idea. After creating the repository you can simply point your build to the directory that holds the dependencies e.g. the following code (assuming it’s a Maven repo):

repositories {
    maven { url 'file://...' }
}
1 Like

@DarrylIR If want to build an offline repository, you can look at the ivypot plugin.

@bmuschko I like your Gist, would you mind if I try to adapt it into Ivypot? It might solve one specific problem I have at the moment.

Thanks for the responses and links guys. I think I’ll have to do some further testing/research to see how local repositories work as well as the offline mode related to caching/mapping. Creating a true offline environment probably isn’t really what I’m looking for since if for whatever reason a dependency is missing, the build will fail. So in that instance, having it download the missing dependency during the build wouldn’t be a bad thing (versus a failure). While in theory if everything is setup properly that scenario should never occur but…

Really the main issue in this situation is the fact that caching information is stored in the gradle home directory on a per project basis. Every Android app build is performed in a new unique temporary directory that is destroyed after the build, so any caching information is irrelevant.

After my initial post, I did some testing by deleting the “/gradle_home/caches/2.8” folder and the “/gradle_home/caches/modules-2/modules-2.lock” file after each build, leaving the modules in tact. From what I can tell, that does appear to work as it finds the modules and doesn’t download anything. Would there be any potential issues with going this route that I haven’t encountered based on my testing, ie. my tests are flawed?

Darryl

@Schalk_Cronje Don’t mind at all. Free to use it.