search

ImranR98 / Obtainium

Get Android app updates straight from the source.
https://obtainium.imranr.dev
GNU General Public License v3.0
7.47k stars 164 forks source link

Build and Release updates with GitHub Actions #513

Closed ghost closed 1 year ago

ghost commented 1 year ago

I like your wonderful app and I have been using it for a while now, however can you please consider using GitHub Actions to build and release your updates, just to offer more transparency so people can actually verify everything that happens and make things easier on you in the future, you won't have to build then upload everytime you change something.

You have all my respect for your efforts to build such a great app, I hope you will think about my suggestion.

iDazai commented 1 year ago

I like this idea. One app where I'd use it is Element. The .apk on github is the one with google services, but in their github actions list there is also the fdroid version. Neither the app in the Fdroid repo, nor the Google Play repo is as up to date as the Github version is. For example: https://github.com/vector-im/element-android/actions/runs/5146729889

ghost commented 1 year ago

Well, I did it my self, you can take a look at my script and tweak it as you wish so you don't have to write a new one from scratch, many steps will be removed because you are the owner of the main repository.

https://github.com/JohnBetaro/Obtainium

ImranR98 commented 1 year ago

Thanks @JohnBetaro for your work on this. I made some changes (tagging, manual-only trigger, etc.) - latest release was done through GitHub actions: https://github.com/ImranR98/Obtainium/actions/workflows/release.yml

ghost commented 1 year ago

I hope you will not make drafts anymore before releasing, other than that I have nothing to say but thank you for your hard work.

ImranR98 commented 1 year ago

I decided to trigger the job manually instead of on merges since sometimes things get merged that aren't ready for release (for example I might not have incremented the package version yet). You're right about the draft though, I guess it's fine to release directly since the trigger is manual already.

ghost commented 1 year ago

I decided to trigger the job manually instead of on merges since sometimes things get merged that aren't ready for release (for example I might not have incremented the package version yet).

You can make it trigger on every new tag made by you manually, this way you will remove many complicated steps of checking the version and tagging before the release, and it will automatically upload the artifacts to the latest release.

And if you no longer will publish a prerelease in the future you can just remove prerelease: true with one simple commit.