search

researchgate / gradle-release

gradle-release is a plugin for providing a Maven-like release process for projects using Gradle
MIT License
859 stars 223 forks source link

Gradle configuration cache compatibility #346

Open Vampire opened 3 years ago

Vampire commented 3 years ago

The current version is not compatible with the new Gradle configuration cache as it for example modifies the version property at task execution time.

Vampire commented 2 years ago

Any plans to update this? The configuration cache is a really great feature even in its current state, but it cannot be used at all with this plugin applied due to the usage of taskGraph.afterTask which is forbidden. If it were just tasks that are non-conforming, these could now be marked as incompatible with the configuration cache, but this listener usage is not fixable by downstream code. :-(

Hillkorn commented 2 years ago

Do I see it right that the alternative would be to use https://docs.gradle.org/6.9.2/javadoc/org/gradle/build/event/BuildEventsListenerRegistry.html which enforces the minimum required version to be 6.1 . Otherwise we could add the cleanup in a separate task if we can get the state there somehow.

Vampire commented 2 years ago

For the afterTask issue, yes, a build service registered as operation completion listener is usally the way to go. Modifying the version at task execution time is a different problem.

Vampire commented 1 year ago

Any news? Now that the configuration cache is promoted to stable with Gradle 8.1, it would really be nice if it could be used. Due to the afterTask usage a build using this plugin cannot use the configuration cache at all, except with dirty hacks like not applying the plugin if CC is enabled and requiring to disable the CC to release.

jonnybot0 commented 10 months ago

I tried messing around with this in my fork. See https://github.com/researchgate/gradle-release/compare/main...jonnybot0:gradle-release:main. Main problem I'm running up against now is that I'm getting this error when running the tests:

org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin class 'net.researchgate.release.ReleasePlugin'.
//...
    at net.researchgate.release.SvnAdapterTests.setup(SvnAdapterTests.groovy:23)
Caused by: org.gradle.internal.service.ServiceCreationException: Cannot create service of type DefaultBuildEventsListenerRegistry using DefaultBuildEventsListenerRegistry constructor as required service of type BuildEventListenerFactory for parameter #1 is not available.

On researching that, it looks like this problem was fixed in Gradle 7.6 (I think). See https://github.com/gradle/gradle/issues/16774 https://github.com/gradle/gradle/pull/21135

As such, fixing this would likely entail upgrading Gradle in the plugin.

There may be other workarounds, but a Gradle update seems the most straightforward. If the maintainers are open to that, I might be able to scare up a PR in that direction. I'd like some pointers on whether it should go all the way to, say, Gradle 8.0 or what, since I imagine breaking backwards compatibility would be a major release.

tnielens commented 4 months ago

@Hillkorn any interest in fixing this issue? @jonnybot0 seems on the right track with his CleanupBuildService. I'd be happy to help out. In my projects at work, the configuration cache works greatly and gradle-release is the last plugin not supporting it. We use this workaround:

// The gradle-release plugin runs gradle subprocesses. Checking only "release" isn't sufficient.
// https://github.com/researchgate/gradle-release/blob/main/src/main/groovy/net/researchgate/release/ReleasePlugin.groovy#L57
if (!gradle.startParameter.taskNames.toSet().intersect(["release", "runBuildTasks", "afterReleaseBuild"]).empty) {
    apply plugin: "net.researchgate.release"
    ...
}