Just increment versionCode in current project based on the last one in Google Play

[zhelanov]

Problem description

In a standard (as I see) pipeline there are a few parallel jobs:

• build app
• static analyze
• custom tasks
• etc.

and only after that it's necessary to deploy an app. For now if we use gradle tasks delivered by this (awesome, really) plugin we deploy right after build and if (for example) static analyze fails we understand that we already deployed "bad" version of app. There is a workaround of course: build and deploy only after another tasks. But obviously it'll slow pipeline so it's just not a good solution

Potential solutions/workarounds

1. Add option to not build and just update versionCode based on the last one in Google Play
2. Add option to not deploy app in Google Play after versionCode increment and build

[SUPERCILEX]

While you might end up with slightly slower builds, I do think the right thing to do here is to not publish anything until you've validated the correctness of your build. Assuming you aren't doing anything funky with caching, it should be as simple as separating the commands:

./gradlew build test lint etc...
./gradlew publish

The publish should only take as long as an upload plus maybe a few other quick tasks.

Another reasonable solution which I think is closer to what you want would be to prepare a publishing action without committing it. Once the build succeeds, commit it:

./gradlew publishBundle --no-commit build test lint etc...
./gradlew promoteArtifact

[zhelanov]

@SUPERCILEX , you are right but if I run ./gradlew build and after that ./gradlew publish then a second task will rebuild an app almost from scratch with a new versionCode because of an automatic versionCode resolution.

I don't really understand how '--no-commit' works in your example (according to https://github.com/Triple-T/gradle-play-publisher#combining-artifacts-into-a-single-release)

[SUPERCILEX]

then a second task will rebuild an app almost from scratch

Have you tried this? It shouldn't do that because release builds update the version code regardless of whether or not you're publishing, precisely to enable this kind of caching.

I don't really understand how '--no-commit' works

The publishing API is atomic for most publishing actions. So we create an "edit," apply some operations (like uploading an app), and then "commit" the edit. Until you commit the edit, nothing happens. In step one, you tell GPP to not commit anything. Then you run promoteArtifact which sees that there's a pending edit and schedules it to be committed.

[stale[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.