Package: pushapkscript
pushapkscriptMain script that is aimed to be run withscriptworker(but runs perfectly fine as a standalone script). This project is a fork ofsigningscript. Most of the documentation from signing script applies to this project.Get the codeFirst, you needpython>=3.5.0.# create the virtualenv in ./venv3virtualenv3venv3# activate it.venv3/bin/activate
gitclonehttps://github.com/mozilla-releng/pushapkscriptcdpushapkscript
pipinstallpushapkscriptThen you need to installjarsigner(usually included with JDK).ConfigureJarsignerAdd the nightly certificate to the java keystore:keytool-import-keystore~/.keystores/mozilla-android-filepushapkscript/data/android-nightly.cer-aliasnightlyNote: The keystore location and the certificate alias will be used in theconfig.jsonsectionconfig.jsoncpexamples/config.example.jsonconfig.json# edit it with your favorite text editorThere are many values to edit. Example values should give you a hint about what to provide. If not, please seesigningscript's READMEfor more details about allowing URLs, or contact the author for other unclear areas.directories and file namingIf you aren't running through scriptworker, you need to manually create the directories thatwork_dirandartifact_dirpoint to.  It's better to use new directories for these rather than cluttering and potentially overwriting an existing directory.  Once you set up scriptworker, thework_dirandartifact_dirwill be regularly wiped and recreated.task.jsoncpexamples/task.example.json/path/to/work_dir# edit it with your favorite text editorOrdinarily, scriptworker would get the task definition from TaskCluster, and write it to atask.jsonin thework_dir.  Since you're initially not going to run through scriptworker, you need to put this file on disk yourself.The important entries to edit are the:apks: point to the file(s) to publish to Google Playdependencies: need to match thetaskIds of the URLs unless you modify thevalid_artifact_*config items as specified abovescopes: the first and only scope,project:releng:googleplay:*, tells which product in Google Play store should be updated (eitheraurora,beta, orrelease)google_play_track: refers to which Google Play track (either production, beta, or alpha) the APK will be uploaded(aurora, beta, release) vs (alpha, beta, production)?Google Play allows a product to have 3 different tracks (alpha,beta,production). Tracks are used by end-users when they want to enroll in a beta-testing program.However, this feature wasn't out when we started publishing Fennec. This is why Fennec is registred as 3 different product: one for each regular Firefox channel (aurora, beta, release). As a consequence, here's how products/tracks should be used.ProductBrand nameTrackNotesreleaseFirefoxproductionbetaFirefox BetaproductionauroraFirefox Aurora for Developersbetaproduction is not used to show the product is not aimed at regular usersNote: For development purpose, aurora on thealphatrack can also be used.runYou're ready to run pushapkscript!pushapkscriptCONFIG_FILEwhereCONFIG_FILEis the config json you created above.This should download the file(s) specified in the payload, check their signatures with jarsigner and publish them to Google Play Store.running through scriptworkerFollow thescriptworker readmeto set up scriptworker, and use["path/to/pushapkscript", "path/to/script_config.json"]as yourtask_script.:warning: Make sure yourwork_dirandartifact_dirpoint to the same directories between the scriptworker config and the pushapkscript config!Frequently asked questionsI'd like to test out changes in pushapkscript...Do Ineedto activate chain of trust forlocaldevelopment?No. Chain of trust is used to securely download artifacts. You can bypass that step by having artifacts already on-disk. Just put the APKs in:$work_dir/cot/$task_id/public/build/target.apk(each APK has a different task_id). Then, you canrun pushapkscript.Is there a staging instance I can push my code to?There used to be one, but it's now decommissioned. You can spawn a new instance via puppet. To do so:Create a new VM instance. You canask for a loaner.On thepuppet master node,set up a user environment.Add a new node tomoco-nodes.pp. The config example is present in this repo atexamples/puppet-node.example.pp.Activate chain of trustby creating the gpg keys and whitelisting them. Otherwise, artifacts won't be downloaded.Edit your tasks to point to a different worker-type. Define it at your will. Please do not use thedeppool because it's used outside of releng, intryfor example.On your VM, make the slavetake the config of your user environment.:warning: Likeexplained below, this instance will interact with the production instance of Google Play. Please make sure"commit": falseis in your task definitions (or don't define it).I'd like to test out Taskcluster tasks...Is there an instance which doesn't interact with production data?Sadly, no. The Google Play documentation doesn't mention any server we can plug to. This means, you will interact with production data. There are ways tomitigate the risk, though.How can I avoid to publish to actual users?There are 3 incremental ways to avoid targetting real users (or the entire user base):1. Use"commit": falsein your task definition.This will execute every step implemented in pushapkscript, but the last one, which commits the transaction to the Play store.This allows to publish the same APK several times.However, there are a few final checks that Google Play does only when the transaction is committed. We have already experienced one: the integrity of l10n stores (descriptions and "what's new" sections) is verified only at this time. We may extrapolate the behavior to: everything that can be done in several calls to Google Play will be checked at commit time.If not defined in the task payload,commitdefaults tofalse.2. Push to a closed alpha trackAt some point, you may want to publish your APK anyway.Google Play provides the ability to havea beta and alpha programwithin a product. Aurora already usesthe beta program.You can ask release management to set up a closed alpha testing on theGoogle Play console(Go to Release management -> App releases -> Manage Alpha) and target users by email address. Then, edit your task definition to contain"google_play_track": "alpha".Before going further: tear down the alpha track:warning: Once you're done with the alpha track, youmustask Release Management to close it. Google Play doesn't accept another track to have more recent version, than the alpha one. If you start using another track (without closing alpha), you may end up with the following error:HttpError 403 when requesting https://www.googleapis.com/androidpublisher/v2/applications/org.mozilla.fennec_aurora/edits/17791185193608549142:commit?alt=json returned "Version 2015491409 of this app can not be downloaded by any devices as they will all receive APKs with higher version codes.In the case where Release Management isn't connect, there's a temporary workaround:Publish the APKs on the alpha track.On the Google Play dashboard, promote the APKs to the beta (then the rollout channel). Reuploading the same APKs to the beta track won't be accepted by Google Play, because APKs can only be pushed once.3. For non-aurora products: Push to the rollout trackIf you are confident enough to publish to percentage of our user base, you can use "rollout" functionality. Just edit your task definition to contain:"channel":"production","rollout_percentage":10,if you want to target 10% of the production user base.