-
Notifications
You must be signed in to change notification settings - Fork 511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upload android debug apk on Release #74
Upload android debug apk on Release #74
Conversation
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. |
a4a42fb
to
47d3af2
Compare
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. |
Ok, that makes sense. I did not realize. You are right, changes to the gradle.yml should also trigger a rebuild.
As for the naming, for the source code, Github chooses the following naming convention: |
One more thing. Since this is not a personal repo, but an org repo, the standard 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. |
Oh please note that I also updated the android README after creating the PR. So check if you're ok with that. |
47d3af2
to
22ad4ca
Compare
Ok, I think I'm done, last sample release here: |
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.