This repository hosts a collection of Gradle plugins meant to extend the capabilities of Gradle and implement hermetic builds.
The plugins are likely to work best if Gradle is the build system of choice, but can be used integrated with other build systems too, e.g. just to build docker images.
- co.elastic.build-scan.xunit: import xunit files into build scan test results
- co.elastic.check-in-generated: Support for keeping checked in generated code up to date
- co.elastic.cli: Efficiently provision and run various cli tools
- co.elastic.docker-base: Building reproducible Docker base images
- co.elastic.docker-component: Building multi-platform Docker images for applications
- co.elastic.license-headers: Enforce license headers in source files
- co.elastic.lifecycle: extended lifecycle tasks
- co.elastic.lifecycle-multi-arch: support for building on multiple architectures
- co.elastic.gradle.sandbox: Run commands with build avoidance in isolation
- co.elastic.gradle.vault: Integration with vault
- co.elastic.wrapper-provision-jdk: Extend the wrapper script to include provisioning of the JDK
Recent versions of Gradle offer a rich set of features for plugin and build script authors alike. These centre around performance of iterating and overall build time reduction. Some examples: lazy configuration, build cache. Unfortunately there are many Gradle plugins that were created before these were available and don't take advantage of them.
The plugins defined here must make use of these facilities to enhance the performance of builds. Custom tasks need to define all inputs and outputs and must be marked as cachable where appropriate. The plugins must make use of lazy configuration and otherwise make sure that the configuration phase is fast.
By doing so we can assure that quick tasks like tasks or help run nearly instantly, and anything else only really
runs if something changed since the last invocation.
The plugins should not make any assumptions about the machine running the build. Linux and OSX must be supported. Where practical plugins should not break when applied to Windows and should be specific where Windows is not supported, or degrade gracefully. Windows support is on a best-effort basis and not something we continuously test. This being the JVM most things should work, but there are no guarantees.
Assumptions about the machine include but are not limited to the availability of software. A JVM will be available as that's running Gradle, but nothing else should be taken for granted. As a convention and enabler plugins can assume that docker will be available and use it, or otherwise provision required tools and libraries.
By doing so, it will be easy to change the versions of these requirements without changes having to be matched by developers and CI infrastructure, and it will be easy to reproduce failures from CI locally.
Plugins access any dependencies using the built-in mechanism of dependency configurations instead of implementing direct downloads. Doing so has the advantage that these will be cached in the dependency cache so it's easy to bake them in CI workers and users running locally will only have to download once. In addition with dependency verificatio enabled the checksum of these dependencies will also be verified.
Gradle doesn't have a generic way to configure dependencies to generic URLS, but Ivy reposirory definitions are generic enough to support it.
- No support for Windows, Linux and Mac on X86_64 and ARM64 are supported
- We made and effort to avoid it but some plugins still use internal Gradle APIs as there was no alternative
- Only tested against the latest Gradle version (this might change)