Build and release Windows binaries

[ThreeDeeJay]

Adds a GitHub actions workflow to compile Win64 executable with dependencies and uploads them to the workflow and releases for people to download easily without an account. It uses the date, commit number (r###) and commit hash (@abc1234) for versioning, though if needed I think I could also prepend the lastest tag (bino-2.2 or whichever is the most recent at the time of compilation). Also, keep in mind that the latest release will get rewritten on every build.

[marlam]

Thank you very much for this! I never looked into this kind of Github functionality, and I am amazed that it seems to work.

But would it be ok for you if you keep that functionality in your fork?

The main reason is that I'd like to deal with source code only, and not take responsibility for any binaries. In this case, especially, there seems to be a tree of dependencies via the uses directives that I don't know, so I cannot know exactly what ends up in the binaries that come out of this process.

Furthermore, I hesitate to rely on any advanced Github features because at some point it will become necessary to switch to a different hosting platform, and untangling the dependencies gets messy at that point (I realize that this may seem a strange point of view, but I'm old enough to have migrated projects away from SourceForge, Savannah and other platforms, and it's a pain).

[ThreeDeeJay]

AFAIK all the uses actions are open source right here on GitHub so you could inspect the code and maybe specify a tag or even commit you've audited after the @ (or even fork to link your own static version). For example, uses: jurplel/install-qt-action@v4 is just https://github.com/jurplel/install-qt-action/tree/v4.0.0 and it seems to be trusted by many projects.

If you want you could also look at the actions' source code to gather the commands that get executed to make CIs transferable. I even prefer it that way, at least when it's a simple command I'm familiar with. Like I use run: git clone --recurse-submodules https://github.com/${{github.repository}}.git . instead of the more common - uses: actions/checkout@v4. However, there are certain actions that just seem tedious to replicate by hand (like installing a specific QT version) so personally I don't bother with it lol

Also, perhaps we could use RelWithDebInfo or Debug configuration for symbols or something to make sure executables weren't tampered with (worst case scenario, it gets bundled with Bing bar or god forbid the Edge browser 😂). But personally, as a Windows user, I'm perfectly fine trading a reasonable risk for convenience (especially with open source projects) and a disclaimer pointing out that the binaries were compiled by GitHub and not verified by developers would definitely not stop a Windows user like me in the slightest, especially when the alternative is having to compile locally myself, which I (and probably most regular people, really) dread. 😅

And the problem with keeping automatic builds in a fork is that they have significantly less exposure, and updates upstream require a manual merge. But anyway, I'm okay with keeping builds in my fork to point my fellow lazy Windows brethren to 🗿

[marlam]

I added a link to your Github fork to the Bino download page -- is that ok for you?

[ThreeDeeJay]

I guess so 😔