Das Gradle Team ist bislang immer wieder durch neuere Konzepte hervorgetreten, mit denen sich Builds beschleunigen lassen. Eines der weniger bekannten ist der Build Cache, um den es in diesem Beitrag geht.
Der Build Cache hat eine wesentliche Rolle dabei, die Performance von Gradle zu verbessern. Dieses wird erreicht, indem wann immer möglich, ein Task nicht neu ausgeführt wird, sondern stattdessen Ergebnisse von anderen Builds und sogar anderen Maschinen recycelt werden.
Hierzu definieren Tasks Input und Output. Wenn diese beiden definiert sind, und sich der Input nicht ändert, kann der Output von einem vorherigen Buildvorgang mit identischem Input verwendet werden. Vereinfacht kann man sich den Build Cache wie eine große HashMap vorstellen, bei der der Input als Key genommen wird, und der Output als Value.
Dieses Verhalten ist nicht zu verwechseln mit dem Standardverhalten, welches Tasks überspringt, wenn lokal bereits der richtige Output existiert. Ein wesentlicher Unterschied ist, dass der Build Cache keine Abhängigkeit zu dem Zustand des Output Ordners hat, und somit z. B. auch nach einem clean noch beschleunigend wirkt.
Der Build Cache befindet sich standardmäßig in GRADLE_USER_HOME und kann bei einem Build aktiviert werden, indem –build-cache als Parameter an den Gradle-Aufruf mit übergeben wird. Z. B.
gradle --build-cache clean build
Dies ist jedoch nicht alles, was mit dem Build Cache erreicht werden kann. Es ist z. B. möglich, den Build Cache zwischen verschiedenen Maschinen zu teilen. So ist es möglich, dass ein CI Server diesen zentralen Cache befüllt, und somit alle Entwickler davon profitieren.
buildCache {
local {
enabled = !isCiServer
}
remote(HttpBuildCache) {
url = 'https://example.com:8123/build-cache/'
push = isCiServer
}
}
In diesem Beispiel wird über eine Variable festgelegt, dass nur der CI-Server auf den geshareten Cache pushen darf, aber alle von diesem Cache lesen dürfen. Hierdurch wird verhindert, dass der Cache dutzende Versionen enthält, die nur für einen Entwickler relevant sind. Zudem wird für den Server der lokale Cache explizit deaktiviert, während er für die Entwickler aktiviert bleibt. Dies hat den Vorteil, dass durch den Entwickler geänderte Tasks trotzdem lokal gecachet werden können.
Für den zentralen Server gibt es vom Gradle Team ein offizielles Docker Image, welches für eine Firmenintranet-Nutzung ausgelegt ist.
https://hub.docker.com/r/gradle/build-cache-node/
Gerade wenn der Build einzelne sehr lang laufende Tasks beinhaltet, die jedoch nur selten geändert werden, kann sich der Build Cache sehr schnell bezahlt machen. XSLT Transformationen, Bildkonvertierungen (z.B. resize für Mobile) und viele andere Tasks profitieren hiervon immens.
Zum Abschluss noch ein Link zu dem offiziellen Build-Cache Beispielprojekt.
