Add github actions for automated building

[Fruktus]

🔗 Related Issues

Closes #425

❕ Summary

The goal of this PR is to introduce GitHub Actions for automated building of the game for Windows and Linux.

📜 Description

The workflow:

1. Builds the game for Windows and Linux
2. Compresses it using xz (this should help reduce the file but may not be Windows-friendly)
3. Uploads the artifacts
4. (On tag pushes) Creates a new release for tag (if not already present) and attaches the binaries to it

💬 Talking points

Stuff up for discussion/changing:

• The compression can be changed to zip to make it easier for Windows users
• The artifacts are currently named after the system but perhaps could include the version
• The workflow may be configured to run only for the tag pushes (and not for other PRs due to Actions limits like time and size - the retention can be configured though), although I thought it may help with testing the changes - it could be easily extended to run tests
• I have modified the .csproj to conditionally change the way in which the MRI is invoked, since the current setup does not work on Linux and the Linux one does not work on Windows, it could perhaps be handled differently

❔ Additional info

• ❗ Since this is a workflow file (sensitive) you should examine it carefully - make sure that you understand what it does and that it is safe
• You can preview the generated release in my fork - this can be customized or manually edited
• You can view the sample run in PR with attached artifacts here
• I am open to all suggestions, if you'd like to change it up in any way or would need clarifications on something let me know 😸
• I have set the build to bundle dotnet runtime, it seems to be the same for the official releases

[mestiez]

Super neat! Thank you! However, Windows users (which is most of them) will almost certainly have no idea what to do with the resulting archive. Should be a zip file.

[Fruktus]

Super neat! Thank you! However, Windows users (which is most of them) will almost certainly have no idea what to do with the resulting archive. Should be a zip file.

You're right, also I think it's double packed (as in directory in directory), I'll correct both of these problems soon

[mestiez]

The Windows build should be built on Linux too, but this doesn't seem to work because of the asset packing mode. The build system tries running MIR but, since it's a Windows build, only MIR.exe is present. This is my stupid mistake and the solution is to run the asset packer using dotnet run as to ensure the correct runtime. I'll try that out on Debian on WSL.

Edit: nevermind, that causes an infinite loop obviously. Starting to think that the asset packing should be done using the waapack dotnet tool instead of MIR itself. The only downside to this is that it's impossible to run the custom asset preprocessors. It's a good thing that they're not required as of now.

[Fruktus]

Yes, I've hit that wall at first when I tried to run both on Linux and finally gave up and set up a separate runner on windows. I tried packing windows build on Linux using Linux build but it didn't work sadly. I can try and come up with something else though

[Fruktus]

I've modified the workflow to produce zips (I had to add 7z on Windows since I knew no other way to create one 🙈 )

You can view the built artifacts here

Let me know if there's anything else I should add or change or feel free to modify my PR as you see fit 🚀 (I'm not sure if the asset packing on Linux is meant to be done in this PR or sometime after changing the tools, so let me know as well if I should work on it)

[mestiez]

No idea how to test this lmfao.

EDIT: I could just merge & run, or even use act to run these locally, but I don't want to actually upload any artifacts... I just want to see if it does the thing it's meant to do.

[Fruktus]

No idea how to test this lmfao.

EDIT: I could just merge & run, or even use act to run these locally, but I don't want to actually upload any artifacts... I just want to see if it does the thing it's meant to do.

Be my guest. You should have an option to authorize running these within this PR, this will create both the artifacts like here. They are workflow only and will get removed after the retention period.

As I mentioned this also provides Release feature, which will add these automatically when you push tags, you can view it here, however if you don't like this feature feel free to remove it (it's the last step in workflow)

Also, thanks for the corrections, I'm not really good at C# atm but I hope to get to the point where I'll be able to contribute at least a bit

[Fruktus]

To reiterate - the artifacts that are built as part of the check (not the release ones) are temporary, I believe the default is 90 days

[Fruktus]

One more thing - I'd suggest leaving the dev branch as a part of the workflow since this would serve as a basic test if the proposed changes do actually compile :D Later on it'd also be possible to add automated tests.

This would likely be useful for external contributors (like myself) since they could have at least a minimal validation of their changes and this could help with code review since reviewers could simply view the checks statuses or pull the builds directly.

If you don't want the artifacts then the upload can be gated similarly to how releases are configured.

Ofc this is just a suggestion