Hi there,
On 14/08/14 09:41, David Hamm wrote:
I agree to most of the points you wrote. but please take a look at the
current version of the plugin. it is currently 0.1.0, which means i'll
work further on the plugin and improve it step by step.
oauth is definitely one of the next features that i'm going to implement.
Yeah, integrating the Google OAuth into my plugin was fairly
straightforward — a nice use of the credentials plugin :)
in the developer console a service account is just a regular account and
you can configure access to whatever you want. i didn't know that it's
not possible to upload apk's in alpha or beta track without having the
production permission. i will test this when i get time to do so.
I tested this again just now, and unfortunately it's still the case that
your API account needs four separate permissions just to upload an alpha
APK :(
i agree that defaulting to '**/*.apk' is not the best solution. but,
what is your recommendation on this point? force the user to input
correct path? don't upload multiple apks at once?
I just meant that it doesn't really make sense to have that as a default
value — make sure the user explicitly specifies the pattern(s) they want.
Uploading multiple APKs does make sense, but only if the user wants to
use Google Play's "Multiple APK Support" feature. But in this case, all
APKs need to be uploaded and assigned to a track in a single API commit.
this plugin is a notifier plugin and i read somewhere in the jenkins
wiki that notifier plugins shouldn't change the build result. and i'm
not sure if this plugin should change the build result to false in case
the apk couldn't be uploaded.
Right, Notifiers shouldn't change the build result, so really this
plugin should be a Recorder, as it totally makes sense to change the
build if the upload failed, rather than just claiming that the build was
successful, even if the upload failed.
removing lower versions from other versions is required. otherwise you
are not able to commit your changes, because ther will be conflicts in
version codes.
Yeah, you're right — I think the scenario I was testing involved calling
update() on the same track, where removing versionCodes isn't required
in advance.
Regards,
Chris
thanks for your reply
david
Am Donnerstag, 14. August 2014 02:06:40 UTC+2 schrieb Christopher:
Hi there,
On 08/13/2014 08:27 PM, David Hamm wrote:
> i created a google play publisher plugin for android app.
> the project is located at github:
Ah, I have been working on an extended version of this plugin, as
perhaps was somebody else (there was a discussion on the users list
recently).
It might be a good idea to integrate with the Google OAuth Plugin,
rather than requiring users to have their Google API private key (p12
file) sitting on disk somewhere on the Jenkins master.
This is made more dangerous by the fact that alpha/beta APKs cannot
currently be uploaded via the API without also granting the API user
permission to alter *production* APKs (amongst other things). I
reported this to Google a few days ago, but they "do not currently have
a timeline" for it to be fixed.
Otherwise, I'm not sure that defaulting to '**/*.apk' is a great idea,
as most release builds produce multiple APKs
(unaligned/aligned/unsigned
etc.) of which only one should be uploaded, but it seems that given how
error handling is implemented, the build will continue in any case and
always report success?
Are you sure that removing version codes from other tracks is necessary
when uploading; the API seemed to do that automatically (except for the
special case of moving from partial rollout to full production)?
Regards,
Chris
--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" 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.
