On 30/07/2012, at 2:33 AM, Luke Daley wrote: > I'm pretty sure that these changes will fix the Windows CI failures. > > The root cause was the introduction of the migration plugin integration test. > The migration plugin uses the tooling API, so starts a daemon. It wasn't > passing on the custom user home dir we use and wasn't inheriting the lower > TTL we use for integ tests. > > Users of the tooling API not doing > https://github.com/gradle/gradle/commit/e175d4298a3e6d287511dc5fcd55731656c6d814 > is going to be a common trap. I think we can fix this by fixing > http://issues.gradle.org/browse/GRADLE-2405 and having Gradle set > -Dgradle.user.home on startup if the user home was set with -g and not the > sys prop.
We want to fix things so that when you run a build using the tooling API from inside another build, you inherit some defaults from the build environment that was used to launch the containing build: the default Java runtime, default Gradle version, default user home. Possibly jvm args (you could make a case either way for jvm args). I don't think setting system properties is the right way to implement this. It's too flakey. There are 3 things going on here: 1. To run a build, each Gradle launcher assembles a model of the build environment that should be used, and then invokes the build. We currently have 5 launchers: the 'gradle' script, the 'gradlew' script, the GUI, the GradleBuild task, and the tooling API. 2. Each Gradle launcher provides various launcher-specific ways to influence the build environment. For some launchers, this includes picking things up from the process's environment, and for others it does not. So, the scripts use things like $GRADLE_OPTS, $JAVA_HOME, --gradle-user-home, -Dgradle.user.home. The tooling API uses method calls to configure the build environment. 3. When a build is launched from within another build, we want to use the build environment model from step 1. to set up some defaults for the build environment model of the new build. The GradleBuild task does this, and the tooling API should do this too (this is the missing piece). It's important that step 3. use the model from step 1, rather than one of the launcher-specific mechanisms from step 2 (e.g. the gradle.user.home system property). There are a bunch of ways that the process environment and the launcher of the containing build can influence the build environment model, and by using the model explicitly, we detangle all the rest of the code from the launcher specifics. > > Begin forwarded message: > >> From: GitHub <[email protected]> >> Subject: [gradle-scm] [gradle/gradle] e175d4: When running the >> CompareGradleBuilds task, ensure ... >> Date: 29 July 2012 4:14:40 PM GMT+01:00 >> To: [email protected] >> Reply-To: [email protected] >> >> Branch: refs/heads/master >> Home: https://github.com/gradle/gradle >> Commit: e175d4298a3e6d287511dc5fcd55731656c6d814 >> >> https://github.com/gradle/gradle/commit/e175d4298a3e6d287511dc5fcd55731656c6d814 >> Author: Luke Daley <[email protected]> >> Date: 2012-07-29 (Sun, 29 Jul 2012) >> >> Changed paths: >> M >> subprojects/migration/src/main/groovy/org/gradle/api/plugins/migration/CompareGradleBuilds.groovy >> >> Log Message: >> ----------- >> When running the CompareGradleBuilds task, ensure the daemon uses the same >> gradle user home as the current build. >> >> >> Commit: bd34b3f1b053352c7d88f4c86b020ede5221d3bb >> >> https://github.com/gradle/gradle/commit/bd34b3f1b053352c7d88f4c86b020ede5221d3bb >> Author: Luke Daley <[email protected]> >> Date: 2012-07-29 (Sun, 29 Jul 2012) >> >> Changed paths: >> M subprojects/docs/src/samples/toolingApi/eclipse/build.gradle >> M >> subprojects/docs/src/samples/toolingApi/eclipse/src/main/java/org/gradle/sample/Main.java >> M subprojects/docs/src/samples/toolingApi/idea/build.gradle >> M >> subprojects/docs/src/samples/toolingApi/idea/src/main/java/org/gradle/sample/Main.java >> M subprojects/docs/src/samples/toolingApi/model/build.gradle >> M >> subprojects/docs/src/samples/toolingApi/model/src/main/java/org/gradle/sample/Main.java >> M subprojects/docs/src/samples/toolingApi/runBuild/build.gradle >> M >> subprojects/docs/src/samples/toolingApi/runBuild/src/main/java/org/gradle/sample/Main.java >> >> Log Message: >> ----------- >> Ensure the Tooling API samples inherit the daemon settings when running the >> sample code. >> >> This prevents the daemons from hanging around and ensures they use the test >> Gradle user home. >> >> >> Commit: aefca7976f11fb61e289e33f58f48b16173b03d2 >> >> https://github.com/gradle/gradle/commit/aefca7976f11fb61e289e33f58f48b16173b03d2 >> Author: Luke Daley <[email protected]> >> Date: 2012-07-29 (Sun, 29 Jul 2012) >> >> Changed paths: >> M >> subprojects/internal-integ-testing/src/main/groovy/org/gradle/integtests/fixtures/AbstractGradleExecuter.java >> M >> subprojects/internal-integ-testing/src/main/groovy/org/gradle/integtests/fixtures/DaemonGradleExecuter.java >> M >> subprojects/internal-integ-testing/src/main/groovy/org/gradle/integtests/fixtures/GradleExecuter.java >> M >> subprojects/tooling-api/src/integTest/groovy/org/gradle/integtests/tooling/SamplesToolingApiIntegrationTest.groovy >> >> Log Message: >> ----------- >> Make the daemon idle timeout specifiable on all executers. >> >> Any Gradle build can potentially spawn daemons, no matter how it was >> invoked, so this needs to be specifiable at this level. >> >> >> Commit: 1f7d26f7c7fb668f4900b25dd8fa2353792f0120 >> >> https://github.com/gradle/gradle/commit/1f7d26f7c7fb668f4900b25dd8fa2353792f0120 >> Author: Luke Daley <[email protected]> >> Date: 2012-07-29 (Sun, 29 Jul 2012) >> >> Changed paths: >> M build.gradle >> M >> subprojects/internal-integ-testing/src/main/groovy/org/gradle/integtests/fixtures/AbstractGradleExecuter.java >> >> Log Message: >> ----------- >> Change the default daemon idle timeout during int tests to two mins. >> >> >> Compare: https://github.com/gradle/gradle/compare/5357c277191c...1f7d26f7c7fb >> >> >> <hr/> >> <p> >> To unsubscribe from this list please visit: >> </p> >> <p> >> <a >> href="http://xircles.codehaus.org/manage_email";>http://xircles.codehaus.org/manage_email</a> >> </p> > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
