Improving your Gradle builds
1 like•1,082 views
The document discusses best practices for improving Gradle builds, emphasizing understanding the Gradle model, task execution, and build configuration. It highlights the importance of maintaining clarity in build scripts, using source sets, and properly managing task dependencies to avoid inefficiencies. Additionally, it addresses the significance of user roles in determining the visibility and execution of tasks to enhance build processes.
Improving your Gradle builds
- 1. Improving your Gradle builds Peter Ledbrook e: [email protected] w: http://www.cacoethes.co.uk t: @pledbrook
- 2. “Safety” in build tools "Straight Razor" by Horst.Burkhardt - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons Gradle is often treated like a cut-throat razor: unsafe Code == spaghetti builds (allegedly) Some people think it’s better to limit build authors to configuration only Is this a good comparison though?
- 3. A better analogy by Noel C. Hankamer - Creative Commons 2.0 Not all jobs are the same for a workman Need the right tools for the job Some tools are dangerous - so you learn to use them Power drills, heavy duty knives, etc.
- 4. Gradle Yes, you can create spaghetti builds, but… “A bad workman blames his tools”
- 5. So how do you create maintainable builds?
- 6. First, understand the Gradle model
- 7. Gradle is an API Project Task Repository Dependency Configuration Source set (Java) This is just part of the Gradle model, which allows you to model your own build processes. Show Gradle DSL and API references if possible: http://www.gradle.org/doc/latest/…
- 8. A basic Java build apply plugin: "java" version = "1.0" repositories { jcenter() } dependencies { compile "asm:asm-all:3.3.1", "commons-io:commons-io:1.4" } compileJava.options.incremental = true An instance of Task A Repository
- 9. Everything from Project • project.tasks • project.configurations • project.repositories • project.dependencies • project.sourceSets (added by Java plugin) All the model elements are available from the project The project itself can be accessed via the `project` property
- 10. The three phases Initialisation Configuration Execution Only relevant to multi- project builds Configures tasks and builds the task graph Executes the necessary tasks based on the task graph Beyond the model that defines the build, this is what happens when you actually run that build
- 11. At execution Y X Z => Z X Y W V Linear execution orderTask graph W V During configuration Gradle builds a Directed Acyclic Graph (DAG) of tasks Before execution, the graph is turned into an execution order There is no distinction between targets and tasks like in Apache Ant
- 13. Beware the config phase
- 14. Beware the config phase • Configuration always happens - even just running grade tasks! - this will change soon(ish) • Avoid expensive work
- 15. Profile your build! gradle --profile <taskName> This generates a report with timings for the different phases of each project in the build
- 17. Example apply plugin: "java" ... jar { version = new URL("http://buildsvr/version").text } Evaluated every build! (This will change soon in Gradle) Potentially unreliable network call *every* time the build runs No matter what tasks are executed Gradle will perform configuration on-demand in the not too distant future, reducing the time cost of the configuration phase
- 18. Remember task doSomething << { println "Doing it!" } task customJar(type: Jar) { archivePath = customJarPath doLast { println "Created the JAR file" } } Execution Execution Configuration Consider always using `doLast()` instead of `<<` to avoid confusion between configuration and implicit execution
- 20. Project properties • Useful for build parameterisation • Equivalent to global variables - Same problems! • Provide sensible defaults • Assume values are strings
- 21. Default values ext { jarFilename = project.hasProperty("jarFilename") ? jarFilename : "myArchive" } task customJar(type: Jar) { archivePath = file("$buildDir/$jarFilename") doLast { println "Created the JAR file: ${archivePath}" } } Check property exists first Default value Values can be overridden via -P cmd line option gradle.properties Both only support strings
- 22. Prefer task properties task customClean(type: Delete) { delete "$buildDir/$jarFilename" } task customClean(type: Delete) { delete customJar.archivePath } Use the path defined by the task Don’t let project properties litter your build If the JAR task stops using the project property, `customClean` will continue to work
- 23. Refactoring
- 24. Custom tasks Prefer task doIt(type: MyTask) class MyTask extends DefaultTask { @TaskAction def action() { println "Hello world!" } } task doIt << { println "Hello world!" } } over More verbose, but easier to maintain Easier to incorporate properties in custom task classes Easier to migrate the task implementation out of the build file
- 25. Custom tasks Where the task class goes: 1. In build.gradle 2. In buildSrc/src/groovy/… 3. In a JAR file
- 26. IoC in tasks class MyTask extends DefaultTask { File filePath = project.myArchivePath @TaskAction def action() { println filePath.text } } Don’t pull values from the environment
- 27. IoC in tasks task doIt(type: MyTask) { filePath = project.myArchivePath } Leave configuration in the build file Effectively Inversion of Control - values should always be injected
- 28. Last one… Consider breaking into multiple smaller projects
- 30. Task order vs dependency task functionalTest(type: Test, dependsOn: test) task functionalTest(type: Test) { mustRunAfter test } Do the functional tests require the unit tests to run? Or is it just the order that counts?
- 31. Leverage source sets Instead of configurations { clientCompile } task compileClient(type: JavaCompile) { classpath ... include "src/main/java/**/client/*" } // Don't forget the test tasks and dependencies! ...
- 32. Leverage source sets Use source sets sourceSets { client { java { srcDirs file("src/main/java") include "src/main/java/**/client/*" } } } Get: • clientCompile, clientRuntime configurations • compileClientJava task
- 33. Use incremental build class SignJar extends DefaultTask { @InputFiles FileCollection jarFiles @OutputDirectory File outputDir File keystore String keystorePassword String alias String aliasPassword @TaskAction void sign() { ... } } Changes to these input files or output force the task to run again
- 34. Plugins • Encapsulate your conventions • Package common features • Lightweight alternative: - apply from: "modules/check.gradle"
- 35. Know your users
- 36. Questions to ask • Do you have only one type of user? • What things can each type of user do? • What do they want from the build? • What should they see?
- 37. Example compile test package/install publish project lead only Lazybones project If the project is published, require credentials Fail fast Other users don’t require credentials
- 38. Interrogate task graph gradle.taskGraph.whenReady { graph -> if (graph.hasTask(":lazybones-app:uploadDist")) { verifyProperty(project, 'repo.url') verifyProperty(project, 'repo.username') verifyProperty(project, 'repo.apiKey') uploadDist.repositoryUrl = project.'repo.url' uploadDist.username = project.'repo.username' uploadDist.apiKey = project.'repo.apiKey' } } Only check for credentials if user is trying to publish: Only fail fast if `uploadTask` will be executed Fail slow would require integration tests to run - adding minutes to deployment
- 39. Other uses • Include class obfuscation conditionally • Limit visibility of tasks based on role • Update version based on ‘release’ task
- 40. Summary • Understand the Gradle model • Keep refactoring • Understand your build • Know your users
- 41. Thank you! e: [email protected] w: http://www.cacoethes.co.uk t: @pledbrook