While developing a parameterized Jenkins Pipeline that triggers a Gradle build I stumbled across some unexpected behavior:
When triggering two Gradle builds on the same machine but from different environments, i.e. having different environment variables being set, I observed that each build seems to use the same environment as its calling process.
At first glance this might be the desired/expected behavior. But then I became aware of the fact that I use the Gradle daemon and things were not that clear anymore. I observed that the builds are executed using the same daemon process. My assumption was, that the environment of a process is basically fixed once started. Nevertheless the Jenkins Pipeline worked as expected, i.e. the re-used daemon process respected the env vars being set be the calling Jenkins Pipeline.
At this point I did not understand why this is working. Questions that came to my mind:
- When I start builds from different environments, can the daemon be re-used, i.e. is it compatible?
- What is the actual environment seen by the build?
- Initial Daemon: env of daemon process when it was started once (this would mean the Jenkins use case would not work)
- Merged: env of daemon process + env of calling process
- Calling Process: just the env of the calling process
In the end I had to analyze the actual behavior, as I did not find any hints in the documentation:
Did I miss something? Maybe wrong assumptions from the first or missed the specified behavior somewhere else in the docs?
I used the following build.gradle to analyze the topic:
task env {
doLast {
System.env.sort().each { println it }
println System.env.size()
println java.lang.management.ManagementFactory.runtimeMXBean.name
}
}