This message was deleted.

However the documentation here confuses me

Put a file that ends with .gradle (or .init.gradle.kts for Kotlin) in the $GRADLE_HOME/init.d/ directory, in the Gradle distribution.

Does this mean, that I cannot use a custom

GRADLE_HOME

env variable?

Correct I think,

GRADLE_HOME

is just a placeholder for the Gradle distribution. If you want to place an init script there, you need to build a custom distribution, or make sure the distribution is at the proper place in the Docker image and add the init script to that.

Or to elaborate on my purpose, is there way I can define an initializtion script at system level. And then allow custom GRADLE_USER_HOME configs so that users can define their own cache directories.

Well, as I said. org-specific configuration you would usually either do by just having a plugin that you apply to all your projects, or by having a custom distribution with an init script that all your projects have to use. Within the Docker image you can as I said of course put it into the unpacked distribution instead of building a custom distribution if always that Docker image is used to run builds. If executing builds locally without Docker should be supported, a custom distribution might be more appropriate. But either way, the projects have to use your custom stuff, either the docker image, or the custom distribution, or the plugin.

Thanks ,that works.. Given this is only a CI specific requirement (of having an equivalent of maven's repository mirrors), I'm inclining towards having this as an init script in the docker image instead of bundling this into a custom gradle distribution. I cannot add this to the unpacked distribution since I'd expect different projects with different gradle versions too. I had initially considered the plugin approach too, but I was trying to set this up in a non intrusive manner.

If it is CI-specific, you could also make sure you call

./gradlew -I yourinitscript ...

For some more context, I'm trying to setup internal mirrors for the repositories that we commonly use. 1. How a project initializes their builds would not be uniform (so I may not be able to enforce the usage of

./gradlew -I

) 2. The gradle distribution and version used may also vary across proejcts 3. The path for gradle user home dir may also vary based on the caching path specified by the project's CI configuration. Seems like an org convention plugin may be the way to go here. Do let me know if you think there could be a better way to handle this.