Fixed
Status Update
No update yet.
Comments
uc...@google.com
cr...@gmail.com
I guess just considering it Internal should be enough, the number of CPUs shouldn't change the output of a task.
ne...@soundcloud.com
Here's a build scan showing this cache miss.
je...@google.com
ga...@google.com
We can tackle this in the following way:
- mark number of buckets as
@Internal - add
@LocalStatefile which only contains the number of buckets used in the previous task run - run incrementally only if the current number of buckets is the same as one in the file
This means that when:
- in a "typical" build where number of buckets does not change we will continue to be incremental
- there is a cache hit this file will be missing (
@LocalStateis not copied from the cache) and all subsequent runs will be non-incremental - if someone changes the number of buckets:
- without changing any of the inputs task will be up to date (that is perfectly fine)
- and inputs change we will run build non-incrementally
[Deleted User] <[Deleted User]>
Could it be backported at least to 4.0 release?
ga...@google.com
We are cherry-picking only sever issues to 4.0 branch right now as we are trying to stabilize it, so sadly this fix will not be cherry-picked.
Description
- Version of Gradle Plugin: 3.6.0
- Version of Gradle: 6.1.1
- Version of Java: 1.8.0_242
- OS: Linux
Android Gradle plugin task class `DexArchiveBuilderTask` has [`numberOfBuckets`](
Usually developer machines and CI runners have different number of CPU cores (even CI runners between could have it different). This prevents usage of this task cache as it quite often produces cache misses.
Could you consider different approach to `numberOfBuckets` input property, so it will not introduce remote cache misses?
Current workaround is to get minimal available cpu cores on developers machines and CI runners and set it to `android.dexingNumberOfBuckets` in `gradle.properties`, though this is not a reliable approach and slows down dexing step.