Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Plugin Information

View PagerDuty on the plugin site for more information.

Allows users to trigger postbuild incidents via PagerDuty

Features

Trigger incidents on single job Success/FailureTrigger incidents based on number of consecutive build resultsRequirements
Jenkins
Jenkins version 1.580.1 or newer is required.

PagerDuty account
For the initial setup only, you must have access to a Google account which owns the Google Play publisher account.

Note that having admin access is not enough; you need the account owner.
You can see who the account owner is under Settings → User accounts & rights in the Google Play developer console.

Please note

Any APKs uploaded will be published by Google Play immediately; they will not be held in a draft or pending state
The app being uploaded must already exist in Google Play; you cannot use the API to upload brand new apps
Even if you're only uploading alpha or beta apps, you still need to give Jenkins access to the Manage Production APKs permission

The Google Play API team have "noted this behavior in August 2014 and are still investigating the most secure and efficient way to resolve access issues using the API" (as of April 2015)

Setup
One-time: Set up Google Play credentials
The following initial setup process is demonstrated in this video: https://www.youtube.com/watch?v=txdPSJF94RM

Install plugin
Install this plugin via the Jenkins plugin manager.
Or if installing the plugin via other means, ensure that the prerequisite Google OAuth Plugin, Token Macro Plugin and their dependencies are also installed.

Create Google service account
To enable automated access to your Google Play account, you must create a service account:

Sign in to the Google Play developer console as the account owner
Select Settings → API access
Click "Create new project"
Once created, click "Create Service Account"
Follow the link to the Google Developers Console
Create a new OAuth client ID
Select "Service Account" as the type
Note that a .p12 file is downloaded, probably named "Google Play Android Developer-xxxxxxxxxxxx.p12"
Copy the email address of the service account created

Assign permissions to the service account

Return to the Google Play developer console page
Click "Finished" on the dialog
Note that the service account has associated with the Google Play publisher account
Click the "Grant access" button for the account
Ensure at least the following permissions are enabled:

Edit store listing, pricing & distribution
Manage Production APKs
Manage Alpha & Beta APKs
Manage Alpha & Beta users

Click "Add user"
You can now log out of the Google Play publisher account

Add the service account to Jenkins:

Navigate to your Jenkins instance
Select "Credentials" from the Jenkins sidebar
Choose a credentials domain and click "Add Credentials"
From the "Kind" drop-down, choose "Google Service Account from private key"
Enter a name for the credential — the actual value is not important
Choose the "P12 key" type
Paste in the service account email address
Upload the .p12 file that was downloaded by the Google Developers Console
Click "OK" to create the credential

Jenkins now has the required credentials and permissions in order to publish to Google Play.

Per-job config
Uploading an APK
The following job setup process is demonstrated in this video: https://www.youtube.com/watch?v=iu-bLY9-jkc

Create a new free-style software project
Ensure, via whatever build steps you need, that the APK(s) you want to upload will be available in the build's workspace
Add the "Upload Android APK to Google Play" post-build action
Select the credential name from the drop-down list

The credential must belong to the Google Play account which owns the app to be uploaded

Enter paths and/or wildcards pointing to the APK or APKs to be uploaded

This can be an Ant-style */-release.apk pattern, or a comma-separated list of filenames, relative to the root of the workspace

Choose the track to which the APKs should be deployed

If you're using Jenkins to deploy a production release, you can choose a rollout percentage

Optionally choose "Add language" to associate release notes with the uploaded APK(s)

You add entries for as many or as few of your supported language as you wish, but each language must already have been added to your app, under the "Store Listing" section in the Google Play Developer Console.

APK expansion files
You can optionally add up to two expansion files for each APK being uploaded.

A list of expansion files can be specified in the same way as APKs, though note that they must be named in the format main.<expansion-version>.<package-name>.obb.

See the inline help for more details.

Moving existing APK(s) to another release track
If you have already uploaded an app to the alpha track (for example), you can later use Jenkins to re-assign that version to the beta or production release track.
Under the "Build" section of the job configuration, add the "Move Android APKs to a different release track" build step and configure the new release track.

You can tell Jenkins which APKs to be moved by either entering the APK version codes directly, or by providing the APK files, from which the plugin will read the application ID and version codes for you.

Feedback wanted
If you're a user of expansion files, especially if you use multiple APKs, it would be helpful to know how you normally use expansion files, and whether what the plugin provides is adequate.
Do you normally have separate main/patch expansion files for each of the APKs, or is it more common for all APKs to share the same expansion files?

Currently the former case isn't possible when trying to re-use expansion files from existing APKs (without having you explicitly specify which expansion files from which old APKs should be re-used with which newly-uploaded APKs).

Let me know via the maintainer email at the top of the page!

Troubleshooting
Error messages from the plugin (many of which come directly from the Google Play API) should generally be self-explanatory.

If you're having trouble getting a certain config to work, try uploading the same APKs manually to Google Play. There you'll likely see the reason for failure, e.g. a version code conflict or similar.

Otherwise, please file a bug report or send an email with details, including the build console log output; see info box at the top of the page.

Frequently asked questions

What if I want to upload APKs with multiple, different application IDs (i.e. build flavours)?
Using the build flavours feature of the Android Gradle build system, it's possible to have a single Android build which produces multiple APKs, each with a different application ID.
e.g. You could have application IDs "com.example.app" and "com.example.app.pro" for free and paid versions.

As these will often be built in a single Jenkins job, people have wondered why this plugin will refuse to upload APKs with differing application IDs in a single job.

However, as far as Google Play is concerned, these are completely separate apps. This is correct and, as such, they should be uploaded in separate Jenkins builds: one per application ID.

If the plugin did allow this and you were to attempt to upload, say three, completely different APKs in one Jenkins build, this would require opening and committing three separate "edit sessions" with the Google Play API. If any one of these were to fail — maybe because of an invalid APK, versionCode conflict, or due to an API failure (which, unfortunately, is not uncommon with the Google Play API) — you would end up with your Google Play account in an inconsistent state. Your Jenkins build would be marked as failed, but one or more applications will have actually been uploaded and published to Google Play, and you would have to fix the situation manually. Also, you would not be able to simply re-run the build, as it would fail due to already-existing APKs.

The 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.
This can be achieved, 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.

TODO: Provide more information on how to set this up.

Version history
Version 0.2.0 (September 25, 2015)

Initial public release

  • No labels