Rollout check/Retries

[NoNews]

Hi, at first, thank you for the gradle-play-publisher!

It saves a lot of time for our team :)

Problem description

• It's possible to upload a new release, while previous release is not rolled out for 100%. We have scheduled publications, and scheduled rolling out

• 404: Edit has been deleted It's been discussed, however, all proposed workarounds didn't help. Custom retries work fine, with the same artefacts. Probably it's just communication with google play api related to our product at the same by the other services. Also, sometimes it can be a problem with google play api.

Potential solutions/workarounds

1. Fail new publication if previous one on the track is not rolled out on 100% It can be add via separate flag to CLI and we can use google play api for that as a source of truth:

2. Retries on a plugin level It may look this way:

--retryCount=2
--retryTimeout=5m

Additional context

I believe this changes will add autonomy to any team which has release automation

If you are OK, I would be really happy to implement all of the above changes and contribute them to gradle-play-publisher

Thank you!

[SUPERCILEX]

1. You should be able to use the promote task to always roll out the app to 100% before uploading. You'll need to invoke gradle twice though because promote will try to run after publishing if those happen within the same build. I don't want to add custom validation logic because it'll be impossible to make everyone happy. If you need special logic, I would recommend writing your own task that uses the android-publisher API. All the code GPP has to do API calls is here if you want examples.
2. Retries are unfortunately impossible with the current architecture. If the edit is deleted, we would have to create a new edit for the retry and rerun tasks that already succeeded using the new edit (something Gradle isn't designed for). If editDeleted failures are a big issue, I would recommend the following:
   • If you use AUTO resolution, only apply the plugin when you intend to run a publish task (otherwise edits will be created for every release build even if you don't publish anything).
   • Run a separate build just for publishing. So first build all your artifacts, then use the artifact dir flag to reuse those artifacts and make the build as fast as possible (thereby minimizing edit conflicts).
   • If you still run into issues, wrap that separate publishing build in some script that does retries on the Gradle build level.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.