Using Gradle Enterprise to Detect Configuration Regressions in an Android Gradle Build
Article Summary
Premise's mobile team caught a sneaky 3x build time regression that only showed up in CI. Here's how they hunted it down using Gradle Enterprise.
Android engineer Nate Ebel walks through a real debugging case study where PR builds suddenly slowed by 20%. The culprit? An AGP update that silently downloaded a 2GB NDK on every CI run.
Key Takeaways
- Gradle Enterprise trend data revealed 3x configuration time spike in GitHub Actions
- AGP 4.1 changed default NDK version not preinstalled on CI machines
- Pinning NDK versions across modules eliminated redundant 2GB downloads
- Created automated workflow to catch configuration regressions before merge
- gradle-profiler benchmarking isolated configuration time as the bottleneck
By consolidating NDK versions in a precompiled script plugin and monitoring configuration time, Premise eliminated a hidden regression that was costing 20% on every PR build.
About This Article
Premise's PR builds got 20% slower in GitHub Actions CI due to Gradle configuration time tripling, but local builds stayed fast. This made it hard to track down without proper monitoring in place.
Nate Ebel's team dug into Gradle Enterprise buildscan logs and found that AGP was downloading a 2GB NDK version during configuration. The NDK version wasn't pinned consistently across modules, so they fixed it with a precompiled script plugin that standardized the versioning.
After pinning the NDK version and setting up automated monitoring through scheduled GitHub Actions workflows, Premise stopped the slowdown and caught similar configuration regressions before they made it into code review.