feat: enable update winget manifest for jdk11

[zdtsw]

- only for official LTS and CPU release
- use eclipse-temurin-bot
- version match official release on jdk-11.*

Ref: adoptium/temurin-build#3071

[vedantmgoyal9]

Suggested change

	name: Update microsoft/winget-pkgs for official release
	on:
	release:
	types: [released]
	jobs:
	publish:
	runs-on: windows-latest
	steps:
	- uses: vedantmgoyal2009/winget-releaser@latest
	with:
	identifier: EclipseAdoptium.Temurin.11.JDK
	token: ${{ secrets.WINGET_TOKEN }}
	version-regex: 'jdk-11[0-9.]+'
	installers-regex: '\.msi$'
	fork-user: eclipse-temurin-bot
	name: Update microsoft/winget-pkgs for official release
	on:
	release:
	types: [released]
	jobs:
	publish:
	runs-on: windows-latest
	steps:
	- name: Update JDK
	uses: vedantmgoyal2009/winget-releaser@latest
	with:
	identifier: EclipseAdoptium.Temurin.11.JDK
	token: ${{ secrets.WINGET_TOKEN }}
	installers-regex: 'OpenJDK11U-jdk.*.msi$'
	fork-user: eclipse-temurin-bot
	- name: Update JRE
	uses: vedantmgoyal2009/winget-releaser@latest
	with:
	identifier: EclipseAdoptium.Temurin.11.JRE
	token: ${{ secrets.WINGET_TOKEN }}
	installers-regex: 'OpenJDK11U-jre.*.msi$'
	fork-user: eclipse-temurin-bot

[zdtsw]

what is version-regex: used for in this case?
from https://github.com/vedantmgoyal2009/winget-releaser/blob/main/index.js#L99, looks like it is using the tag, but the way we format our tag is not X.Y.Z but "jdk-11*" for official and "jdk11u-*" for nightly

Another question: does it only look for files matching installers-regex: by the exact release event?

[vedantmgoyal9]

installers-regex is used to filter Windows installers from GitHub release assets based on a regular expression. If you know about wildcards, it's kind of similar but gives more control like negative matches, range, number of occurrences, etc.

version-regex is used to get to scrape numerical value + dots . from the release tag. For example: jdk-11.0.16.1+1 would be just 11.0.16.1. I'm planning to deprecate it since it's not used anywhere and try to implement something which is more customizable.

on:
 release:
   types: [released]

Also, nightlies wouldn't get published since they are marked as a prerelease and workflow will only trigger on a release.

[zdtsw]

I am considering to add edited along with released, the work flow for temurin usually involves a release with bunch of installers then upload more installers when they are ready.

[vedantmgoyal9]

I'm afraid since the action wouldn't be able to handle this case. Currently, it only generates manifests when: the previous number of installers = the new number of installers.

[vedantmgoyal9]

Can't we prioritize windows installers to get published along with the release?

[zdtsw]

That's why in the issue I mentioned maybe this update manifests step should be done in a different way, not using GH action.
We have a different release procedure for these official releases in a more secured way.

Is there a standalone tool we can use ( I guess that is the pwsh scriptsyou have in the repo?) so we can avoid:

1. bot in each binary repo
2. clone your repo
3. release vs edit by GH action

[vedantmgoyal9]

There're only 2 tools for creating manifests of WinGet:

1. WinGet Create (https://github.com/microsoft/winget-create)
2. YamlCreate.ps1 (https://github.com/microsoft/winget-pkgs/blob/master/Tools/YamlCreate.ps1)

The YamlCreate in the action repo is modified to run in non-interactive mode since the original script requires user interactivity.

Well, this is really a special case, so I might need some time to design a logic to handle individual installers or think of a different solution completely since Temurin doesn't use GitHub Actions to manage releases.

Can you assign this PR and the issue to me, and I'll update you when I have one?

[vedantmgoyal9]

@zdtsw We can change the workflow to run on a workflow_dispatch event. The workflow_dispatch workflows are workflows which are triggered manually.

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/

[zdtsw]

Sorry for late reply!

Technically, manual trigger could be one option. Since this involves extra work for the one doing each release, maybe @gdams can bring this to pcm for further discussion?

This draft is not an implementation, but only to see the possibility to use this action with the least change from temurin. Better to continue conversation in the original issue for tracking purpose.

[zdtsw]

close it as stale PR