Create Github Action to release winget package

[jo-chemla]

Following issue #221 Uses winget-releaser I suggest a Classic Github Token with public_repo scope is created by f3d-app org or another maintainer, following this link, then the Token can be added to the f3d 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.

[mwestphal]

While I'm not against this, I fail to undersand why does we (the F3D maintainers and contributors) should be responsible to upload a binary to yet another package system. Why cant winget packager/logic grab it instead ?

Is there a documentation about the winget workflow and how it is supposed to work ?

[mwestphal]

Also, can/should we upload the nightly too ?

[jo-chemla]

The winget-pkgs is a community repository, so anyone can create a manifest for a package - which references the package name, author, installer url etc - for others to install via the winget install pachage command.
Hence why I listed f3d package myself via that PR: microsoft/winget-pkgs#172695

The automation to upload the new installer to winget-pkgs on every release usually happens on the original repo - around 200k PRs, to get an overview of the approximate count of packages hosted in this community repository - so they don't have to watch every release of every package - especially since the packages that use github release are only a portion of the standard winget packages. The github action are the way to do it, but usually involve simply forking the repo, and using the winget-releaser action to create the new PRs automatically.

Here is a bit of context in another repo - this resource is a pretty good intro to winget

[mwestphal]

Thanks for the explanation.

It happens that our binaries are created by a dedicated release workflow in another repository. I think the action you are adding would be more at home there instead of relying on the release trigger.

https://github.com/f3d-app/f3d-superbuild/blob/79c0daeabef09cfa12c2ce17b39ba83c9252d38e/.github/workflows/release.yml#L44

[jo-chemla]

Thanks for mentioning f3d-superbuild. Usually, the winget-releaser workflow actions are setup on the repo where the release contains the exe or installers, watching for the release.

I've not seen example of actions where the installer files generated by the build CI are actually used within a subsequent job of the action.

[mwestphal]

Thanks for mentioning f3d-superbuild. Usually, the winget-releaser workflow actions are setup on the repo where the release contains the exe or installers, watching for the release.

I've not seen example of actions where the installer files generated by the build CI are actually used within a subsequent job of the action.

F3D is different than many other repos as the binary package is not generated manually or from the repo itself but from another repo, the superbuild.

This repository is also responsible for generating our python wheels and publishing them on pypi. It seems logical that the winget package would be uploaded from there too imo, and at the same time.

[jo-chemla]

Understood. One thing I forgot to mention, the package manifests references the installer (or portable exe) url, so that every client machine that do run winget install xyz request the installer from that url in order to install it.

So even if the github action is moved outside to f3d-suprebuild, it would reference the installer exe url that resides in https://github.com/f3d-app/f3d/releases/
I don't know of existing github actions that allow that kind of behavior. But it is possible this would simply involve getting release url and passing it to the action, or use Komac under the hood

[mwestphal]

Understood. One thing I forgot to mention, the package manifests references the installer (or portable exe) url, so that every client machine that do run winget install xyz request the installer from that url in order to install it.

So even if the github action is moved outside to f3d-suprebuild, it would reference the installer exe url that resides in https://github.com/f3d-app/f3d/releases/ I don't know of existing github actions that allow that kind of behavior.

I'm not sure to follow, when a user do winget install f3d, does it download from https://github.com/f3d-app/f3d/releases/ or from winget servers ?

[jo-chemla]

The package manifests are stored on the community repository - and the indexes are usually updated on each machine. So when the user runs winget install F3d.F3d, the manifest (which references the metadata and installer url) is queried from the index, and the installer is requested through the url listed in the manifest, which for github packages is https://github.com/f3d-app/f3d/releases/

[mwestphal]

Ha! So this action does not even uploads the binary package, but just reference a link to it?

[jo-chemla]

Yep exactly!

[mwestphal]

Then that looks fine to merge imo. Thanks for the explanation.

[jo-chemla]

The PRs to update the package identifier on winget-pkgs have been merged, so now it can be installed via

winget source update
winget install f3d-app.f3d

[mwestphal]

Ill merge this as soon as I find the time to create the token

[mwestphal]

@jo-chemla the winget package CI failed for 3.0, wanna take a look ?

https://github.com/f3d-app/f3d/actions/runs/12852778924/job/35835166416

[jo-chemla]

Hi there, only thing I can see is the regex was maybe wrong, see the suggested edits in PR

[jo-chemla]

Ah, just saw the run logs, seems that the github personal access token you provided does not let the CI make a fork, probably the authorizations are not set the correct way? You have that PAT to allow forks.
There seem to be a bug on github side regarding authorizations for the PAT, see this issue in Komac

[mwestphal]

Ah, just saw the run logs, seems that the github personal access token you provided does not let the CI make a fork, probably the authorizations are not set the correct way? You have that PAT to allow forks. There seem to be a bug on github side regarding authorizations for the PAT, see this issue in Komac

Yeah, I forgot this and need to take a look

[mwestphal]

So I think I did whats needed, I've added a PAT, I've created a fork, its still not working. Do you have any idea @jo-chemla ?

[jo-chemla]

Sorry, from the docs it seems that Komac and winget-releaser@v2 users need a classic github api token rather than the new PAT for the action to run properly.

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 vedantmgoyal9/winget-releaser#172 for information.

The latest execution of the github action is last week Jan 20, after the also failed Jan 19. Seems the error is Failed to create branch from upstream default branch, maybe the PAT did not have pull, branch and commit authorization. Anyway, you would need a classic token while the above linked issue is resolved.