Incompatible with new Gradle configuration cache

[magneticflux-]

Requirements for tasks to support configuration caching: https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements

Errors logged:

FAILURE: Build failed with an exception.

* What went wrong:
Configuration cache problems found in this build.

2 problems were found storing the configuration cache.
- Plugin 'org.shipkit.shipkit-auto-version': external process started 'git log --pretty=oneline v0.1.23..HEAD'
  See https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements:external_processes
- Plugin 'org.shipkit.shipkit-auto-version': external process started 'git tag'
  See https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements:external_processes

In the documentation here, they suggest using providers.exec() to postpone execution until the property is actually needed.

[mockitoguy]

Makes sense. We should look into it. Have you thought about contributing? Thanks for reporting!

[magneticflux-]

Can I upgrade the minimum Gradle version? providers.exec() is only available since Gradle 7.5.
If sticking on 6.1 is required, I can make a custom ValueSource to replace ProcessRunner and work with Provider<T>s.

Either way, it looks like Gradle APIs (Provider, Project, etc.) are going to have to reach deeper into the code. You commented in AutoVersion.java "Main functionality, should never depend on any of Gradle APIs.", but the only way I see to preserve that is to wrap the entire functionality in a ValueSource, which kinda defeats the purpose of Gradle's state tracking. It's a lightweight git log call right now, but if we want to add some heavy feature later everything will be wrapped together.

If I could do whatever I wanted, I think I would start by making VersionsProvider a ValueSource, making a Provider out of it, and then mapping that with the logic in AutoVersion to get a Provider<String>. Then we can just wire up that to the version property and Gradle should handle the whole data graph and do whatever caching it wants to.

[mockitoguy]

Hey can you summarize version we are compatible / not compatible with? Sorry for late response - if it takes too long for me to respond/figure it out I'll give you write permissions to the repo and green light for making a decision on this.

[mockitoguy]

@magneticflux-, interested in becoming a project member of the Shipkit organization?

[benbitrise]

@mockitoguy @Magneticflux - I've opened a PR for configuration cache support. #187