The document discusses strategies for optimizing Gradle builds at Delivery Hero, highlighting the importance of resolving cache issues to improve CI/CD efficiency. It details the challenges faced with increased cycle times and the implementation of various profiling and performance benchmarks. Additionally, it outlines improvements made with the adjustments to the Paparazzi plugin, resulting in significant time reductions for test execution.

1. Optimizing Gradle Builds
Strategies to Identify, Resolve, and Avoid Cache Issues
Sinan Kozak

2. Sinan Kozak
Google Developer Expert
Staff Android Developer @DeliveryHero

3. Fast CI results? Quick local builds?
CI/CD is mostly more centralized in Delivery Hero.
Bigger customer team has splitted infra teams per topic, but
Logistics Tribe has one Mobile Infra.
Practical optimizations with tradeoffs are very critical.

4. Cycle time increase incident - March 24

5. 90+ minutes
Long PR checks are unacceptable

6. What does bad look like?

7. How did it start?
Initial usage
Full migration
Convention plugin
and more tests

8. CI cost and Cycle time had skyrocketed

9. Why didn’t we notice earlier?
We had other planned changes that increased CI time.
● Running lint on test code
● Detect verification per commit

10. Build Benchmark
We use Gradle Profiler on CI to compare times
● Incremental build for ABI and non-ABI changes in critical modules
● Gradle Enterprise scan comparison
We didn’t have profiling for;
● Unit test compile
● Android test compile

11. Impact analysis
Problem grow with number of feature with screenshot test
● Convention plugin and training increased the speed
● 60+ of 450 modules has screenshot tests now

12. PR Check CI steps
● Checkout
● Setup
● Lint + Detect
● Unit Test
○ testDebugUnitTest
● Screenshot test
○ verifyPaparazziDebug
● Coverage
○ JoCoCo + dependOn(Test Tasks)

13. Why does Gradle disable cache for test task?

14. Where are details? What is output $2
-Dorg.gradle.caching.debug=true

15. Let’s investigate
Paparazzi suppose to be fast and run on JVM like any other junit test.
● Yes, it is faster to run.
● Yes, it runs on JVM. We don’t need emulator
● But, but, but…
Paparazzi Gradle Plugin configures the Test task
even for non Paparazzi tests!!

18. What would be nice setup?
● Verify screenshot tests by default
○ Create aggregated report on demand
○ Fail unit test when screenshot test fail
● Make screenshots folder input of tasks for verification case
○ Screenshots are input of verification
● Remove reports path as output. Html report aggregates with every run.
○ Reports are not reproducible.
● Record task is never up to date when we run record

21. 90m -> 35m
~60% improvement after changing a Paparazzi Plugin setup.

22. Don’t modify cacheability of other tasks

23. But our devs never use the report

24. What will we work on next?
More benchmark cases on CI with Gradle Profile
● Unit test and Android Test builds
Make profiling automatic and blocker for certain type of PRs
● Dependency changes
Maintain internal Paparazzi plugin unless they change the defaults
https://github.com/cashapp/paparazzi/issues/1334
https://github.com/cashapp/paparazzi/issues/1365
Gist of modified Paparazzi Plugin
https://gist.github.com/kozaxinan/4b44f817b28ac409f950c041c3627eca

25. Thank you
Q&A?
Sinan Kozak
@snnkzk