DPE University Training

Gradle Build Cache Deep Dive - Runtime API Exercise

This is a hands-on exercise to go along with the Gradle Build Cache Deep Dive training module. In this exercise you will go over the following:

• Practice troubleshooting cache issues due to missing input and output declaration
• Get familiar with using the build cache runtime API

Prerequisites

• Finished going through the build cache runtime API section in Gradle Build Cache Deep Dive

Develocity Authentication

If you haven't already done so, you can authenticate with the training Develocity service by running:

./gradlew provisionGradleEnterpriseAccessKey

The output of the task will indicate a browser window will come up from which you can complete the authentication:

Once the browser window comes up you can enter a title for the access key that will be created or go with the suggested title:

Once confirmed you will see the following message and you can close the browser window and return to the editor:

Scenario

In app/build.gradle.kts there is a task called countSrc, which counts the number of source files and puts the number in app/build/src-stats/num-files.txt.

The task makes use of the CountSrcFiles task type which is in buildSrc/src/main/kotlin/CountSrcFiles.kt. For this exercise we will assume the task type is provided by a third-party plugin and we cannot modify the source.

Both incremental build and build caching does not work with the countSrc task. You will debug why and use the build cache runtime API to address this.

Steps

1. Open the Gradle project in this repository in an editor of your choice
2. Run ./gradlew :app:countSrc task. You will notice the file app/build/src-stats/num-files.txt gets created which contains the count:

3. Run the task again. You will notice the task is not UP-TO-DATE:

4. Create a build scan, ./gradlew :app:countSrc --scan , and look at the details in the timeline. Notice the message that indicates that no outputs were declared:

5. Open the task type in buildSrc/src/main/kotlin/CountSrcFiles.kt. We can see from the task type implementation, as well as the output observed earlier, we need to declare app/build/src-stats as an output directory. We could also be more specific and declare app/build/src-stats/num-files.txt, however in the future the task type may create additional files, so it's more future-proof to specify the directory.

6. Use the build cache runtime API documentation to declare the output directory, call the property outputDir.

7. Run the task twice, it should now be UP-TO-DATE:

8. Now let's check if the task is working with the build cache. Do a clean, then run the task. We expect the FROM-CACHE outcome label, but instead there is no outcome label:

9. Create a build scan and look at the task details in the timeline. Notice the message that indicates that build caching is not enabled for the task:

10. Use the build cache runtime API documentation to enable build caching for the task.

11. Now do a clean, run the task. This should populate the cache. Do another clean and run the task again. You should see the FROM-CACHE outcome label:

12. Now let's check the caching behavior. Do a clean first.

13. Now add a new file under app/src anywhere. There are now 3 files under app/src, one App.java, one AppTest.java, and the new file.

14. Run the task. Check the app/build/src-stats/num-files.txt file, you will see the value 2 still. Also there should have been no outcome label as the action should have executed, however we see the FROM-CACHE outcome label.

15. We need to declare the app/src directory as an input directory. Refer to the documentation to do this. Don't forget to specify the path sensitivity.

16. Now do a clean and run the task. There should be no outcome label and the value in the output file should be correct.

Solution Reference

If you get stuck you can refer to the solution branch of this repository.