There are multiple language API libraries for APK publishing (Java, PHP, Python, etc.) and description updates, including description and changelog translations. All description text and translations can be maintained from the Player Git repository and published from a manually triggered Jenkins CI job.
Because the server already has a php server for forum, wiki and blog I suggest to use the PHP client, as we don't need to spend more VPS RAM resources for another server daemon just for this task. Jenkins is Java based but uses its own built-in server (as a self-hosted servlet). We have RAM enough nowadays to run whatever we need.
While jenkins provides it's own plugin for apk publishing, we might also consider fastlane's supply (https://github.com/fastlane/fastlane/tree/master/supply). This way we do not need to write our own script using the api libraries, but can instead work with local files and let supply handle the rest.
While we already use gradle now, we can also enable this: https://github.com/Triple-T/gradle-play-publisher
Both supply and this plugin enable us to have the metadata (i.e. description, changelog, etc) in the repository and therefor possible synchronization with transifex:
Actually I'm against full automatic Publishing because Android likes to break :D (Quality ensurance). But pushing via some script would be nice.
The "automatic" means for me that the upload from jenkins to google play does not need to go through additional steps (logging in on google play, opening developer center, uploading apk, updating description/changelog...). Also, it makes no sense to force the users to install a new version every few days (whenever a pull request is merged).
Have a look at the player-emscripten job, it has a parameter to update the web player on the homepage. What I think of is a similar switch that can be used after successful testing.
Also, even if we do not update the actual .apk, updating the description and such is worth imho.
Of course, if you want to maintain that on google play directly, it is okay by me.
My only concern was that I can't test anymore the APK before pushing it. I fully support your suggestion, makes everything easier :+1:
Most helpful comment
The "automatic" means for me that the upload from jenkins to google play does not need to go through additional steps (logging in on google play, opening developer center, uploading apk, updating description/changelog...). Also, it makes no sense to force the users to install a new version every few days (whenever a pull request is merged).
Have a look at the
player-emscriptenjob, it has a parameter to update the web player on the homepage. What I think of is a similar switch that can be used after successful testing.Also, even if we do not update the actual
.apk, updating the description and such is worth imho.Of course, if you want to maintain that on google play directly, it is okay by me.