Create a github action for winget deployment

[lesquoyb]

Describe the bug Deployment to winget-pkgs can be tricky. I found out there's a github action tool that makes it possible to automate this process: winget-releaser maybe we can investigate this to see if it fits our deployment process and hopefully make it smoother for next releases.

Note: what I did to be able to push the new version on the winget-pkg repo:

• download the three previous manifests in the 1.9.1 directory
  • I put them in a folder hierarchy that follows the repo hierarchy, but I don't know if it's necessary or not. The path is: manifests\g\GamaPlatform\Gama\1.9.2\
• update them all with the new version number 1.9.2
• update the two installers in GamaPlatform.Gama.installer.yaml with the new download url
• process the sha256 of the installer file (in windows: Get-FileHash path\to\GAMA_1.9.2_Windows_with_JDK.exe -Algorithm SHA256
• update the two installers in GamaPlatform.Gama.installer.yaml with the new hash value
• locally validate with wingetcreate.exe validate path\to\yaml\directory
• try to locally install it with winget install -m path\to\yaml\directory
• submit a pull-request with: wingetcreate.exe submit --prtitle "New version: GamaPlatform.Gama version 1.9.2" path\to\yaml\directory
  • for the first version I had to agree to the microsoft policies by writing @microsoft-github-policy-service agree company="Gama-platform" in the comments of the pull request
  • https://github.com/microsoft/winget-pkgs/pull/118992
• wait for the request to be validated by a moderator

[RoiArthurB]

I would be careful adding this in our CI/CD. I'm not sure if winget is supporting pre-release and, on the way we're recently creating our release (i.e creating an alpha version, then manually renaming it and changing GH's release flag) I don't think it would help us pushing our next stable release on winget :/

A better work would be to create an extended GHA which would create a real/clean stable release on GitHub and, at the same time, publishing on every third party installers (linux, homebrew, winget, else ?)

[lesquoyb]

From what I know they don't really care if it's alpha or not, they just want a download link, probably from any reachable url. I'm not proposing that we create a job that will automatically push the latest build to the winget repo, though I'm sure it's feasible. But just to create a job that we can manually activate and that will execute the necessary commands to generate the files for a new release and create a pull request on the winget-pkg repo. That can completely be a subpart of a bigger script that will push a release on the different third party installer hosts

[WoodenMaiden]

I looked at the vedantmgoyal2009/winget-releaser@v2 action and especially Komac, the tool that it uses. Both the action and Komac seems to be widely used and effective, even though it looks like will create a repo in the organization

@lesquoyb told me that the switch from a pre-release to a release was done manually, so I created a workflow that triggers when a pre-release turns into a release.

Since there is an event with the creation of a pre-release, it would be possible to ship pre-release to winget and others.

Concerning pre-releases and winget, maybe we could have the production ready package with PackageIdentifier set as GamaPlatform.Gama, and the pre-release with PackageIdentifier set as GamaPlatform.Gama_unstable as they don't really care about wether what we gave them is a pre-release or not, moreover it is possible to delete the previous re-release we send them with the action's max-versions-to-keep input