Hi Christopher,

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.

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 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?

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.

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.

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 jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to