How to set up gradle.properties in a Hosted Jenkins environment

I use gradle.properties to use the daemon and to set up a proxy.

According to the User Guide there are three options:

from gradle.properties in project build dir.
from gradle.properties in gradle user home.
from system properties, e.g. when -Dsome.property is set on the command line.

I COULD put this file into every gradle project, but I’d rather not do that.

In my initial work in a non-jenkins environment, I just used the second option and put it in $HOME/.gradle/
(Actually, is that incorrect documentation? The second option is telling me to put it in $HOME, not in $HOME/.gradle, which is where I have it and it works there.)

Whether the second option is in $HOME or $HOME/.gradle, it won’t work for me because I have no $HOME directory. Well, of course there is a home directory ( ~ ) but it’s not my Jenkins instance’s home, it’s the home directory for every Jenkins instance hosted there. And the third option is a path I’d rather not go down either.

So is there any other option for making these settings (BEFORE Gradle starts)?

The “gradle user home” is $HOME/.gradle.

I’m not sure I understand this. The user the Jenkins agent is running as should have a home directory (i.e. /home/jenkins/.gradle). What’s the reason why you can’t place a gradle.properties file there?

As I work with Steve, I’ll put in my POV.

In reality, there probably isn’t any problem at all. In “theory” this Jenkins server is a shared resource, and the resulting $HOME/.gradle/gradle.properties file could potentially be a point of conflict. And when I say “shared”, it could also be used by other groups that have no relation to Steve’s work. On the other hand, at this point in time, it’s possible that Steve has the only Gradle build job in the entire Jenkins infrastructure here. However, not only is Steve the only Gradle user at this point, the team who maintains the Jenkins server doesn’t know very much about Gradle either.

To be cautious, I’m suggesting that he look into specifying a separate GRADLE_USER_HOME in his wrapper. In these technical circumstances, this is probably overkill, but in terms of preventing writing files in “common” places that sysadmins might be unfamiliar with, it may be a prudent action.

It’s a very odd setup, I know. In asking this question I was in part trying to determine just how odd it is. I think you just answered that.:weary:

Basically, there is a team that manages a system for a bunch of teams. Each project has a “data home” where all it’s stuff goes: /home/jenkins/jenkins/{project-name}/data. But that is not the porject’s home directory. Everybody’s ~ is /home/jenkins/jenkins.

Fairly clearly, this was not designed with gradle in mind. And I may go running out of there with my hair on fire. It’s also an option to put jenkins on our team’s own server and I’m leaning heavily toward going that route now. there would have been some initial setup advantages to using their server, but it looks like these are outweighed by these gradle-unfriendly assumptions, unintentional though they may be.

I thought maybe someone would have had experience in working in this type of environment.

I could see the possibility of auto-locating the GRADLE_USER_HOME inside “~/jenkins/{project-name}/data”, but it would have to be done so it would only work that way on the build server, not with normal developer workstations.