I’m using the tooling API to run acceptance tests for a plugin which I want to operate in isolation from my normal user home directory. I’ve tried both BuildLauncher#setJvmArguments with -Duser.home and adding -Duser.home to the command arguments passed to BuildLauncher#withArguments and neither had an effect.
The tooling API use is proxied by Luke Daley’s “test kit” found here: https://github.com/alkemist/gradle-test-kit. The meat of invocation is here: https://github.com/alkemist/gradle-test-kit/blob/master/src/main/java/org/gradle/testkit/functional/internal/toolingapi/ToolingApiGradleHandleFactory.java
I haven’t wrote the code but this is what I was able to find: when I look at daemon’s log files there are outputs from https://github.com/gradle/gradle/blob/master/subprojects/launcher/src/main/java/org/gradle/launcher/daemon/server/exec/EstablishBuildEnvironment.java#L55 that sets the environment at the beginning of build command processing in daemon. If you use toolingApi then the environment passed to this code comes from
DefaultBuildActionParameters
created in https://github.com/gradle/gradle/blob/master/subprojects/launcher/src/main/java/org/gradle/tooling/internal/provider/DaemonBuildActionExecuter.java#L40 . It means that for each client request the daemon sets an enviroment passed from client. If you want to update HOME and related system properties it can be a problem since I suppose there are things done early during the daemon run and original values can already be spread to various places.