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)


(red squirrel) #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.


(Benjamin Muschko) #2

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


(red squirrel) #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.


(red squirrel) #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.


(Franz Krainer) #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


(Franz Krainer) #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


(Sterling Greene) #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

(red squirrel) #8

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


(red squirrel) #9

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