|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
This is something I'm not really willing to have in the plugin, as I believe uploading separate applications should be done in separate jobs.
If you attempt to upload, say three, completely different APKs in one Jenkins build, this requires opening and committing three separate "edit sessions" with the Google Play API. If any one of these fails — maybe because of an invalid APK, or due to an API failure (which, unfortunately, is not uncommon with the Google Play API) — you will end up with your Google Play account in an inconsistent state. Your build will be marked as failed, but one or more applications have actually been uploaded and published to Google Play, and you'll have to fix the situation manually. Also, you won't be able to just re-rerun the build again, as it will fail due to already-existing APKs.
The Jenkins best practice in this case would be to have one job that builds the different flavours (i.e. the APKs with different application IDs) and then, if the build is successful, it would archive the APKs and start multiple "downstream" Jenkins builds which individually publish each of the applications.
You can do this relatively easily, for example, with the Parameterized Trigger Plugin and the Copy Artifacts Plugin, i.e. the "upload" job could be generic, and would receive the APK information via parameter.
I will look at documenting this on the wiki.