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

Fix multiproject support

Open danez opened this issue 10 years ago • 20 comments

There might be multiprojects where the root projects does not contain code or a build task, but the release task is still calling the build task.

For reference this configurations do currently not work:

  • [ ] multiproject - parent: release-plugin applied - sub: no release-plugin applied (will only build parent)
  • [ ] multiproject - parent: no code and release-plugin applied
  • [ ] SNAPSHOT/project dependencies between subprojects

danez avatar Oct 26 '15 11:10 danez

Faced the same issue. Even

release {
    buildTasks = [''] // buildTasks = ['subproject:build']
}

does not help

madhead avatar Nov 04 '15 17:11 madhead

As a workaround you might be able to do

release {
    buildTasks = []
}

for the project that does not contain sourcecode.

Does this work?

danez avatar Nov 04 '15 17:11 danez

No, that doesn't help. I connected to the Gradle in debug and it looks like it first runs build with ['build'] and then with whatever I set in release.buildTasks. Maybe some problems with running forked build?

The problem is my project layout. I have top level project A who has two children A1 and A2 in corresponding subdirectories. Also, there is gradle.properties in project A who sets the version for all project.

When I put release plugin to subprojects (as recommended in the docs) then it cannot find properties file with version (it is one level upper). So, I put release plugin in project A:

plugins {
    id 'net.researchgate.release' version '2.3.2'
}

release {
    buildTasks = []
}

What I need is:

plugins {
    id 'net.researchgate.release' version '2.3.2'
}

release {
    buildTasks = ['A1:build', 'A2:build'] // buildTasks = [':A1:build', ':A2:build']
}

But that doesn't work too as it still tries to run build task on project A. Now I have stub build task in main project that depends on subprojects...

madhead avatar Nov 04 '15 17:11 madhead

Ah now I got it. When you run gradle build it works and builds A1 and A2?

danez avatar Nov 04 '15 17:11 danez

Yes. When I run ./gradlew build from the root (A) it builds both projects.

madhead avatar Nov 04 '15 17:11 madhead

When I put release configuration in subprojects:

plugins {
    id 'java'
    id 'net.researchgate.release' version '2.3.2'
}

release {
    versionPropertyFile = '../gradle.properties'
}

The build fails because first subproject increments version in properties and it became -SNAPSHOT and the second project's release task fails.

madhead avatar Nov 04 '15 17:11 madhead

And the final blocker. Even if I use separate gradle.properties for both subprojects and configure them independently, I get snapshot checking exception because second subproject (A2) depends on first (A1). And at the moment when A2 is release A1 is already bumped to snapshot:

* What went wrong:
Execution failed for task ':A2:checkSnapshotDependencies'.
> Snapshot dependencies detected: 
    A2: [by.dev.madhead:a1:1.0.28-SNAPSHOT]

madhead avatar Nov 04 '15 18:11 madhead

I've created a demo: https://github.com/madhead/gradle-release-demo:

┌[madhead@madhead-linux:~/Projects/gradle-release-demo]
└─$ ./gradlew release -Prelease.useAutomaticVersion=true
:release
:gradle-release-demo:createScmAdapter
:gradle-release-demo:initScmAdapter
:gradle-release-demo:checkCommitNeeded
:gradle-release-demo:checkUpdateNeeded
:gradle-release-demo:unSnapshotVersion
:gradle-release-demo:confirmReleaseVersion
:gradle-release-demo:checkSnapshotDependencies
:gradle-release-demo:runBuildTasks FAILED
:release FAILED
Release process failed, reverting back any changes made by Release Plugin.

FAILURE: Build failed with an exception.

* What went wrong:
Task 'build' not found in root project 'gradle-release-demo'. Some candidates are: ':build'.

* Try:
Run gradlew tasks to get a list of available tasks. Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 7.687 secs

madhead avatar Nov 04 '15 21:11 madhead

Can you please check this line. Before project is evaluated extension.buildTasks contains default values, no matter what I set in release extension. Is that ok?

madhead avatar Nov 04 '15 22:11 madhead

I think there are more problems, because there are really a broad spectrum of different setup types. But you are right this line was wrong. I fixed it in master and created a snapshot, does it fix something for you? at least the buildTasks = [] might work now i think.

buildscript {
  repositories {
    maven { url 'http://oss.jfrog.org/artifactory/oss-snapshot-local' }
  }

  dependencies {
    classpath 'net.researchgate:gradle-release:2.3.3-SNAPSHOT'
  }
}

danez avatar Nov 04 '15 23:11 danez

Can you please check this commit.

P.S. Didn't saw you comment :) I've made exactly the same thing and it looks ok. P.P.S Sorry for spamming here...

madhead avatar Nov 04 '15 23:11 madhead

:) Thanks I released 2.3.3 with this fix.

danez avatar Nov 04 '15 23:11 danez

Hi,

The fix applied in 2.3.3 for this issue doesn't work for me. I still get Task with name 'subproject:build' not found in root project 'parent'. It seems that @madhead's patch is different than which actually got applied because that really seems to work. Here I made the changes of @madhead to make it work. However, he uses project.task() which creates a task not retrieving it, which doesn't seem to be correct, yet it seems to work.

Katona avatar Nov 10 '15 16:11 Katona

@Katona, like you've mentioned 2.3.3 has some extra changes, changing task access logic. And I faced the same problem as you. What I did is an extra task (in root project) that depends on all the tasks needed for the release:

release {
    buildTasks = ['releaseBuild']
}

task releaseBuild {
    dependsOn(
            'subproject-a:clean',
            'subproject-a:build',
            'subproject-a:publish',
            'subproject-b:clean',
            'subproject-b:build',
            'subproject-b:publish'
    )
}

madhead avatar Nov 10 '15 16:11 madhead

@madhead excellent, this is exactly what I came up with in seconds ago :)

Katona avatar Nov 10 '15 16:11 Katona

Here is an example of multi-project setup https://github.com/JV-ration/gradle-multi-project-sample/tree/0.0.1, where any Gradle task fails, including gradle tasks. Problems disappear when declaration of release plugin is removed from top level build.gradle

plugins {
    id 'net.researchgate.release' version '2.3.5'
}

sadovnikov avatar Mar 21 '16 15:03 sadovnikov

For people stumbling on this one: the example from @madhead works fine, but instead of explicitly listing all sub-projects you can simply do the following:

task releaseBuild {
    dependsOn subprojects.findResults { it.tasks.findByName('build') }
}

I even renamed the task at the root project to build so I didn't need to specify it as the buildTask:

task build {
    dependsOn subprojects.findResults { it.tasks.findByName('build') }
}

franzbecker avatar Jul 26 '16 21:07 franzbecker

Any progress on this?

  1. I have cross-project dependency issue as listed in the issue, do we have a workaround?
  2. Can we skip a subproject release if there is no code change?

Thank you!

myanything avatar Feb 21 '17 05:02 myanything

Hey, it depends on your gradle setup. The ones that should work can be found here https://github.com/researchgate/gradle-release-examples

Hillkorn avatar Feb 21 '17 09:02 Hillkorn

Is there any workaround for "SNAPSHOT/project dependencies between subprojects" support?

gesellix avatar Feb 19 '18 12:02 gesellix