search

AndreRH / hangover

Hangover runs simple Win32 applications on arm64 Linux
GNU Lesser General Public License v2.1
1.24k stars 91 forks source link

Created automatic releases #115

Closed devedse closed 5 months ago

devedse commented 3 years ago

Hi @AndreRH and @stefand ,

As I said in my issue I've created a proposal to setup automated releases. Some details and things to think about:

  1. My automated releases trigger on every commit. You could choose to only trigger a release manually. I've set this up for a mod for Valheim before: https://github.com/Loki-Valheim-Modding/loki-valheim/blob/development/.github/workflows/githubactionsbuilds.yml I personally like a build on all checkins better, but I'll leave that up to you :).
  2. The version number is automatically increased by 1 for every build. This means that versions go from 1.0.1 to 1.0.2 etc.
  3. The release is only made if all 3 builds are successful.
  4. Currently the build is triggered on both a push to master and a PR. I would advice to only do this on a push to master (as that's something triggered by you). Depending on what you want you could decide on basically skipping the "upping version" number part on normal checkins and only doing this for a manual trigger.

Anyway, I'd love to hear your ideas :).

devedse commented 3 years ago

Example release I made: https://github.com/devedse/hangover/actions/runs/673312250

AndreRH commented 3 years ago

I see the CI/CD thinking behind that, but for now a successful build doesn't justify a new version. Testing hangover is complicated and we need to do it manually. I don't want to have a version out which is fundamentally broken but builds.

devedse commented 3 years ago

Makes sense, I kindoff expected that. I'll work on building functionality to manually trigger this then.

AndreRH commented 3 years ago

we don't often release and the process for that is easy enough, so no need for effort

devedse commented 3 years ago

That's also fine, the thing I would like is to have the 3 build folders in the release output if that's possible. By having that I can more easily setup a docker image of my own which already has hangover installed.

The way I've set this up previously is by having a github actions build that you could manually start and provide a version to it. E.g. you want to release version 1.0.55 you would simply start the build, provide that version and it would create a release with the 3 zip files included. If you want I can really easily automate that for you.

Alternatively you could decide on pushing docker images to the docker hub which include the hangover source + build output without the need of all the build dependencies. (Again, something I could help you automate 😄 )

AndreRH commented 3 years ago

For https://github.com/AndreRH/hangover/releases/tag/hangover-0.5.15 we haven't had build artifacts enabled, so my assumption was that the upcoming 0.6.x release would automagically have the build assets attached. If that won't be the case, then there's work to do. Another point of optimization in the actions would be to first build wine-guests (including their dependencies of course) and pass that to the 3 architecture specific builds. The wine-guest builds should be identical anyway (they are done with mingw-64, not with a target platform specific compiler). But there'll be some issues I guess and I am not sure if it's worth the effort...

devedse commented 3 years ago

I'll leave this PR open until you release version 0.6.x and we'll see if the release includes the build artifacts. I wouldn't mind at all to help you guys further improving the release as I always like working on stuff like that.