Winget-release github action

[jo-chemla]

Description:

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

[jo-chemla]

According to the list of recent Github Actions runs, it looks that a maintainer needs to validate the winget-release. Note as mentioned in the original linked issue #168 that when merging this PR, you will need to proceed with a few steps for the final workflow to run smoothly and automatically on every github release:

• You will need to create a classic Personal Access Token (PAT) with public_repo scope.
• This token should be added as a repository secret by creating a new repo secret with name WINGET_ACC_TOKEN and value the token
• Fork microsoft/winget-pkgs under the same account/organization as the project's repository. If you are forking winget-pkgs on a different account (e.g. bot/personal account), you can use the fork-user input to specify the username of the account where the fork is present.

[Jacalz]

Sorry for the slow response. I have been rather busy and forgot about reviewing this. Will have a look as soon as I have some time over. Thanks for working on this.

[Jacalz]

Hi again. I have now released v3.7.0 with and important dependency fix which makes the project buildable again after a dependency changed its import path so this seems relevant to look at again. Is it possible to make this build the application directly instead of just pulling down a pre-built exe? Doing the latter seems to me like it adds no very little compared to the time I have to put into maintaining this. Especially for an operating system that I neither like, use nor have easy access to for testing purposes.

[Jacalz]

See https://github.com/Jacalz/rymdport/releases/tag/v3.7.0 for more information as to why I would prefer it to build directly. I am a bit tired of managing cross-compilation toolchains on my end.

[jo-chemla]

Hi there, thanks for getting back and congrats on the 3.7.0 release. The winget-pkgs repo only accepts pre-builts installers or executables - eventually zipped - and the PR I made looks for one or more exes in the github release to push these new version packages to winget-pkgs.

If you first want github to build these executables for eg the windows platform, this is probably doable via another github action. Github has a dedicated post regarding go build Github Action workflow CI here, this is probably where you'd like to have a look first.

[Jacalz]

Thanks.

Hmm. Only allowing .exe files from a random location seems like a supply chain attack waiting to happen. Anyway, not my problem to worry about :)

Thanks for the hint about GitHub CI. That might fix half of the problem but I suppose it still would be needed to do cross-compiling for other architectures like arm64 unfortunately :/

[Jacalz]

I've thought a bit more about this and I'm afraid that I don't have any intention of maintaining a winget package on my own. There are a few reasons for this:

1. I don't use Windows myself and as such I don't wish to personally maintain a package for that system (binaries and support for Windows will of course still be available to as large an extent as possible but with little testing from my own side).

2. Just repackaging .exe files does not seem very helpful and still relies on working cross-compilation somewhere else to build the binaries.

However, I will not be against if anyone else wants to maintain a package just like some Linux distributions do.

[jo-chemla]

Understood, thanks for the feedback! The winget package will still be available on the official winget-pkgs repo, and package updates will then be manually pushed by community then.

[Jacalz]

Cool. That sounds like a good plan. Give that it is how most Linux packages are maintained, I find it good to be consistent there :)