Create github action to submit a PR when a release is created

[JohnMcPMS]

Description of the new feature/enhancement

A GitHub Action placed in the marketplace that would submit a PR when a release is created could make keeping open source projects up to date in this repo very easy.

Proposed technical implementation details (optional)

I have no idea if an action actually supports that 😉 It would need to be able to:

1. Get a template manifest from the repo
2. Download artifacts from the release
3. Calculate the hash
4. Update the template
5. Submit a PR using some account token

[SoftCreatR]

That's what we do internally already for a selected set of applications:

• Atom
• Bitwarden
• Brave
• CCleaner
• Chrome
• Chrome Beta
• Defraggler
• Discord
• Discord PTB
• Discord Canary
• Docker
• Docker Edge
• Edge
• Edge Beta
• Edge Dev
• EasyPHP Devserver
• Firefox
• Firefox Developer
• Firefox ESR
• Irfan View
• Microsoft Powertoys
• OBS Studio
• osu!
• Pale Moon
• Recuva
• Speccy
• Start10
• Telegram
• Windows Terminal
• Windows Terminal Preview
• WinSCP
• Zygor Guides Viewer

More are planned, however the ones listed above are already fully automated (even the PR creation).

[JamieMagee]

@SoftCreatR Can you share any more about your current work in this area?

[SoftCreatR]

@SoftCreatR Can you share any more about your current work in this area?

@JamieMagee Well, I'm simply obtaining the current version numbers from the supported applications, compare them with the existing ones and if needed, download the executable, calculate it's hash and create a PR, using the official GitHub API.

Every covered application has a Manifest Template that is used upon release creation to guarantee consistency.

Before doing a first release, a manual validation will be performed on a HyperV machine. Everything else is done on a small Linux machine. However, I've planned to move to a Windows server, so all the validation stuff can be automated, too.

At the end, all I have to do to support an application is to provide the logic to get the current version number and a download link. Everything else is generic. But as a result, I can provide updates in realtime (within 5 minutes after official release) without any additional work 🥰

---

EDIT: There was a small update at our end that fixes #91 for now by providing a simple proxy. This allows us to provide more packages like HeidiSQL (see #1610), MEGASync (see #1620) and others, where the validation is currently failing due to the range request bug.

However, the proxy isn't meant to be used by everyone, so a secret (per download url) is required in order to download a file using the proxy.

An example url would be: https://www.winget.it/dl/968981d487aca3400e56f0a09cd3b2adfffaa99916cca1578470894167337417/https%3A%2F%2Fmega.nz%2FMEGAsyncSetup.exe?v=4.3.1.0

In this example, a version parameter has been appended. This allows us to save/cache the executable MEGAsyncSetup.exe as MEGAsyncSetup_4.3.1.0.exe, so we don't have to request the original file on every request/installation and as a bonus, we have some kind of versioning for those executables. I know, that this won't work for every application (e.g. Google Chrome), but that's better than nothing, I guess ;)

This solution is a temporary one and lasts, until the bug has been fixed.

[JamieMagee]

@SoftCreatR Thanks for the explanation, but I think I'm still missing something.

Where are you getting this version information from? Is it a manual process or are you using something like Repology? Additionally, does winget.it just proxy requests to the actual download URL due to the bug about range requests?

[SoftCreatR]

Where are you getting this version information from? Is it a manual process or are you using something like Repology?

We are not using any external/additional service to obtain version informations. I was considering to use one, but then decided to do this "manually". Most times (when there's no public information or a Git repository) we analyze the application's traffic and try to find, how they know about new versions. If that's not possible, we'll create alternative ways.

Additionally, does winget.it just proxy requests to the actual download URL due to the bug about range requests?

Yes and no. The server itself automatically builds the manifest files, if there's an update of an application and finally creates a PR for the generated manifest files. However, that should not the only reason to pay for the server, so i've just created a website at https://www.winget.it, which also acts as "web directory" for winget manifests. I had some fun creating a website that looks and behaves like the Windows Terminal (or the classic PowerShell that can be selected from the settings that are hidden behind the ? icon at the top).

Last but not least, there's the proxy thing as mentioned above. Like I said, it's a temporary solution around the range request bug. As of now, it downloads the requested binary, stores it on the server and delivers it from here. The rest is just a matter of proper webserver configuration.

[SoftCreatR]

Just a quick heads up: We've just set up a list that shows, which applications are covered by our automation (Version check, Manifest and PR creation), : https://www.winget.it/auto

It's not finished yet, but it already contains the most important informations.

[dfreilich]

@SoftCreatR The auto link seems to be broken, any chance you can give the updated list? And how can we get our application covered by your automation?

[SoftCreatR]

I'm no longer active here, that's why I've abandoned the whole website, sorry.

[Vishesh-Gupta]

@JohnMcPMS I am the author of the Automatic Winget pkg update issue on the cli/cli for the new gh cli as mentioned by @alannt777. I was wondering if there has been any update on someone working on this since I was planning to work on this to help with the cli update and was planning on working on it. If there is someone working on this please let me know, if not let me know if there are any requirements decided by Microsoft since I was planning on working on it.

[JohnMcPMS]

@Vishesh-Gupta , I don't believe that we have anyone actively working on it, although I believe that the VS Code team may have created one for their own purposes.

[denelon]

We've released wingetcretae and have examples of using GitHub actions to publish manifests as PRs.

[vedantmgoyal9]

I have created https://github.com/vedantmgoyal2009/winget-pkgs-automation for auto-updating manifests for packages that are delivered through GitHub releases. Currently, there are only a few packages but Levvie has provided me with a long list of packages (vedantmgoyal9/vedantmgoyal9#1 (comment)) which I will be adding soon to the automation.

[jedieaston]

Related to having packaged actions: microsoft/winget-create#160

[jedieaston]

Also, not that it helps, but here's an example of a GitLab CI job that automatically posts PRs (via running the wingetcreate.exe file in a Windows Docker container): https://github.com/DataDog/datadog-agent/blob/main/.gitlab/deploy_7/winget.yml.

[denelon]

PowerToys has automated their manifest publishing with the Windows Package Manager Manifest Creator.

[Trenly]

@denelon - I believe this duplicates #1184, but would like your opinion before I simply mark as duplicate

[vedantmgoyal9]

@Trenly this one specifically mentions about a GitHub Actions, whereas, the other one talks about automation in winget-pkgs itself.

[denelon]

I think I agree with @vedantmgoyal2009 here. I think the other one is also related to:

• Auto generate manifests for newer versions #500

I've been discussing ways we could fully incorporate @vedantmgoyal's other project in winget-pkgs directly so we can easily reason about what is automated, and look at further enhancements for other mechanisms of detecting upgrades and updating manifests. Sadly, it's a prioritization challenge, and a concern about honoring publisher wishes.

I still believe it's in a publisher's best interest to submit their own manifests which is why a GitHub action looks like one of the good mechanisms to do this leveraging wingetcreate. When that isn't an option some kind of responsible polling mechanism seems to be the second-best option.

[Cyberboss]

I'm currently just rolling my own implementation:

https://github.com/tgstation/tgstation-server/blob/de5493f8fd0bf6b8a82fcf61a4105621cbbbfcaa/.github/workflows/ci-pipeline.yml#L973-L1086

https://github.com/tgstation/tgstation-server/blob/de5493f8fd0bf6b8a82fcf61a4105621cbbbfcaa/.github/workflows/ci-pipeline.yml#L1439-L1480

[denelon]

Here are a couple of other examples using wingetcreate:

• PowerToys
• Oh-My-Posh