Request: Build critical path

[Maragues]

Given a a Baseline critical path, it'd be great if gradle-doctor threw a warning/error if a developer's PR changed the critical path for worse.

This would be specially useful in large teams, where it's really hard to control what devs add in order to get their tasks done, often disregarding metrics like build performance.

Reasoning: When working in android multi-module projects, I wonder how important dependencies amongst modules are. Which modules are blockers to others, where's it's worth to invest time to try to remove the dependency on an expensive-to-build module.

Scan's Timeline view tells you the order in which tasks where run, and you can more or less see the build order, but it would be great it gradle-doctor could print the build critical path.

If this is not the right tool to request this feature, could you point out some documentation to read on the topic?

Thanks

[runningcode]

Hi Maragues, thanks for the feature request. Let me see if I fully understand this request.

Are you asking for a tool to keep track of whether a change made anywhere in the codebase would increase or decrease build times for a "critical path" i.e. assembleDebug? In order to validate this, one would need to make the exact same change to the codebase and then run a benchmark against it. Changing a single file in a module in a base module will definitely slow down the next build that runs but likely won't have an impact on the overall build time of the critical path once this change is cached. In order to validate whether or not the build time was affected by a change to the codebase, one would need to run the exact same changes to the codebase and then perform a benchmark against it. I recommend using the Gradle Profiler for this. https://github.com/gradle/gradle-profiler

I hope that answers your question. Let me know if that was unclear.

[Maragues]

Thanks @runningcode, my question comes more from a frustration of lack of knowing where to invest time when trying to reduce build times

Since we have very little influence on reducing task times on android (kapt is what it is), I had hopes that applying close architecture principles to our module dependencies would allow for more parallelization, thus faster fresh build times

But, after applying the changes shown in the diagram, build scan timeline shows that bluetooth-sdk module is no longer the 1st blocking task, but there's 0 net gain on fresh build times. I assume there's improvement when touching Bluetooth SDK module because we won't have to rebuild Feature 1 and Feature 2 modules. But I'm looking for fresh build times for now.

Ofc the dependency diagram is much more complex, but I hope the idea is conveyed.

In your experience as gradle consultant, from build times perspective, is it worth pursuing breakdown of modules into new -domain modules?

If it is worth exploring this path, I wonder if there's a way

1. To show critical path, so that we can focus on offending modules
2. To warn when a PR breaks closed architecture principles

We are a team of 9 devs, so I dream of a way to keep build times from slowly increasing over time.

[runningcode]

Hi @Maragues I appreciate your question and your interest in the Gradle Doctor. This question has more to do with the Gradle build tool itself than with Gradle Doctor. I suggest you ask this question in the Gradle community slack: https://gradle.com/slack-invite or the Gradle forums https://discuss.gradle.org/ There are many Gradle experts from the community around the world and the Gradle team itself (including myself) which will be willing to help you.

[Maragues]

Thanks @runningcode, you are right this isn't the right place for such requests

I created the following post on the forums https://discuss.gradle.org/t/should-we-break-expensive-modules-into-domain-modules/38710