Spawn tasks using Worker API #170
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
…'s classpath to the main gradle classloader
08512e6 to e571634 Compare Looks like the Worker API is causing metaspace memory issues, see gradle/gradle#15200, gradle/gradle#8291, gradle/gradle#8221. I'm placing the PR back into draft mode until Gradle will provide a better way to run tasks with an isolated classpath. |
This was referencedSep 12, 2021
Sign up for free to join this conversation on . Already have an account? Sign in to comment
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Fixes #75.
This makes the plugin tasks (
ScoverageReportandScoverageAggregate) run using Gradle's worker API, which provides an ability to run them with a custom classpath without affecting the main Gradle classpath/classloader.Logging may change slightly, as the the worker API does not expose a way to use the project's logger (see gradle/gradle#2678).
Another aspect that may change is the performance of the Gradle build. #75 initially addressed the performance hit caused by spawning each task in its own process, so the fix then (version 3 I think) was to run in the main Gradle process, which introduced the pollution of the classpath/classloader.
Looking at the worker API documentation about isolation modes, it's implied that running with a separate class loader will not spawn another process (otherwise why would there be another isolation mode just for running in a separate process?), so my hopes are that the performance is not impacted in a significant way.