Triple-T / gradle-play-publisher

GPP is Android's unofficial release automation Gradle Plugin. It can do anything from building, uploading, and then promoting your App Bundle or APK to publishing app listings and other metadata.
MIT License
4.13k stars 341 forks source link

use gradle publish lifecycle task instead of custom task #821

Closed Larusso closed 4 years ago

Larusso commented 4 years ago

Describe the bug

The plugin adds a publish task to the gradle task list. Many other plugins also do this but don't provide their own custom implementation. Instead they leverage the gradle lifecycle task called publish and add their task(s) as a dependency. Just like assemble and check.

The problem I have is that I use another plugin which also hooks into the publish task. And in combination with the gradle-play-publisher this results in errors or weird behavior.

How To Reproduce

Create a android project and follow the gradle-play-publisher setup steps. Also add a second publish plugin like net.wooga.appcenter classpath 'gradle.plugin.net.wooga.gradle:atlas-appcenter:0.7.1' apply plugin: 'net.wooga.appcenter'

Versions

Tasks executed

publish

Expected behavior

That all tasks, depending on publish will be executed. In my example publish to play and publish to appCenter

Additional context (if a crash, provide stack trace)

Depending on the order which plugin gets applied when, I see two different errors. If I apply gradle-play-publisher before the appCenter plugin, the build crashes:

* What went wrong:
A problem occurred evaluating root project '******'.
> Failed to apply plugin [class 'org.gradle.api.publish.plugins.PublishingPlugin']
   > Cannot add task 'publish' as a task with that name already exists.

If I apply the appCenter before after gradle-play-publisher then the publish task won't call the gradle-play-publisher publish steps. I did a small workaround

project.tasks.withType(com.github.triplet.gradle.play.tasks.internal.GlobalPublishableArtifactLifecycleTask) {
    publish.dependsOn it
}

All in all I see two major issues. I plugin should not setup a task with a name that is a known lifecycle task name in the gradle echosystem. Rather that creating a publish task the plugin should use the one provided by the gradle publish plugin. And bind the default logic to it as a dependency. This also makes sure that the ordering of plugins doesn't matter.

SUPERCILEX commented 4 years ago

Yeah, a lot of pain has come out of the publish task. Currently, if you apply GPP last, it should rename the publish task to gppPublish. I've debated how this should work before, but couldn't make up my mind. So is your vote in favor of making GPP add its dependencies to the publish task? I've thought that might be unexpected if people are used to that task only doing maven things.

Larusso commented 4 years ago

I know it's a tough topic. I personally prefer one publish task that acts as the lifecycle task just like assemble. I think that the whole topic like most of gradles internal plugins is slightly to much opinionated around java. Yes the publish plugin from gradle drags other stuff into the build that maybe not all users are happy about. I will rethink this as well. I used the publish plugin before it had the new publications setup etc.

What I essential want is a high level tasks that does the default behavior when envoked. If I call build the project assembles and gets tested. If I call publish I want that too plus the publication step to whereever the build configured it. The specialized publish task are there for finer control. When you use gradle locally. I try to setup my CI scripts as stupid as possible. They don't know that the project is an android build or a java application or whatever. I come from this angle. But again I can understand your standpoint.

But in gradle terms the cleanes solution would be to implement publications as gradle defined them. https://docs.gradle.org/current/userguide/publishing_customization.html

I never implemented it like this for my plugins because of the nature how gradle introduces such API's. Incubation -> maybe stable -> 2 versions later gone or stable. But it seems this API is in for good and the Android plugin itself can also publish aars with it.

Last question. Do you create the gppPublish in any case? I could work with this solution if you don't want to bind your plugin to the publish plugin or decide against using the publish task as your main entry task.

SUPERCILEX commented 4 years ago

Thanks for elaborating! I think adding GPP's dependencies to an existing publish task is a reasonable change for the upcoming v3.0 release I'm working on.