Upload android debug apk on Release

[francisduvivier]

The last PR for #65 .
This PR's hooks in to release publish events to automatically upload the android apk for this release. This PR affects the way of working for release, so I understand if you do not want to accept it. But I just wanted to finish my proposed tasks for #65 .

Here is an example release with an automatically uploaded apk, and a the GitHub Action run for that.

Important here is that this will not trigger when you just push a tag, it will only trigger when a release is made in GitHub.
If we would also want it for tag pushes, that is possible, but then it would need to first create the release as well and it would need conditional logic for the case of a tag with no release yet and a manual release in GitHub. Or 1 way of working would need to be chosen.

Since last time a release with notes was created and for keeping it as simple as possible I used the release trigger.

This will trigger on first publication, so if you first pre-release and then release, it would only trigger on the pre-release.

Lastly, the PR also has a small refactor for the gradle.yml for less duplication.

[thias15]

Overall this looks good. Ideally, the uploaded apk would reflect the release name (version number) in the name, see release v0.1.0, in case people download different releases. But maybe this is not really necessary. I also noticed that the gradle.yml action was executed for your PR even though you did not modify anything in the Android folder. I guess there is value in having artifacts for every single commit. But at the same time, it somehow seems unnecessary to run the build check if nothing was changed in the Android source code.

[francisduvivier]

Overall this looks good. Ideally, the uploaded apk would reflect the release name (version number) in the name as for the release v0.1.0 in case people download different releases. But maybe this no really necessary. I also noticed that the gradle.yml action was executed for you PR even though you did not modify anything in the Android folder. I guess there is value in having artifacts for every single commit. But at the same time, it somehow seems unnecessary to run the build check if nothing was changed in the Android source code.

The build of the android apk in this PR is because I included '.github/workflows/gradle.yml' in the paths, I figured that if the job definition is changed, it should run also, just to show that it is still working, but I could remove that.

Adding the release version and renaming is no problem, I'll add that.

[thias15]

The build of the android apk in this PR is because I included '.github/workflows/gradle.yml' in the paths, I figured that if the job definition is changed, it should run also, just to show that it is still working, but I could remove that.

Ok, that makes sense. I did not realize. You are right, changes to the gradle.yml should also trigger a rebuild.

Adding the release version and renaming is no problem, I'll add that.

As for the naming, for the source code, Github chooses the following naming convention:
-<version_number>.
So let's follow the same naming convention (e.g. OpenBot-0.1.0.apk). I just updated the previous release accordingly.

[thias15]

One more thing. Since this is not a personal repo, but an org repo, the standard secrets.GITHUB_TOKEN may not work. I faced this issue with some other actions that sort the incoming issues. You can use secrets.GH_TOKEN instead.

I also learned that some actions (e.g. when people push from forks) do not work at all. See this commit.

Maybe you have some ideas, since you are much more experienced with actions.

[francisduvivier]

One more thing. Since this is not a personal repo, but an org repo, the standard secrets.GITHUB_TOKEN may not work. I faced this issue with some other actions that sort the incoming issues. You can use secrets.GH_TOKEN instead.

I also learned that some actions (e.g. when people push from forks) do not work at all. See this commit.

Maybe you have some ideas, since you are much more experienced with actions.

Interesting about the secrets with org repos, I'll change that to secrets.GH_TOKEN or make it conditional so it still works in forks.

And actually I don't have that much experience with Actions, I have experience with bitbucket pipelines, which is kind of similar.
But working on these PR's helped a lot for sure! Also not that much experience with pipelines with PR's that come from forks since I've been working mostly on private repo's. But I might have some idea's, I'll check it(this commit) out.

[francisduvivier]

Oh please note that I also updated the android README after creating the PR. So check if you're ok with that.

[francisduvivier]

Ok, I think I'm done, last sample release here:
https://github.com/francisduvivier/OpenBot/releases/tag/v0.1.12 (different branch name but same commit)

[francisduvivier]

Just to make sure, I also created a fork in an organisation account, merged the PR there, and created a tag to test running the action.

Looks ok there.