feat: workflow and build updates

[jonstelly]

Changes

• combine pre-release and tagged-release workflows - just looking to simplify/combine the tagged and pre-release build workflows, there's a bit of conditional logic in just a few places in the release workflow, mainly around the release creation
• macos 15 runners - macos 13 runners were deprecated/removed and I don't think github has a macos 14 intel runner so I moved everything macos to macos 15
• add linux arm build - copied linux x86-64 job to create a linux arm build
• updated release action - the previous release action has archived their repository so assuming it's no longer maintained, just switched to a different popular release action, seems to have roughly same features

Open questions / notes

• I'm not familiar with nix cachix stuff, but I think I also need to add a nix build for linux-arm in the cachix.yml
• In the combined release flow, I added:
  • ability to manually trigger a release from a branch (trigger a release from any branch via github ui)
  • in manually triggered releases, ability to specify a name for the build
  • pre-release release tag (not git tag) that's either the manually-specified name, or the branch name. I believe this would allow having 1 pre-release per branch (or manual name)... it keeps most of the benefit of pre-release 'latest' tag to keep release storage needs low (new releases overwrite old with same release tag), but support builds from multiple branches. I'm still testing this
• I added architecture tags to the binary/release-artifact names, all binaries in release are lan-mouse-<OS>-<ARCH>... There are so many different standards for architecture tags, I don't have any strong feelings so happy to use the same tags everywhere or whatever you'd like. I generally think amd64 and arm64 are too similar which is why I went with x86-64 for linux and windows and intel for macos (feels more common for macos things).
• I tried to add a windows arm build/release as well, but it was having issues with gtk4, and I've heard that windows intel emulation on arm windows is alright, so there's probably not a ton of value to having a separate windows arm build IMO

[feschber]

Do we have a way of testing this?

[jonstelly]

I've tested it a good bit in my repo here. The weirdness about github actions and how they primarily use the main/default branch's workflows to trigger means it might be tough to test here before merging...

You could create a separate organization, fork lan-mouse there, then do testing there? Or I'm happy to make you a contributor on my fork of the project so you can test there?

Theme of consolidation change is:

• Instead of only keeping 1 development build, it's possible to create multiple development builds with different tags, so in my repo for instance there are 'dev' and 'main' development releases, the goal here is to allow multiple work-streams or feature branches that could each have a built/published release
• Can manually trigger a release from any branch in the github actions ui

The above are all development / preview releases, for official/versioned/tagged releases it's the same process you have here now, just push a tag and that creates a non-prerelease release

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[feschber]

It seems like you accidentally re-added the tagged-release.yml when force pushing ...

[feschber]

I added architecture tags to the binary/release-artifact names, all binaries in release are lan-mouse--... There are so many different standards for architecture tags, I don't have any strong feelings so happy to use the same tags everywhere or whatever you'd like. I generally think amd64 and arm64 are too similar which is why I went with x86-64 for linux and windows and intel for macos (feels more common for macos things).

I don't have strong opinions on wether it should be arm64 or aarch64 but currently it's just "arm". Should probably change that to arm64