Gradle 2.12 upto Gradle 3.5: Problem of Gradle Daemon with environment variables (Just tested on windows 7, Testcases [Gradle and Batch files] are added)

Help/Discuss
1

Groovy Class takes Environment variables first time correct and for the second time it uses (most likely from buildCache).Without gradle daemon everything works fine.
This problem appeared in Gradle 3.5.

GradleBug.zip (1.6 KB)

env.bat just sets up the Location (Java and Gradle).
TestCase.bat just run 4 times the same Gradle build file.
runBuild.bat runs gradle file with daemon and takes 1 Parameter (just a string e.g.: ‘ABC’)
runBuild-no-daemon.bat runs gradle file without daemon and takes 1 Parameter (just a string e.g.: ‘FGH’)
build.gradle creates a floder, but also prints out the Paramter.

The second run of runBuild.bat (“runBuild.bat XYZ”) shows the Problem.

2

You mention the build cache here specifically. Is there a reason for it? Did you experience the issue with 3.4 already?

3

Hi,
Build Cache was more a guess, because it looked like(that was the reason for the small project and batch file). Sorry for that, because this was maybe not correct.
We tried to move Gradle Versions in a bigger step. I just compared 2.14.1 with 3.5. I did not check 3.4, till yet but tested now. Same behaviour like in 3.5, so most likely a different issue.
I tested also 3.3 and 2.14.1 (this time with activated daemon (gradle -b %ROOT_FOLDER%\build.gradle configure --refresh-dependencies --daemon). We did not use daemon as default). Also the same behaviour, so most likely problem is more daemon related.

It gets build the first time, everything works like expected, the environment variable is taken.
The second time (build with a different environment variable), the previous value of the environment variable is taken.
This just appears if daemon is activated.

4

So i also tested it with Gradle 2.12 and 2.2.1 and daemon.

Gradle 2.12 behaves like 3.5.

Gradle 2.2.1 behaves like expected. The new environment variable is used.

5

Hi,

is there any update on this story?
we have the strong indication that this is an issue with Gradle Daemon here, right?
we see this on multiple Gradle versions and it is immediately gone when switching off the gradle Daemon.
Any way fwd.? Respectively, is there something so terribly wrong with the program redsquirrel provided so that Gradle Daemon stops functioning correctly?

BR,
Franz

6

Dear Gradle Team, hi everybody,

I wanted to revive this thread and ask for help here from the Gradle core developers.
We have re-read the intro and basics about Gradle Daemon:
https://docs.gradle.org/current/userguide/gradle_daemon.html:
<<<
Running Gradle builds with the Daemon is no different than without.

With the example from above (and as it is unfortunately also the case in our business code), we are proving the contrary.
The application of the Gradle Daemon is not transparent in some cases which are not academic but also realty.

Can somebody pls. help us here and dig into it?
This problematic behavior is keeping us away from modern Gradle versions 3.x because the Gradle Daemon is there enabled by default (the bug in the Daemon is already longer there, as redsquirrel describes) and do not dare trusting it fully.

Thanks!
BR,
Franz

7

The issue is that the environment variables are read into a static variable. The classloaders (and therefore the static state of any loaded classes) are retained between build invocations. This is the intended behavior since Gradle 2.4 and would have been the behavior for some things before that.

The example provided in the OP is a little too simple to know exactly how you’re using the environment variables, but I would suggest either using extra properties that are initialized to the environment variable’s values or making the Globals class an extra property.

Here’s the second option:

class Globals {
  String root =  System.getenv( 'ROOT_FOLDER' ).toString().replace( "\\","/" )
  String gid =   System.getenv( 'GID' )
  String buildResultsGid = "${root}/build/Results/${gid}/demo"
}
ext {
   globals = new Globals()
}

// reference it like:
println "value of ROOT_FOLDER = " + globals.root
8

Changing the code in the described manner solves. The variable contains the correct value, depend on the corresponding environment variable.

9

Thanks for replying and finding a solution without disabling gradle daemon.

10

From the above, I am wondering why preserving static variables between runs is desirable/intended behavior.
This behavior is somewhat un-intuitive to anyone providing plug-ins or the like in a Java-based language, because the assumption would be that a “run” is like a running a Java program - static variables stay only for one run of the program, once it completes, they are cleared.
I understand there are likely performance benefits to this, but I’d be interested to know what led to the choice that was made and if those reasons still hold true a couple major versions later (since we are now in Gradle 5 with recent releases)

1 Like
11

I ran into this specific problem now recently, and it was causing random problems which was hard to pinpoint. We have gradle custom tasks that executes java code with parameters (instead of using a main), the library called in this code relied on some updated environment variables.

After some serious bug hunting, we started to suspect that the environment wasn’t properly transferred/updated from gradle to the java code (and its sub processes). When we finally we disabled daemon with --no-daemon everything worked.

This was with gradle 6.3. Would like to see that the env was consistent between the daemon and the launcher…