Hi everyone 🤗 Our Gradle project has slowly become a mess. An actual ball of spaghetti. Projects depending on projects everywhere with deep paths from our app project to our lowest level project. I tried using a plugin such as this one Graph Assert (https://github.com/jraska/modules-graph-assert) to understand the scale of the problem (it's big) but am struggling to figure out some proper next steps. The goal would be to improve build speeds and enforce a better Gradle graph health going forward. Has anyone faced similar challenges? And would they be able to offer some concrete suggestions for how to plan our way out of this? The project is about 130 modules (Android and Kotlin with some legacy Java) at the moment and takes about 25 minutes to compile on the CI. That's before we start running tests. For example what are some useful things to measure and how? Or what is a repeatable process for refactoring that we can farm it to the entire team including junior engineers that is easy to understand and fool proof? Cheers

Hey hey, are you sure that topology of project is the problem?

I think you'd find this talk relevant Goodness, Gracious, Great Builds of Gradle - Eric Kuck | droidcon San Francisco 2024

Thank you @Adam I'll give that a watch. @Eug thank you also. To be honest that's a really good question. My thoughts were based on how spaghetti like our module graph appears. And how deep. Here's the scan for a recent build. As for what we've done. We've tried to minimise the tests that are run by only running the tests relevant to affected modules on a PR. But other than that nothing much apart from ad-hoc upgrades to build libraries and gradle property changes. I would like to get a lot more serious and rigorous about improving our build times though. So any help is appreciated.

The scan gives quite some insight IMHO. I’m not an expert in reading them, but sorting by longest task I see some tasks that are not compiling tasks but take up quite a bit of time

You have 7m for initialisation and configuration - that is definitely too much for number of modules you have. Looks like you're doing something custom in gradle and that should be fixed.

Those are some very good observations that I'll take back to the team. Agai, thank you everyone for the tips 🤗.

Improving the ball of spaghetti following the guidelines of the plugin you shared always helps (a flat tree with at most 3-4 levels to maximize parallelization of tasks). However I don't think this is your worst problem right now. In the timeline you can see that most of your threads are able to work in parallel most of the time, with not big idle waits, so right now you probably won't see a big improvement with that. As mentioned by others in this thread, your biggest issue here is 7min in configuration phase. It is not healthy to spend 30% of your total build time there. Other than that, what will definitively help you cutting drastically the build time on CI is to enable a remote gradle cache, as avoiding task execution is usually the best way to speed up your builds. You have gradle cache already enabled (and I guess you enjoy it in your local builds), but your CI runners are most likely ephemeral (starting clean, and shut down after each build), so you are not leveraging this on CI, adding a remote cache will help you here. Once you have this, then solving the spaghetti module graph will also make more sense (as the fewer dependencies a module has, the more times it will be reused from the cache).

Thanks @Roldan Galan. I'll look into the caching. Yes I think we have something set up but maybe, as you've noted, not in the best way.