Publish to Windows Package Managar (WinGet)

[vedantmgoyal9]

With every new release of Temurin JDKs/JREs, use a GitHub workflow to update manifests at https://github.com/microsoft/winget-pkgs repository.

The workflow will be added to every release repository:

• Temurin8: https://github.com/adoptium/temurin8-binaries
• Temurin11: https://github.com/adoptium/temurin11-binaries
• Temurin16: https://github.com/adoptium/temurin16-binaries
• Temurin17: https://github.com/adoptium/temurin17-binaries
• Temurin18: https://github.com/adoptium/temurin18-binaries
• Temurin19 (beta): https://github.com/adoptium/temurin19-binaries
• Temurin20 (beta): https://github.com/adoptium/temurin20-binaries

Prerequisites:

1. https://github.com/microsoft/winget-pkgs will be required to be cloned under the organization or a personal account of a maintainer/bot like @eclipse-temurin-bot.
2. A GitHub Personal Access Token (PAT) will be needed to create pull requests to update manifests at https://github.com/microsoft/winget-pkgs. The token needs to be added as a repository secret to every repo. I know it's a bit hectic but it needs to be done only one time ;) Permissions required: public_repo and workflow.

Existing projects which use the action: https://github.com/search?q=vedantmgoyal2009%2Fwinget-releaser+path%3A.github%2Fworkflows%2F+language%3AYAML&type=Code&s=indexed&o=desc

P.S. I can create PRs for every repository.

Edit: Replaced extraneous reference of temurin18 with temurin19 (beta).

[zdtsw]

I made a draft on jdk11, if this is what you want? @vedantmgoyal2009
I am thinking only for the official releases and skip nightly builds, which only enable jdk8/11/17/19(tobe)

[vedantmgoyal9]

I've updated to add JRE too.

[zdtsw]

ping @gdams and @karianna for this issue

[sxa]

Any thoughts @gdams @karianna - are MSFT willing to support this?

[gdams]

This seems like the logical thing to do here. The manifests are currently being manually updated although it's not something that I've been doing myself.

I would say let's role this out for the 8-18 repos and see how stable it is

[vedantmgoyal9]

@gdams The internal CI which publishes GitHub releases can trigger the WinGet workflow programmatically after all 4 binaries have been published (JDK/JRE x64/x86) and pass the GitHub release tag with it (see https://docs.github.com/en/rest/actions/workflows#create-a-workflow-dispatch-event to how to do it).

References:
2. Docs about workflow_dispatch event: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/
3. Updates to workflow_dispatch: https://github.blog/changelog/2022-06-10-github-actions-inputs-unified-across-manual-and-reusable-workflows/

[vedantmgoyal9]

@gdams @karianna From some discussion in adoptium/temurin11-binaries#11, I came to know that not all binaries are published along with the release. So, we might want to trigger the WinGet workflow from the internal CI which uploads Windows MSI binaries to GitHub.

Use GitHub CLI to create workflow_dispatch event: https://cli.github.com/manual/gh_workflow_run (we need to pass release tag to workflow, which we can do via JSON standard input, as mentioned in the docs)

Main Documentation: https://docs.github.com/en/rest/actions/workflows#create-a-workflow-dispatch-event

References:

1. Docs about workflow_dispatch event: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/
2. Updates to workflow_dispatch: https://github.blog/changelog/2022-06-10-github-actions-inputs-unified-across-manual-and-reusable-workflows/

[friesoft]

Any progress on this? Using winget the latest versions are currently not available and therefore contain open CVEs (CVSS 7,5 iirc).

[karianna]

@gdams Let's discuss when we next meet up - not sure where this is these days.

[gdams]

I think this certainly makes sense to me. We'd have to ensure that the workflow supports multiarch packages (x64 and ARM64)