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.

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

Support Gradle configuration cache on multiple JVMs #1274

Open
nedtwigg opened this issue Aug 11, 2022 · 4 comments
Open

Support Gradle configuration cache on multiple JVMs #1274

nedtwigg opened this issue Aug 11, 2022 · 4 comments

Comments

@nedtwigg
Copy link
Member

nedtwigg commented Aug 11, 2022

Gradle configuration cache requires task state to be round-trip serializable. As outlined at #987, this is a signficant constraint on plugin developers and it slows down the end-user experience of change-test-change-test on a single JVM daemon. We built a workaround (JvmLocalCache) that complies with Gradle's requirement by making our tasks round-trip serializable without requiring much work from plugin developers or the end user's machine, but it only works within a single JVM.

To work on multiple JVMs, we need to

  • make every step round-trip serializable
  • remove JvmLocalCache
@eskatos
Copy link
Contributor

eskatos commented Sep 28, 2022

FYI Gradle 8 will do a full roundtrip on the first invocation with CC enabled.
See work in progress here gradle/gradle#21985 (comment)
The goal is for this to be the default in 8.0.

@nedtwigg
Copy link
Member Author

nedtwigg commented Sep 28, 2022

Full roundtrip will work great on the same JVM, so Spotless will still work and not work under the same conditions it does currently. EDIT: Compatibility with configuration cache within a single JVM on Gradle 8 is confirmed.

@nedtwigg
Copy link
Member Author

nedtwigg commented Dec 4, 2023

I think we now have a way to incrementally build this until we can eventually remove our workaround. See:

In this comment, I'm going to maintain a list of remaining TODOs before we will fully support Gradle's configuration cache model without any workarounds. If you'd like to help: comment in this issue when you start on a given step, follow-up with a PR (draft is fine) and I will update the checklist below

@lehmanju
Copy link

lehmanju commented May 6, 2024

I checked npm.EslintFormatterStep, npm.PrettierFormatterStep, npm.TsFmtFormatterStep and sql.DBeaverSQLFormatterStep. They all use StepHarness for testing which has roundtrip serialization testing enabled by default. Since their tests do not fail, it should mean they are already serializable, am I correct?

For NativeCmdStep I created a PR #2108 which adds a test using StepHarness.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants