End goal: Detect if the configuration time for gradle builds goes up and help diagnose why.
Background: We have our own gradle enterprise server which we have started polling for build events across our several hundred projects. One of our projects is pretty large - about 600 sub-projects - and has a highly customized build setup; Our buildSrc is, uh, complex (to use a nice word), with many plugin classes that are applied to all sub-projects. Config time for simple gradle task (e.g. help) was around 2-3 seconds, but in the past month it crept up to over 12s, making working with the build very painful for devs. We were able to find a couple of the main culprits for this by analyzing a few build scans manually, but we want to prevent this in the future by detecting when config time jumps so we can trace it more easily. We hope we can use the emitted events to track the avg config time across builds, and figure out what is taking more time.
The Problem: We’ve been able to figure out events that tell us various parts of the build time, like Settings load time and the Loading Projects time (lines from the build scan’s Performance pane). Calculating the Configuration time itself is a bit harder. The PluginApplicationStarted/Finished events get us close - they tell us elapsed time for configuring a plugin on a particular project (i.e. the Total Time column of the Performance -> Configuration screen in the UI). But that double-counts time if one plugin calls another plugin. We need the time for a plugin itself, minus plugins it calls (again, like is shown in the UI).
Anyone have any suggestions for doing this? Obviously, the information is available because the Build Scan UI shows it. We just need to figure out how to get it from events.
Thanks, e