gradle-release icon indicating copy to clipboard operation
gradle-release copied to clipboard

Order of release tasks when applied in multi module project is random with Gradle 5?

Open markusrausch opened this issue 6 years ago • 3 comments

Hi,

After upgrading to Gradle version 5.1.1 I observed the following:

Consider a (minimal) multi module project with the following structure:

- project:
    - moduleA

I apply the release plugin to the main project and to the module. I keep the version independently in project's and moduleA's gradle.properties, respectively. Now, ./gradlew release --dry-run would give me

:release SKIPPED
:moduleA:release SKIPPED

which indicates to me that the release task of the project is executed before that of moduleA. This makes sense to me as project then includes moduleA before its version is updated in :moduleA:release.

However, what I observe is that the execution order is somewhat random. Executing ./gradlew release -Prelease.useAutomaticVersion=true would give me

$ ./gradlew -Prelease.useAutomaticVersion=true
> Task :project:moduleA:createScmAdapter
> Task :project:moduleA:initScmAdapter
> Task :project:moduleA:checkCommitNeeded
...

or, after another execution,

$ ./gradlew -Prelease.useAutomaticVersion=true
> Task :project:createScmAdapter
> Task :project:initScmAdapter
> Task :project:checkCommitNeeded
...

in a random fashion.

So far, I didn't observe this behavior using Gradle 4 (4.10.2 and 4.10.3).

I know that support for multi module projects isn't complete but how is it intended to be used in my case? Is there anything I can do to ensure the order of release tasks using Gradle 5? Or is it just a bug? I used plugin version 2.6.0/2.7.0/2.8.0 with the same outcome.

Best regards,

Markus

markusrausch avatar Jan 31 '19 08:01 markusrausch

If you want to run the release on the root before the subProject you should add a task dependency there. On root level you can do

project.tasks.release.dependsOn project('.moduleA').tasks.release

Hillkorn avatar Mar 04 '19 09:03 Hillkorn

How would I achieve a similar setup, but instead of calling release on the sub-modules, we are caling uploadArchives on each sub-module. This used to work on Gradle 4.x, but doesnt work on Gradle 5.x:

afterEvaluate {
    subprojects { subproject ->
        subproject.tasks.withType(Upload).configureEach { task ->
            afterReleaseBuild.dependsOn task
        }
    }
}

dazza5000 avatar Mar 12 '19 18:03 dazza5000

Is this project dead? When can we expect support for multi-module projects?

Is there any way to disable release execution in submodules?

uPagge avatar Feb 16 '23 12:02 uPagge