Github Actions workflow

[gentslava]

Hey @theothernt
I've prepared GHA workflows:

• release.yml - Automatically builds apk and app bundle (aab), you just need to create a release.
• ci.yml - CI workflow runs integration tests, test build, etc. on every push to master.

The release workflow can also provide multiple builds for all flavors. There is only githubRelease at the moment.
Easy to add any flavor on request.
Finally, all you need to do is create a release tag and the workflow will start bundling and uploading all the artifacts, and at the end it will add the Github APK to the release page.

I'm sure that will boost your bundling time 🚀
Be free to contact me for any assistance to speed-up GHA integration.

[gentslava]

The Matrix strategy allows to run multiple builds in parallel for all flavors, for example [github, googleplay]:

[theothernt]

Thanks for this PR, this was something I never got time to look into!

I will have a few questions and suggestions, if you don't mind...

1. Are the Release and CI paths separate? (I assume they are, just wanted to check)
2. Did you use the BASE64 option for encoding the keyfile?
3. Can a Release be built and uploaded as a Draft Release (I hand create the release notes as the Play Store has a short desc. limit)
4. For the moment, being able to build release packages for GitHub (apk), Google Play (aab bundle) and Amazon App Store (aab bundle) based on a tag would be the most helpful.

[gentslava]

1. Yes, that's right. These are different workflows. One works when creating a release, the second for pushing to master. For each workflow, you can set events for which it should trigger. For pushing to master, a workflow is usually written for the CI to check the functionality of the entire code.
2. I just uploaded the keystore file to a new private repository. And saved in secrets the repository name and access token. So, the runner just checkout this repository at the build time to use it for sign.
3. No, docs say Workflows are not triggered for draft releases. Currently, the release workflow is triggered by the pushing of a new tag and uploads the assembled apk to the linked release. More about events for GHA - https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows
4. I've already prepared build matrix for GitHub and Google Play - apk and aab for both. It can be defined that for each only one thing is collected. Well, and add Amazon assembly - literally add one word to the matrix array :)

[gentslava]

Added Amazon, excluded creating aab for GH and apk for GP and Amazon.

Disabled CI for master push. To enable just replace main with master branch name :)

Also updated prev comment with actual info, check 3 point again 👆🏻

[gentslava]

@theothernt detailed info about secrets, value stored them:
KEYSTORE_ACCESS_TOKEN - Personal access token generated on GH here. It must to have repo rights to access private repos.
KEYSTORE_GIT_REPOSITORY - Just username/reponame of private repository with keystore
KEYSTORE_FILE - path to keystore file after checkout repo to app/keystore. E.g. keystore/KeyStore.jks
KEYSTORE_PASSWORD - keystore password
RELEASE_SIGN_KEY_ALIAS - key alias in your keystore
RELEASE_SIGN_KEY_PASSWORD - key password in keystore

[gentslava]

Prepared a bump step in the Release workflow.
Automate versionCode bumps and versionName changes in the app/build.gradle.kts
It increases versionCode and replaces versionName with new tag name. After it commits with verified.

This commit is on the automatic_ver_bumps now.
Can add to the current PR or create new one for the next release.

[theothernt]

This all looks great, I'll make time to play it with a bit more in a couple of days!

[gentslava]

Later we could try to add Lokalise to CI pipeline!
For example, it could send new en-strings to Lokalise that are sent to master. And pull all localizations from Lokalise with Release flow.
https://lokalise.com/blog/how-to-continuously-localize-your-front-end-resource-files-using-github-actions/

[theothernt]

Yes, that would also be a time saver.

When a release is nearly ready, I pull all the new or update strings into Lokalise with their GitHub addon.

But, when all the strings are translated, I have to manually integrate the strings back into the project as Lokalise sees Android .XML files and .JSON files are two different 'groups'.

Also, I would like to add the Play Store, etc descriptions to the repo so they can be translated as well.

[gentslava]

💯 It could be done without human participation.
We have to prepare a script or use a ready-made one to translate JSON to XML and back.

Translating the Play Store description and What's New is a good idea! Let the native speakers do it)

[theothernt]

Sorry about the delay, I should have time to approve the PR this week!