deliver built artifacts in releases page

meleu commented 2 years ago

Purpose of this PR

Improving the github workflow to automatically deliver built artifacts in the releases page when a new tag is created.

Such artifacts are:

zip files of the cross-compiled version of RALibretro (both x86 and x64)
zip files with RAHasher for Linux (both x86 and x64)

Here's an example of the results: https://github.com/meleu/RALibretro/releases/tag/v6.6.6

Notes

I changed the Makefile to generate a zip file like RALibretro-${ARCH}-${GIT_TAG}.zip
- e.g.: RALibretro-x64-v6.6.6.zip
I changed the Makefile.RAHasher to generate a zip file like RAHasher-${ARCH}-${OS}-${GIT_TAG}.zip
- ${OS} is either windows or the value returned by uname -s
- e.g.: RAHasher-x64-Linux-v6.6.6.zip

:warning: Disclaimer

I didn't test the binaries generated by cross-compilation (I don't have a Windows machine at hand).

If some kind person (@Jamiras, @Sanaki, @televandalist) could confirm the RALibretro binaries are running fine on a Windows machine, that would be appreciated. :heart:

Download the zip file from here: https://github.com/meleu/RALibretro/releases/tag/v6.6.6

meleu commented 2 years ago

For consistency sake I've reverted my changes related to the final binary name in the Makefile.RAHasher.

Instead of changing the binary name, I've added a make zip option that will create the zip file with the pattern RAHasher-${ARCH}-${OS}-${GIT_TAG}.zip

I've updated the OP accordingly.

Jamiras commented 2 years ago

I haven't looked at the implementation yet, just the results.

Firstly, the distribution zip for the binary requires the Cores and Overlay subfolders, as well as the SDL2.dll. The other DLLs that we normally distribute appear to be getting statically included. I'm a little weary of using the cross-compiled version for distribution. I'd rather use the native Windows compilation.

Additionally, we use a different tag for the version than the release. The "v1.3.10" release is using a "1.3.10" tag. Having the "v" in the tag breaks the internal versioning logic:

Finally, I'm concerned that non-tagged commits are being promoted as releases:

There's 5 commits since the release was tagged, but the release was last updated 11 minutes ago (which corresponds to the latest commit).

meleu commented 2 years ago

Thanks for the feedback.

I started to work on this because I wanted to have the RAHasher binary with no need to build them locally (it is not a problem on my end, but it's an extra step for the users of the hascheevos script).

I tried to include RALibretro binaries as a "bonus" but as I don't have the proper toolchain to minimally test it, I'm going to reduce the scope of this PR to just: "deliver RAHasher binaries for Linux on releases page".

If you are interested in automaticalaly delivering the RALibretro binaries from the native compilation, please let me know and I can help on it.

Maybe if you add to the Makefile setup some sort of a make release packaging everything needed, I can do the rest on the github workflow.

meleu commented 2 years ago

let's do the clean way...

I'm closing this PR and then open a new one properly scoped.

RetroAchievements / RALibretro