Task should be a @CacheableTask so build-cache can be used

[nhoughto]

Since native-image is so damn slow for even moderately sized projects, it makes it hard to use like a normal compile step in build pipelines, Gradle can help with this if you enable the task to support the Gradle build-cache (https://docs.gradle.org/current/userguide/build_cache.html). It is effectively a set of annotations (building on top of the existing @Input @Output annotations) that tell gradle to store the output (native image in our case) in a cache, and if it sees those same inputs again it won't run the task, and just use the existing output.

The build cache store can be S3 or similar and shared across CI jobs/machines/people, if you have an environment where builds are run often, but native image code changed rarely this will mean the slow native-image build step should be skipped most of the time.

At a minimum it requires adding @CacheableTask to the task classes, and thats it. A lack of the annotation can be worked around by adding: nativeImage.outputs.cacheIf { true } to your gradle file, but would be good for it to be done in the plugin.

:+1:

[iamdanfox]

Fully agree! We've been using both remote and local gradle build caches internally and it's massively sped things up.

Would want to make sure we have a nice accompanying test that proves we get the cache hits/misses we want (e.g. when an input changes) as I've found it's quite easy to cause accidental regressions with this stuff. Looks like this should be pretty doable though: https://docs.gradle.org/current/userguide/test_kit.html#sub:test-kit-build-cache