Consider pitest task cacheability

[szpak]

If sensible mark task with @CacheableTask. It would be especially useful with Gradle Build cache introduced in Gradle 4.

Potential issues. That annotation has been added in Gradle 3.0. Check Gradle 2 compatibility in runtime.

[C-Otto]

I'd say Gradle4/3/2 support isn't necessary nowadays.

[szpak]

Nevertheless the cacheability is still trendy :-D.

@C-Otto Maybe you would like to take a look at the implementation options and eventually provide a PR? :-)

[SimY4]

@szpak isn't adding an annotation not binary breaking? I mean, whether you have annotation in your classpath or not doesn't stop classes from loading. So, if you run a version of Gradle with APIs where this annotation is present - it will be taken in effect, and if not - it'll work as it works today.

[szpak]

I believe that there were some other requirements for cacheability to be effective, however, as the project migrated to the property-based task parameters it might be fulfilled automatically. Still, there would need to be written a functional test confirming that in fact caching holds.

[davidburstrom]

I've been using

tasks.named<PitestTask>("pitest").configure {
  outputs.cacheIf { true }
}

since December 2019 and have yet to see any issues related to caching. My thinking is that it's pretty safe to turn it on, with a functional test, and deal with any subsequent issues as regular bugs.

[szpak]

Thanks for your comment. The inputs/ooutputs migration to the Property-based replacement could do the trick. Would you like to add a functional test confirming that the second execution is cached (to verify it now and keep it as a regression test)?

[davidburstrom]

Done!