GitHub action to integrate with winget-release upon releaser

[assarbad]

• This uses https://github.com/marketplace/actions/winget-releaser with Komac under the hood to initiate a pull request to microsoft/winget-pkgs whenever a release is created
• Tags are expected to carry on the existing scheme of giving the bare segmented version number ... if this changes, the action needs to be adjusted
• This action has further prerequisites:
  • someone associated with the Conan project should create a (classic) personal access token (https://github.com/settings/tokens) with scope public_repo (no other scopes should be active)
  • the main conan-io/project should get a secret (https://github.com/conan-io/conan/settings/secrets/actions) configured with the name WINGET_TOKEN
  • furthermore someone associated with the Conan project should fork microsoft/winget-pkgs
  • if it gets forked to their personal user account fork-user needs to be configured accordingly
  • it's implied that full access is possible for said user to said fork; PRs initiated via this action will be issued from this fork of winget-pkgs
  • the maintainer of winget-releaser suggests strongly to keep the fork up-to-date via the Pull app (https://github.com/wei/pull) as well -- I reckon the main purpose is to provide clean pull requests with the least amount of friction or risk of conflict
  • after that everything should be in place to upgrade the existing winget-pkgs manifest
  • NB: if desired max-versions-to-keep can be configured to limit the number of older version manifests available (e.g. if the old version downloads are known to disappear at a certain cadence)
    • please note that when initially configuring this, it will likely (haven't tried it) result in one PR per culled old version, since winget-pkgs has the rule of modifying only a single manifest per PR! This is one of the reasons I opted to stick with the minimal configuration for this action.

Changelog: (Feature | Fix | Bugfix): Describe here your pull request Docs: https://github.com/conan-io/docs/pull/XXXX

• [ ] Refer to the issue that supports this Pull Request.
• [ ] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• [x] I've read the Contributing guide.
• [ ] I've followed the PEP8 style guides for Python code.
• [ ] I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

[CLAassistant]

All committers have signed the CLA.

[assarbad]

Hi folks, still preparing this. Same person as #16979, but this is my account outside of work. I also did a few of the PRs to bring the winget-pkgs manifest for Conan up-to-date (latest microsoft/winget-pkgs#179052).

This PR will require some assistance and preparation by at least one project member to get the GitHub action going.

FWIW the process I outlined for another project windirstat/issues#88 is probably applicable here as well. But since the existing manifest seems much closer to what Komac expects, I expect less problems here.

I will try this out via my own fork, creating one (or a few) PRs with a fake (re-release) of the 2.8.0 Windows installers. No worries, I'll close the PRs almost immediately. Having contributed to microsoft/winget-pkgs before, I am confident that none of these test PRs would go through accidentally.

PS: Could one of you — @czoido or @memsharded — provide guidance please. It feels like several of those checkboxes above don't exactly apply for a PR like this one.

[memsharded]

Hi @assarbad

Thanks for your contribution.

We are at this moment exploring the possibility to move our Conan client CI to GH actions. If this action helps improving the automation for winget, that would be a good addition, but it would be important that this wouldn't cause any disruptions or blockage to the Conan releases if something goes wrong in this action, and also to consider possible future maintenance cost. From the code, it seems the action is pretty simple, but just to make sure about possible future issues.

In any case, I'd prefer to wait a bit until we move the main CI to GH actions (if it happens, still evaluating), we get a bit more used to them, and resume this one from there. I think that one or two releases once we move to CI with GH actions would be good to continue with this.

Thanks very much!

[assarbad]

We are at this moment exploring the possibility to move our Conan client CI to GH actions. If this action helps improving the automation for winget, that would be a good addition, but it would be important that this wouldn't cause any disruptions or blockage to the Conan releases if something goes wrong in this action, and also to consider possible future maintenance cost. From the code, it seems the action is pretty simple, but just to make sure about possible future issues.

@memsharded Understood. So to the best of my knowledge here is how it works (some further findings about Komac and winget-releaser are documented in windirstat/windirstat#88).

• winget-releaser uses Komac under the hood
• Komac is cross-platform and can be invoked manually from your shell
• The winget-releaser action merely formalizes the Komac invocation
• Komac will — based on an existing manifest (this project got one already) — create a new manifest for an update containing these files

There is something along the lines of continue-on-error for GitHub actions, if you wanted to make sure. But I think each action stands alone. So when this action triggers it'll be run but failure should not affect other actions unless you somehow establish a dependency chain (don't know how you'd do that, btw).

In any case, I'd prefer to wait a bit until we move the main CI to GH actions (if it happens, still evaluating), we get a bit more used to them, and resume this one from there. I think that one or two releases once we move to CI with GH actions would be good to continue with this.

Perfectly fine with me. I have figured it out enough so that I can invoke Komac manually to do the same deed the above action would, so creating an updated manifest is no longer a manual process for me.

In fact, so could you. Here's the command line for a hypothetical version 2.8.1, in case you stick to the same tag and file name conventions:

$ komac update JFrog.Conan --version 2.8.1 --urls https://github.com/conan-io/conan/releases/download/2.8.1/conan-2.8.1-windows-i686-installer.exe https://github.com/conan-io/conan/releases/download/2.8.1/conan-2.8.1-windows-x86_64-installer.exe

It's trivial to adapt this for subsequent releases.

One caveat: should you ever desire to use an alternative tag naming convention where the tag name contains a leading v or other parts that aren't exactly the version, let me know and I'll try to adapt it. For WinDirStat I just finished it so that we can distinguish beta/... from release/... tags and thereby have two distinct actions for updating a separate .Beta manifest in winget-pkgs.