kind of a weird one. I just fixed up an internal p...
# configuration-cachet
tony
04/08/2022, 10:17 PMkind of a weird one. I just fixed up an internal plugin to work with CC, and I've verified it works. However, when I try to write a spec verifying it, I get this error:
Copy code
1 problem was found storing the configuration cache.
- Task `:app:resignDebug` of type `com.company.ReSignTask`: value 'map(org.gradle.api.file.RegularFile map(property(org.gradle.api.file.Directory, property(org.gradle.api.file.Directory, property(org.gradle.api.file.Directory, map(org.gradle.api.file.Directory flatmap(provider(task 'packageDebug', class com.android.build.gradle.tasks.PackageApplication)) check-type()))))) check-type())' failed to unpack providertony
04/08/2022, 11:02 PMhuh. The chain has an NPE in both the real and test cases, but only fails CC for the latter. That's odd
tony
04/09/2022, 12:16 AMwith configuration cache, does gradle have to resolve all
Provider<RegularFile>p
Phil Glass
04/09/2022, 7:34 AMMy rough understanding is that if a provider resolves to a fixed value post-configuration then that value gets serialized, rather than the provider itself (but often it doesn't, e.g. if you wire a task output to an input the value will only be known at execution time). So maybe a value somewhere in the chain is fixed post-configuration in your test but not in your real usage? https://github.com/gradle/gradle/blob/a7ed5ebdd4bbbcb02b7323e418acc0998abc27aa/subprojects/model-core/src/main/java/org/gradle/api/internal/provider/ProviderInternal.java#L54-L66
t
tony
04/09/2022, 5:01 PMI have observed that in both the real and test situations, the provider is being queried at configuration time, when the final value is not ready yet (in fact the final value is a file that doesn't exist until execution time). I haven't yet found anywhere where I might be querying this value early.
tony
04/09/2022, 5:03 PMlooking at the stack traces, it's gradle all the way down. I'm not seeing any user code triggering this provider to be queried
tony
04/09/2022, 5:10 PMI find this output extremely weird and confusing
Copy code
0 problems were found storing the configuration cache.
See the complete report at file:///...../build/reports/configuration-cache/8jv613vpgs12l1jt7kvolgyak/c5cqx0h8dlcjykb6opxpucv6s/configuration-cache-report.html
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':app:resignDebug'.
> Failed to query the value of task ':app:resignDebug' property 'packageFile'.
> java.lang.NullPointerException (no error message)tony
04/09/2022, 5:14 PMI'm not sure how readable this is, but this is a diff of two stacktraces. The one on the left is the provider queried during configuration time. The one on the right is when it is queried during execution time. This is the only section where they differ.
p
Phil Glass
04/09/2022, 5:34 PMHuh. I've seen the 'failed to unpack provider' thing a few times when task dependencies have accidentally been removed (e.g.
taskProvider.map { it.someProperty.get() }taskProvider.flatMap { it.someProperty }t
tony
04/09/2022, 5:52 PMappreciate it nonetheless 🙂 (and that makes two of us)
3 Views