Profile a build - to see which tasks were cached and which ones weren’t
If you are using Bitrise Build Cache and you build the same commit two times you shouldn’t see any long running Gradle tasks, most tasks should be served from the cache. If you rebuild the same commit and still see long running gradle tasks then something is preventing Gradle to reuse the previous task run result. To see which Gradle tasks weren’t served from build cache and took a long time you can enable Gradle’s profile feature.
We recommend starting with our guide on Debugging and optimizing Bitrise Build Cache for Gradle if you haven’t read it yet.
Profiling a Gradle build means running the Gradle task with --profile flag, so Gradle generates an HTML build profile report.
To do this (and to be able to access the HTML profile) you have to do 2 things:
- Add the
--profileflag to thegradletask you want to profile - And add a new
Deploy to Bitrise.iostep to the workflow and specify the location of the profile directory Gradle generates, so you can then download the generated profile once the build finishes.
Let’s go into the details and do these step-by-step.
If you use Bitrise steps then you can add the --profile flag in the step’s Additional Gradle Arguments input:
or if you use the official Gradle Runner step then add the --profile flag in the Additional options for Gradle call input:
If you run gradle in a script step then just add the --profile flag to the end of the gradle call, for example: ./gradlew assembleDebug --profile
To be able to access the report add a new Deploy to Bitrise.io step to the workflow after the Android/Gradle step, and set Deploy directory or file path input of the step to $BITRISE_SOURCE_DIR/build/reports/profile and the Compress the artifacts into one file? input to true :
This step will compress (zip) and attach the build/reports/profile directory to the Bitrise build.
Save the changes and run a new build. If everything went correctly you should see a new artifact on the Artifacts tab called profile.zip
Download this profile and open the html file from it. You should see something like this:
Click on the Task Execution tab:
From this list you can see which tasks took the longest, and which ones were served from cache (FROM-CACHE on the right side) and which ones weren’t but could have been (the tasks where there’s nothing under Results).
Once you identified the gradle task which took the longest and was not served from cache but could have been (noting under Results listed for the task) you can narrow down your investigation to that gradle task in your code, to see what prevents it from being cached properly. You should first check the things listed in the What things can cause Gradle Build Cache to be ineffective section, but if you want to dig deeper you can also check Gradle’s cache debug logs - for this keep reading the Debug a specific Gradle task section below.