Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Gradle properties not used at configuration time can still invalidate configuration cache #20969

Open
Tracked by #28341
mathjeff opened this issue Jun 8, 2022 · 1 comment
Open
Tracked by #28341

Gradle properties not used at configuration time can still invalidate configuration cache #20969

mathjeff opened this issue Jun 8, 2022 · 1 comment
Labels
a:bug in:configuration-cache Configuration Caching

Comments

@mathjeff
Copy link
Contributor

mathjeff commented Jun 8, 2022

Expected Behavior

It would be helpful if changes to unused Gradle properties didn't invalidate the configuration cache

Current Behavior

In AndroidX we're finding that changes to Gradle properties that aren't used at configuration time can still invalidate the configuration cache.

Also interesting, we're finding that Gradle properties that aren't used at all can still invalidate the configuration cache ( repro at https://github.com/mathjeff/gradle-samples/tree/master/configuration-cache-unused-property )

Context

We have a feature ( #13753 ) that changes some properties of some Gradle tasks, and we'd like it to be possible to avoid reconfiguring all projects and instead to just reread the new property value during task execution.

This issue looks closely related to #20873 ; if there were a convenient way to exempt a specific Gradle property from invalidating the configuration cache, that would work too.

In the meanwhile we might end up switching from a gradle property to an environment variable, which appears to not invalidate the configuration cache, see https://android-review.googlesource.com/c/platform/frameworks/support/+/2120272
@mathjeff mathjeff added a:feature A new functionality to-triage labels Jun 8, 2022
@eskatos eskatos added a:bug in:configuration-cache Configuration Caching and removed a:feature A new functionality to-triage labels Jun 9, 2022
copybara-service bot pushed a commit to androidx/androidx that referenced this issue Jun 9, 2022
@mathjeff
Enabling TaskUpToDateValidator via environment variable rather than g…
7121d83 
…radle property

so that it doesn't invalidate the configuration cache.

Also adding exemptions for tasks that start rerunning when using the configuration cache, see https://youtrack.jetbrains.com/issue/KT-49933

Bug: b/234451189

Bug: gradle/gradle#20969

Test: ./gradlew :help -Pandroidx.verifyUpToDate # and see that this still fails

Test: /gradlew :annotation:annotation:assemble -Pandroidx.verifyUpToDate # and see that the second build says "Configuration cache entry reused"

Test: rm -rf ../../out/dist && DIST_DIR=../../out/dist ./gradlew :annotation:annotation:assemble -Pandroidx.verifyUpToDate && ls ../../out/dist/scan* # and see that the scan zips exist
Change-Id: I8e89462e8bed8006d835dd4bd11a69eb7f45a932
@mlopatkin mlopatkin added 👋 team-triage Issues that need to be triaged by a specific team and removed 👋 team-triage Issues that need to be triaged by a specific team labels Jul 18, 2023
@ov7a ov7a added the to-triage label Dec 21, 2023
@ov7a
Copy link
Member

ov7a commented Dec 21, 2023

Sorry for the late reply.

Thank you for providing a valid report.

The issue is in the backlog of the relevant team, but this area of Gradle is currently not a focus one, so it might take a while before a fix is made.

@ov7a ov7a removed the to-triage label Dec 21, 2023
@mlopatkin mlopatkin mentioned this issue Feb 1, 2024
Closed
@oleg-nenashev oleg-nenashev mentioned this issue Mar 4, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
a:bug in:configuration-cache Configuration Caching
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@eskatos @mathjeff @ov7a @mlopatkin