Next DevProdEng Lowdown (Webcast) features LinkedIn on how they do DPE – Dec 9, 10:00 AM – 11:00 AM PST. Learn more.
OSS Projects Revved Up by Gradle Enterprise
Gradle is proud to support key open-source projects with FREE instances of Gradle Enterprise.
Gradle Enterprise is quickly emerging as a de facto standard tool for build and test data analytics and as a source of acceleration technology for many of the most important open source projects. Here is a roundup of OSS projects that rely on Gradle Enterprise to improve build and test feedback cycle times and make troubleshooting more efficient by combining root cause analysis data with failure analytics.
Spring is the world’s most popular Java framework for making Java programming quicker, easier, and safer for everybody. Gradle Enterprise is being used by the Spring Boot, Spring Framework, and Spring Security projects. After the Spring Boot project migrated from Maven to the Gradle Build Tool and further optimized the Build Cache effectiveness with Gradle Enterprise, CI builds now take roughly 20 minutes on average, 3-4 times faster than before. Local builds are taking an average of 2.5 minutes, which is 20-30 times faster than before. The team has also started looking at Gradle Enterprise Failure Analytics to address flaky tests and other avoidable failures.
JetBrains Kotlin is a general-purpose, free, open source programming language initially designed for the JVM and Android and is the most used programming language for building JVM applications after Java. The JetBrains Kotlin Compiler open source project is built with Gradle Enterprise about 60,000 times every month. Gradle Enterprise was used to reduce median build time from about 10 minutes to about 3.3 minutes. JetBrains made their custom tasks cacheable and also optimized the configuration phase of the build with the help of Build Scan insights.
JUnit is the most widely used testing framework on the JVM. Given its widespread usage, JUnit needs to be thoroughly tested on all current JDKs and early access versions. Since enabling the Gradle Enterprise remote Build Cache, the average build time decreased by about 50%. Build Scans allow the JUnit team to collaborate on build failures and point out problems in pull requests. In addition, the JUnit team takes advantage of the Gradle Enterprise Test Failure analytics to stabilize flaky tests. More recently, the JUnit build has adopted Gradle Enterprise Test Distribution for CI and local builds to speed up slow integration tests.
Spock is a testing and specification framework for Java and Groovy applications. Spock’s beautiful and highly expressive specification language differentiates it from alternative solutions. Its JUnit runner makes Spock compatible with most IDEs, build tools, and continuous integration servers. Gradle Enterprise surfaced several performance issues in Spock’s Gradle build. Build Scans showed that tasks were not up-to-date with no code changes because of changing snapshot dependencies. The Gradle Enterprise task inputs comparison identified tasks that were not being pulled from the cache. After solving those problems, as well as a few others, Spock’s Gradle build could take full advantage of the Gradle Enterprise remote build cache. This brought CI build times for the Spock project from a median of 3 minutes per build to about 1 minute per build.
JHipster is a development platform to quickly generate, develop, and deploy modern web applications and microservice architectures. JHipster helps developers create deployments across a range of both frontend and backend languages and frameworks. JHipster’s project generator creates backend Java applications which in turn have their own individual build and test cycles. Gradle Enterprise’s build caching and scan features are now seamlessly available in generated JHipster projects, saving time for JHipster developers and their users. JHipster also makes use of the Build Scan functionality to more easily identify previously undetected areas for build time improvement as well as analyze build failures caused by differences in infrastructure.
Ratpack is a simple, capable, toolkit for creating high performance and scalable web applications built on Java and the Netty event-driven networking engine. It consists of a set of Java libraries for building scalable HTTP applications. Optional Gradle build time support makes building and testing applications a breeze. The Ratpack team relies on Gradle Enterprise Build Scans to efficiently debug build failures and on the remote build cache to accelerate building locally and in their CI pipeline.
Micrometer is a vendor-neutral instrumentation facade for JVM-based applications which provides multiple interfaces that developers can use to instrument their code without being locked into a monitoring solution. The dimensional data model, in combination with the timers, gauges, counters, distribution summaries, and long-task timers provided by the interfaces allows for searching and drilling down on metrics. Before optimizing the build with Gradle Enterprise the average build time for the project was 3 minutes; after optimizations the build time was less than 1 minute. Analysis of test-related task inputs found multiple opportunities for avoidance savings during test cycles, leading to further reduction in feedback cycle times. The insights gained from the Build Scan service have helped the team uncover multiple inefficient dependency repository lookup calls alongside improvements to the project’s overall cacheability. Build Scan dependency info, plugin insights, and deprecation warnings help the team ensure that build systems stay up to date with the latest version of the Gradle Build Tool and the related plugins that they use.
Gradle has emerged as the build tool of choice for projects within the JVM ecosystem, including Kotlin. Gradle Build Tool has a comprehensive automated test suite that covers different operating systems and Java versions. The team runs about 70,000 builds a week. The build relies heavily on the remote Build Cache for build acceleration, Build Scans for finding performance regressions, flaky test management to identify and prioritize fixing the most flaky tests, and Test Distribution to further reduce build times.