From code to deployment

So, your code works! You've solved all the bugs and now you just need to get it out to everyone!

So, how does THAT work?

The process has two major parts, one is "Getting your code in the main repository" and the other is "Deploying versions" - as a developer, you'll be taking an active part in the first process, but the second process is on me =)

Getting your code in the main repo

• First off, push your changes with Git to your own branch at https://github.com/YourUsername/Unciv.git. I hope you've been doing this during development too, but that's none of my business *sips tea*
• Issue a pull request from https://github.com/YourUsername/Unciv - from the Pull Requests is the simplest
• The Travis build will check that your proposed change builds properly and passes all tests
• I'll go over your pull request and will ask questions and request changes - this is not only for code quality and standard, it's mostly so you can learn how the repo works for the next change you make =)
• When everything looks good, I'll merge your code in and it'll enter the next release!

Deploying versions

When I'm ready to release a new version I:

• Comment "merge translations" in one of the open PRs tagged as 'mergeable translation' to trigger the translation branch creation, add a "summary" comment to trigger summary generation, merge the PR and delete the branch (so next version translation branch starts fresh)
• From my workstation - pull the latest changes and run the translation generation
• Change the versionCode and versionName in the Android build.gradle so that Google Play and F-droid can recognize that it's a different release
• Add an entry in the changelog.md done, WITHOUT hashtags, and less than 500 characters (that's the limit for Google play entries). The formatting needs to be exact or the text sent to Discord, the Github release etc. won't be complete.
• Add a tag to the commit of the version. When the Github action sees that we've added a tag, it will run a build, and this time (because of the configuration we put in the yml file file), it will:
  • Pack a .jar file, which will work for every operating system with Java
  • Use Linux and Windows JDKs to create standalone zips for 32 and 64 bit systems, because we can't rely on the fact that users will have a JRE
  • Download Butler and use it to push the new versions to the itch.io page
  • Read the changelog.md file to get the changes for the latest version
  • Upload all of these files to a new release on Github, with the release notes, which will get added to the Releases page
  • Send an announcement on the Discord server of the version release and release notes via webhook
  • Pack, Sign, and Upload a new APK to the Google Play Console at 10% rollout
• The F-Droid bot checks periodically if we added a new tag. When it recognizes that we did, it will update the yaml file here
  • When the bot next runs and sees that there's a version it doesn't have a release for, it will attempt to build the new release. The log of the build will be added here (redirects to the latest build), and the new release will eventually be available here

About Google Play publishing

+We start at a 10% rollout, after a day with no major problems go to 30%, and after another day to 100%. If you were counting that means that most players will get the new version after 2+ days. + +If there were problems, we halt the current rollout, fix the problems, and release a patch version, which starts at 10% again. + +Dear future me - the automation was extremely annoying guesswork to set up, so the facts you need to know are:

• There is a user at the Google Cloud Platform Account Manager called Unciv_Upload_Account. There is an access key to this account, in json, stored as the Github secret GOOGLE_PLAY_SERVICE_ACCOUNT_JSON.
• This user was granted ADMIN permissions to the Google Play (after much trial and error since nothing else seemed to work) under User > Users and Permissions. Under Manage > Account permissions, you can see that it has Admin.