search

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.1k stars 340 forks source link

Plugin 3+ publish task dependencies with --artifact-dir parameter #903

Closed tprochazka closed 3 years ago

tprochazka commented 3 years ago

I'm using two separated jobs on TeamCity, one for build aab and the second for deploy to Play. So build job, just transfer result aab files to deploy job.

Until now, with plugin 2.8.0 I was using this way: ./gradle -x bundleDefaultBackendProdRelease publishDefaultBackendProdRelease

But It stops working with 3+ version of the build plugin because of using a new API for handling dependencies. Your publish job now has no direct dependency on bundleDefaultBackendProdRelease, but has a dependency on the artifact itself.

So. I started using this way: ./gradlew --stacktrace publishDefaultBackendProdRelease --artifact-dir bundle

It works correctly. I mean publish aab inside of bundle folder to Play, but big issue is that it build whole app again, simply because publishDefaultBackendProdRelease has still dependency on aab. I asked mz colleagues which using also this way, but still with 2.8.0 and it works for them without rebuilding whole app.

It is bug or I'm doing something wrong? Whould be possible to not setup dependency on aab when --artifact-dir is used? Or use different task name without this dependency?

SUPERCILEX commented 3 years ago

Do you have defaultToAppBundle enabled? Either way, it should work if you run ./gradlew publishDefaultBackendProdBundle --artifact-dir bundle as opposed to the task that runs everything. Though if you have defaultToAppBundle set to true, the task that runs everything should work.

tprochazka commented 3 years ago

Yes. I have defaultToAppBundles.set(true). But I'm now a little bit confused by your reply if it is good or bad :-) But I tried to change it to false and it still does a full build. Btw. I'm using plugin 3.1.0 with AGP 4.1.1.

SUPERCILEX commented 3 years ago

Oops, sorry. It's good if you set it to true and want to publish a bundle (so true is good).

Did you try the command I suggested? I'd be curious to see if that works. You might also want to check that you didn't accidentally add a dependsOn("bundleRelease") to the publish task.

tprochazka commented 3 years ago

Sorry. I miss that you added Bundle to the end of the task. But it looks that it is the same it still starts the full build chain. But I just tried to do the same on testapp which is part of your plugin code and it looks that it really doesn't trigger build of everything. So it is really a mystery for me. I will investigate what is going here.

tprochazka commented 3 years ago

I found a possible source for this issue image For some unknown reason the publish task has dependency on :app:uploadCrashlyticsMappingFileDefaultAvastBackendProdRelease which basically trigger evething. I'm using plugin id("com.google.firebase.crashlytics") Maybe this firebase plugin itself declares a dependency on publish task.

SUPERCILEX commented 3 years ago

Ohhhhh, shoot. I added that because of https://github.com/Triple-T/gradle-play-publisher/issues/859

tprochazka commented 3 years ago

Yes. I just found this maybeAddDependency("uploadCrashlyticsMappingFile$variantName")

So, I think that this should not happen when --artifact-dir is used. Only without it.

SUPERCILEX commented 3 years ago

Hmmmm, I'll have to think about this some more and see if I can ignore it when --artifact-dir is used like you said. Otherwise I wasn't a fan of adding deps on third-party libs anyway, so I might just kill the feature and add docs telling people how to do this for themselves.

tprochazka commented 3 years ago

I personally think that the Crashlytics plugin automatically runs its task after the assemble and bundle tasks. So if I run publishReleaseBundle It depends on bundleRelease task which will trigger uploadCrashlytics task. So I'm actually not sure what is the reason for #859. Maybe using of this new (and old in the same time) API android.onVariants which is not used by the Crashlytics plugin?

SUPERCILEX commented 3 years ago

Yeah, since v3.0 we don't depend on bundleRelease which is what the crashlytics plugin assumes you'll use. That means it doesn't run by default when you call publish bundle/apk

SUPERCILEX commented 3 years ago

Just in case you want the technical background, Gradle is moving away from depending on tasks directly. Instead, you depend on a property (in this case a RegularFileProperty that will contain our app bundle) and Gradle knows that's it's an output of a task and can add the implicit dependency on the task for us. bundleRelease is a global task meaning it doesn't actually do anything and instead just adds a dependency on the real task that builds stuff (which can change without you having to care).

tprochazka commented 3 years ago

Thanks! I know about it. It is probably a good way. But I feel that it is even more mysterious than now. They should at least keep the actual effective task name to keep compatibility with the older plugin. I mean that if your task needs bundle as input it will still run bundle release task as before.

mochadwi commented 3 years ago

Hmmmm, I'll have to think about this some more and see if I can ignore it when --artifact-dir is used like you said. Otherwise I wasn't a fan of adding deps on third-party libs anyway, so I might just kill the feature and add docs telling people how to do this for themselves.

would you mind point us a references to which docs for this? is related to runs the mapping task ourselves in #859?