summary: A parallel build that does not require the build master or plugin author to concern themselves with writing thread-safe code. status: Discussions are happening and we will iteratively add features for this after 1.0. code: planned
Every build has plenty of parallelism which Gradle can exploit to complete the build a quickly as possible. For example, the tests for a particular project can be running while its dependent projects are built and tested. Gradle will provide a general purpose mechanism to spread the execution of a build across multiple processes on a given machine, and across multiple processes running on different machines. Gradle will extract the parallelism of a given build based on information already present in the project model (such as the project and task dependencies, task input and output files, and so on). It will do this without requiring that the build master or plugin author concern themselves with writing thread-safe code.
Distributed execution is not just about speeding up the build. It allows a build to use resources without requiring them to be installed on the local machine. For example, a build user can build multiple native versions of an application without needing to run the build on each operating system. Or, functional tests can run against multiple different target platforms that may not be possible or easy to install locally, such as selenium tests which use multiple versions of Internet explorer. Distributed execution also opens up options to make the build independent of location. For example, a build user might be working at home or at a client site, and can use distributed execution to use a build farm at work, which can access internal repositories and other resources.
There will be very little effort involed in maintaining a build farm. The process for adding a build machine will be simple: Unzip the Gradle distribution and run a script to start the daemon. Optionally, you might specify some meta-data about the build machine. The build master will be able to specify in the build script various constraints on this meta-data which a build machine must meet in order to run the build. Gradle will discover and make use of those machines which are available and meet the criteria. Gradle will offer some capabilities for optionally restarting the affected part of build when a build machine failures. Gradle will expose state and operational capabilities over JMX, to allow centralised management.
Security will be baked into the platform. A build user will be authenticated with the build agent, and the build agent authenticated with the build user. Integration with existing enterprise authentication and authorisation infrastructure will be possible. On platforms where it is available, the builds for each build user will run in their own sandbox. Encrypted transport will be used to move files between the build user’s machine and the build agent.
The Gradle team might also look at being able make use of the build agents provided by various CI tools. We will offer tighter integration with various popular monitoring and provisioning tools.