Accelerate
Troubleshoot
Observe
Although ephemeral builds can be nice to test changes in isolation, there are trade-offs for doing so. One of those trade-offs is dependency download times.
In Develocity 2019.3, the dependency download metrics in the performance and trends dashboards can be used to look at dependency download times and debug issues. For example, let’s look at the dependency download times for the Gradle project itself for all builds run in the last four weeks.
Dependency download trends for all builds of the Gradle project over the last four weeks
There a few small spikes on August 18, 24, and 31, but overall the average dependency download time of 1.76 seconds is quite good. Even the small peaks don’t go above 6 seconds, and the fact that those peaks only show under the 95th percentile means there are just a few much longer builds raising the average. These calculations include a large number of builds mostly run on the same workspaces with caching enabled so the average remains quite low.
If instead, we filter the search results to look at just the clean builds run as part of the `readyForRelease` process, we see a different picture.
Dependency download trends for builds running clean and tagged with ‘readyForRelease’ over the last 4 weeks.
Now, the average time is 31.15 seconds with several peaks above 2.5 minutes. If we want to see which builds are contributing to this average, we can switch to the Performance tab and click on the ‘Dependency downloading’ button at the top.
Performance dashboard for ‘readyForRelease’ clean builds zoomed in on August 18th midday.
If we click one of the columns, we get a detailed view of that build. In this case, it took 3 minutes and 22 seconds to download all the dependencies.
Going to the build scan, we can see on the Network Activity tab that there were over 1000 files downloaded at a speed of 1.5 MB/s.
This is only necessary on the first run though. The next run of that same task in that workspace was much shorter because it didn’t need to spend that time downloading the dependencies.
When a release process is initiated, a large number of checks are added to the build queue and then an autoscaling process adds new build agents to the pool to accommodate them. Therefore, this build and many of the ones adjacent to it took longer to download dependencies because they ran on a clean workspace.
There are cases like this where running from a clean workspace is necessary, but as we saw in the first graph, the overall average stays low because this doesn’t happen very often. If instead, you choose to use a new environment every time you run a build, as is the case for ephemeral builds, you’re significantly increasing the average build time, and your trends will look more like the ones in the second graph.
Also worth mentioning is that the 3-minute download number is for Gradle’s already optimized setup. We run in a highly modularized environment and distribute build execution across many different agents. If your build is larger, highly coupled, or more complex, there may be a much higher cost for downloading dependencies. If you would like to analyze your own builds and the amount of time they spend downloading dependencies, upgrade to Develocity 2019.3 or start a free trial today.