You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Paparazzi plugin configures the test tasks with a bunch of paths and those paths are set up as absolute paths. system properties are part of the cache key so if CI writes remote build cache entries while having the repository checked out in a directory like /tmp/my-repository and local machines have it in ~/Projects/my-repository the cache key of test tasks is different resulting in a cache miss.
Steps to Reproduce
The problem can be reproduced by updating the unit test app.cash.paparazzi.gradle.PaparazziPluginTest.cacheable() to run the second run in a different directory. In that case assertions that the task came from cache fail
@Test
funcacheable() {
val fixtureRoot =File("src/test/projects/cacheable")
// Also validate remote cache by running the test in two separate directories that use the same build cacheval secondFixturesRoot = fixtureRoot.parentFile.resolve("cacheable-2").registerForDeletionOnExit()
fixtureRoot.copyRecursively(secondFixturesRoot)
fixtureRoot.resolve("build-cache").registerForDeletionOnExit()
val firstRun = gradleRunner
.withArguments("testDebug", "--build-cache", "--stacktrace")
.runFixture(fixtureRoot) { build() }
with(firstRun.task(":preparePaparazziDebugResources")) {
assertThat(this).isNotNull()
assertThat(this!!.outcome).isNotEqualTo(FROM_CACHE)
}
with(firstRun.task(":testDebugUnitTest")) {
assertThat(this).isNotNull()
assertThat(this!!.outcome).isNotEqualTo(FROM_CACHE)
}
val secondRun = gradleRunner
.withArguments("testDebug", "--build-cache", "--stacktrace")
.runFixture(secondFixturesRoot) { build() }
with(secondRun.task(":preparePaparazziDebugResources")) {
assertThat(this).isNotNull()
assertThat(this!!.outcome).isEqualTo(FROM_CACHE)
}
with(secondRun.task(":testDebugUnitTest")) {
assertThat(this).isNotNull()
assertThat(this!!.outcome).isEqualTo(FROM_CACHE)
}
}
Expected behavior
A second run without input changes in a project that is in a different directory should come from cache. The recommended way of setting up remote build cache is to store cache entries on CI so that local dev machines can use them. If there are absolute paths in the cache key those local machines would never be able to use them
Workaround
I was able to work around this by adding the following gradle logic
Description
The Paparazzi plugin configures the test tasks with a bunch of paths and those paths are set up as absolute paths. system properties are part of the cache key so if CI writes remote build cache entries while having the repository checked out in a directory like
/tmp/my-repository
and local machines have it in~/Projects/my-repository
the cache key of test tasks is different resulting in a cache miss.Steps to Reproduce
The problem can be reproduced by updating the unit test
app.cash.paparazzi.gradle.PaparazziPluginTest.cacheable()
to run the second run in a different directory. In that case assertions that the task came from cache failExpected behavior
A second run without input changes in a project that is in a different directory should come from cache. The recommended way of setting up remote build cache is to store cache entries on CI so that local dev machines can use them. If there are absolute paths in the cache key those local machines would never be able to use them
Workaround
I was able to work around this by adding the following gradle logic
and initialize paparazzi as follows
Additional information:
The text was updated successfully, but these errors were encountered: