[Feature] Build and publish Android Debug apk from GitHub Actions about openbot HOT 3 CLOSED

Hi @francisduvivier.

This is great!

(1) I never actually checked the workflow, just assumed it worked. So this would be a great contribution! Ideally, it would only run when files in the android folder are changed and not for any push to the repo.

(2) This is also a good idea. I'm actually just about the tag the first release, now that the project seems to be semi-stable and some people were able to go through the complete process. Just to make sure. Would this only run when a new release is tagged? There should not be a new release for every push to the repo. So I guess ideally, people can download the apk from the build artifacts for every push and if a release is tagged the corresponding apk is added. Not sure if this is possible.

(3) I also agree on this and we are working on it. However, it requires some internal approvals to host the app in the Playstore.

Anyways, open to discussions. You obviously have much more experience than me with this.

from openbot.

(1) Good point regarding changed files, we can arrange that with https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths,

(2) Yes I should actually split this in 2 parts as well since there is a difference between GitHub release assets and GitHub Action build artifacts. And so actually I would say that we use the build artifacts every time the apk is built, since the time-cost of uploading is very small compared to the build and it is IMO useful if you on every PR with changed android files can easily download the apk and quickly check the functionality when you want to. Also people who need access to a quick fix which is not released yet but is already on master could use this, or if you want people to check that a PR fixes their android issue for them.
Then as a 2.2 step, we can upload the same artifacts as a release asset in case of a tagged release, but it's a different trigger, different destination and a different Github Action, so it's quite a separate thing.

(3) Indeed, I am certainly not expecting this to be done anytime soon and I think the above stuff can stand fine on its own, it was just my Idea of where this could eventually go. Having a signing key would certainly already be a good step, so that you can upload the release version to the release assets and so that it is not signed with the google debug key. But yeah, you need to make sure that this key can only be used when authorized by owners, I don't know if there is a way to automate that in a public Github project.

from openbot.

This issue is completed with #68, #73 and #74.

from openbot.