moko-resources
moko-resources copied to clipboard
icerockdev
Improve build cache support in `GenerateMultiplatformResourcesTask`
The GenerateMultiplatformResourcesTask currently doesn't support its build cache entries to be re-used between builds at different filesystem locations. This effectively prevents build cache re-use for any subproject using this plugin, between:
- a CI build and a local build (in most cases, they're built at different paths);
- a CI build and another CI build (if built from different locations);
- a local build and another local build from a different clone or worktree.
Path sensitivity and cache relocatability
Snippets taken from public docs.
When sharing cached results between computers, it’s rare that everyone runs the build from the exact same location on their computers. To allow cached results to be shared even when builds are executed from different root directories, Gradle needs to understand which inputs can be relocated and which cannot.
Tasks having files as inputs can declare the parts of a file’s path what are essential to them: this is called the path sensitivity of the input. Task properties declared with ABSOLUTE path sensitivity are considered non-relocatable. This is the default for properties not declaring path sensitivity, too.
The Task input in GenerateMultiplatformResourcesTask that's preventing relocatability is upperSourceSets.
Testing for relocatability
We verified that this is the offending input using in a relocatability test performed with develocity-build-validation-scripts n. 3, which runs 2 builds at different locations and checks re-executed tasks.
This Task Inputs comparison in Develocity shows that the input has a different value across the 2 builds of moko-resource's kotlin-2-sample project, yielding different cache keys and preventing cache re-use. The 2nd build had 50s additional build time due to the re-executed GenerateMultiplatformResourcesTasks and dependent Tasks.
We can compare the actual content of the upperSourceSets input in the 2 Build Scans to illustrate how it references absolute paths, causing its value to change across builds.
We recommend adding tests to the plugin with TestKit to catch regressions on relocatability in the future.
Fixing relocatability
To fix relocatability for this Task, upperSourceSets would have to become a File input with path sensitivity declared. Please refer to the custom cached outputs documentation for an example. If it's still necessary for this input to be a map, you could explore turning it into a @Nested input, which would then reference other @InputFiles properties (if it's a fixed number of cases), or registering one Task per 'upper source set' key, which would eliminate the need for a single Task to reference multiple source sets.
