Github Action to auto push new releases to Winget package registry

[jo-chemla]

Note, at the moment, there are unofficial bots maintaining the winget package given github releases see example PR microsoft/winget-pkgs#276316

It would be great to use a github action in this repo to push every new github release to the winget package registry CNRISTI.MeshLab .

This PR uses winget-releaser (which uses Komac). It requires a Classic Github Personal Access Token with public_repo scope is created, following this link, then the Token can be added to the repo as a secret named WINGET_ACC_TOKEN. See below, that user also will have to fork the winget-pkgs repository.

Notes:
You will need to create a classic Personal Access Token (PAT) with public_repo scope. New fine-grained PATs aren't supported by the action. Review #172 for information.
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.

[alemuntoni]

Thanks @jo-chemla, I did not know about winget.

The only problem I see is that the first installer uploaded after a new release is published isn't signed. I have to manually sign the file, then replace the published .exe with the signed version...

This could be solved by running this action manually, but I'm not sure how to make it refer to the last release instead of using ${{ github.event.release.tag_name }}...

[jo-chemla]

I've been relying on winget for the past few years, and it's indeed pretty useful, comes pre-installed from win >= 11, helps install/update software on multiple machines at once with simple commands.

Thanks for the precision regarding the signing process, indeed might be a bit trickier.

The best route would probably be for that executables signing process to be encapsulated into the automated build workflow, would that be possible? I imagine you would have to pass the key/cert as a repo secret if this is ok on your side (cannot ever be retrieved by other repo members, but github would have access to it even if it won't leak it).

On another repo Victor-IX/Blender-Launcher-V2, the action yaml looks like the following, so running it manually can be passed a user-defined tag version like screenshot below.

Hope this helps clarify things and what would be the best way to do it!

name: Winget Release
on:
  workflow_run:
    workflows: ["Windows Release"]
    types:
      - completed
  workflow_dispatch:
    inputs:
      tag_name:
        description: "Specific tag name"
        required: false
        type: string
jobs:
  winget-publish:
    name: Publish winget package
    runs-on: ubuntu-latest
    if: ${{ !contains(github.event.release.tag_name, '-rc')}}
    steps:
      - name: Set winget version env
        env:
          TAG_NAME: ${{ inputs.tag_name || github.event.release.tag_name }}
        run: echo "WINGET_TAG_NAME=$(echo ${TAG_NAME#v})" >> $GITHUB_ENV
      - name: Submit package to Windows Package Manager Community Repository
        uses: vedantmgoyal2009/winget-releaser@v2
        with:
          identifier: VictorIX.BlenderLauncher
          installers-regex: '^Blender_Launcher_v[\d.]+_Windows_x64\.zip$'
          version: ${{ env.WINGET_TAG_NAME }}
          release-tag: ${{ inputs.tag_name || github.event.release.tag_name }}
          token: ${{ secrets.WINGET_ACC_TOKEN }}
          # fork-user: Victor-IX

[alemuntoni]

The best route would probably be for that executables signing process to be encapsulated into the automated build workflow, would that be possible?

Unfortunately, for us it is not possible anymore. The only certificate we could afford was shipped with a FIPS USB token (which is mandatory by microsoft, as far as I know) that is kind of impossible to use on linux and therefore impossible to automatize with scripts on a server.

The second strategy you suggested looks good! I'll take a look on it soon!
Thanks again!

[jo-chemla]

Understood, thanks for getting back! Don't hesitate if you have any comments.

[jo-chemla]

By the way, if you want to avoid inputting the tag string manually, you could run the action manually from a specific release tag name as seen here: https://github.com/orgs/community/discussions/45871#discussioncomment-9945812

Also, is the release in prerelease/draft state while you sign and upload the binary? If so, the workflow could listen to published or release status changes, see release event. Would mean the winget release could be automated, awaiting the release to switch from draft to published state, which you would do when uploading the signed binary.