“CI is a black box; you don’t know what’s really going on in CI outside of the logs. Even reading the logs is not a trivial job. It’s really hard to parse when you have thousands of lines of logs.”
Staff Software Engineer
Earlier this year, Aurimas Liutikas from the Google AndroidX team joined our DPE Lowdown webcast to talk about how Gradle Enterprise has helped them troubleshoot build and test failures faster in their GitHub Actions CI environment. Since then, we’ve heard from many companies that already use or plan to adopt GitHub Actions as their CI solution and want to understand how Gradle Build Tool and Gradle Enterprise fit into the CI build experience. In this post, we will cover the official Gradle Build GitHub action that the AndroidX team is using to integrate with Gradle Enterprise and some of the build troubleshooting best practices Aurimas shared in his talk.
If your team is using GitHub Actions and struggling to identify the root cause of build failures by combing through CI logs, Aurimas’ story will be particularly relatable. He describes how using the Build Scan™ service from Gradle Enterprise gave the AndroidX team critical insights to quickly zero in on the causes of failures as well as the analytics needed to spot problematic trends in their build process. A Build Scan is like an X-ray for your build. It gives developers deep data on each task or goal, so they can quickly find the root cause of failures. Armed with a Build Scan, developers can fix their problems without re-running broken builds to reproduce issues or requiring the help of the build team.
We’ll also touch on a time-saving Build Scan feature, “View task in console log,” and how the detailed performance tracing helped solve a dependency issue that cut 27 minutes out of the build and test time.
Integrating GitHub Actions and Gradle Enterprise
“It passed on my machine and failed on GitHub Actions, but I didn’t change anything.”
Does this sound familiar? That was the sort of complaint the AndroidX team heard that led them to add Gradle Enterprise to their build and test experience. Integrating Gradle Enterprise into the GitHub Actions CI process started with the Gradle Build Action, a GitHub action that simplifies configuring and running the Gradle Build Tool, leveraging the GitHub Actions cache, and working with Gradle Enterprise Build Scans.
Next, the Gradle build script is updated with a few lines of configuration code to start sending Build Scans to Gradle Enterprise, including GitHub-specific build metadata. Those Build Scans provide the rich context, insights, and failure history needed to identify the root cause of a failure in just a few clicks. The integration makes it possible to directly view a list of all Gradle build failures in a GitHub Actions workflow, and navigate to a Build Scan to learn more about a particular build failure from the GitHub Actions UI and back.
Using Build Scan custom links, it’s easy to navigate to the GitHub source repository and GitHub Actions UI, as well as other Build Scans from the same CI workflow run or associated with the same commit ID.
The failure report, test report, failure history, dependency downloads, and all other information captured by a Build Scan are also easily accessible.
The GitHub Actions UI can be difficult to navigate for workflows that execute many Gradle builds. Another benefit of the Gradle Enterprise integration is a direct link to view all of the builds for a particular GitHub Actions run if you have more than one action configured. In the screenshot below, we’re filtering for a specific GitHub Actions run ID to see all the builds that were part of the same CI workflow.
Troubleshooting GitHub Actions failures with Gradle Enterprise
GitHub Actions failures can be hard to debug. Gradle tasks often don’t provide much information in their failure message, and the data required for analysis is buried deep in the build logs. As the build gets bigger, the logs get longer and can include thousands of lines of text for large projects. Aurimas commented on how challenging this can become:
“If you want to figure out what exactly went wrong with the build you have to go through all of the logs, a variety of logs and, hopefully, on the gray and black screen notice what went wrong.”
For example, here’s a failure as it appears in the build log in GitHub Actions:
Looking at this same build from a Gradle Enterprise Build Scan provides a dramatically better troubleshooting experience. The task failures are listed concisely with a helpful link to “View task in console log” located on the summary page.
Clicking the link filters the entire console log down to just the relevant lines of output, helping to identify the root cause of the failure quickly:
Using Build Scan Performance Insights to cut 27 Minutes off the Build and Test Time
Gradle Enterprise Build Scans capture critical information regarding build infrastructure, dependencies, and performance that are not included in the CI logs alone. In one particular example, Aurimas looked at the Gradle Enterprise Performance dashboard and noticed that the time spent on Dependency Downloads was very high. Gradle Enterprise shows you Dependency Download times as part of the default view of the Performance Dashboard. Aurimas could identify which particular builds had high dependency download times and view a corresponding Build Scan to get the network activity information with one click. The network activity made it clear that the Gradle Build Tool was repeatedly trying to download dependencies from the wrong location. Without Gradle Enterprise, this would have been very difficult to determine. Aurimas wrote a blog post about his troubleshooting process and how resolving the issue cut at least 27 minutes from his CI build time. We encourage you to check it out to get a first-hand account of the experience.
You can watch Aurimas discussing Gradle Enterprise with GitHub Actions on DPE Lowdown here:ARVE Error: Invalid URL
If you are interested in trying out the integrations and tools mentioned above, here are some useful links: