search

twohoursonelife / OneLife

Two Hours One Life, building upon One Hour One Life. Join us on Discord to play.
https://twohoursonelife.com
Other
46 stars 39 forks source link

Automate windows and linux client releases #216

Closed ghost closed 1 year ago

ghost commented 1 year ago

Use Github CI to build & push build artifacts to Github's releases page automatically on new tag push.

Flow:

  1. Check for dependent repositories are all up to date (minorGems and OneLifeData7).
  2. Ensure all upstream commits in OneLife ready to be tagged.
  3. git tag -a 2HOL_vVERSION
  4. git push origin 2HOL_vVERSION and will automatically triggers CI to build & release.
  5. Go to Github releases pages to see prerelease feed (intentional for final review/testing), update descriptions/title accordingly and re-release as official full release.
ghost commented 1 year ago

Hi! I've pushed a new commit to address the requirement of OneLifeData7 tag check. Now, the CI actions will abort if the pushed OneLife tag isn't equal to that of OneLifeData7.

Example tag check failure.

However, I'm not 100% sure regarding minorGems tag check. It doesn't seem to get consistently updated like OneLifeData7 before every official release. There's no clear indicator for me to ensure compatibility of them both. I'll leave this one out for now.

Also a bit off-topic, it's totally fine if this PR got rejected for whatever reason (i.e, don't fix things that didn't break). I just wanted to streamline the building process in my github's repo end, and thought might as well share this change to upstream if it's potentially going to be helpful. :blush:

ghost commented 1 year ago

I'm closing this PR because I don't think it's robust enough as the primary automated path to release official clients.

There are also plenty of things that this PR didn't tackle which it should:

  1. proper APT packages & dependencies folder caching (not a huge deal as I reckon releases are rarely done)
  2. windows executables signing (to satisfy Window's & AVs defensive measures)
  3. optimized build mode & executable stripping (I believe at this time of writing, makeFullGameFolderForRelease.sh only defaults to debug build and I don't see any flag to turn this on)
  4. dealing with auto update and hot fixes

I could address 3. and 1. by sending relevant patches to miniOneLifeCompile scripts repo to make this available, but lacking 2. and 4. still isn't satisfactory to me and I'm not knowledgeable with 2. & 4. to deal with properly which I now learned to be an important part of the release process.

While this patch works great for my own personal test client builds and purposes, after a second thought, I don't think the current patch is good enough for the original intended purpose and I personally do not have the time and interest to ensure all the mentioned points implemented correctly.

Although feel free to use this PR as a future reference in case someone else more experienced with Github actions/docker and the overall release process want to complete this.