Create WinGet workflow

[russellbanks]

This pull request adds a workflow that automatically publishes Onefetch to WinGet every release, as discussed in vedantmgoyal9/vedantmgoyal9#638. Please do not merge this pull request without reading the below and making the required changes (The token part is the important bit) :)

• runs-on: windows-latest

The WinGet Releaser action can only run on Windows.

• identifier: o2sh.onefetch

This is the identifier for Onefetch on Winget. It will use this to find Onefetch's current package on WinGet.

• installers-regex: '\.exe$'

This will make all .exe files in the assets of the latest Onefetch release to be included in the pull request.

• delete-previous-version: 'true'

This is optional, and you are welcome to change this to false (or omit it; the default is false). This will essentially overwrite the previous version on WinGet packages, so that only this new version is stored on WinGet. Again, entirely optional.

• token: ${{ secrets.WINGET_TOKEN }}

This is the bit that will require action from yourself. This is a GitHub token with which the action will authenticate with GitHub and create a pull request on the winget-pkgs repository.

To do this, you will need to:

1. Create a Personal Access Token (PAT) with public_repo scope on your GitHub account.
   

2. Create a repository secret containing the token. Super important: call this token: WINGET_TOKEN.
   See using encrypted secrets in a workflow for more details.

Finally, make sure you have a fork of winget-pkgs on your GitHub account. Please do not delete the fork after a pull request has been merged as the action will use that fork for making a branch and merging it with the upstream winget-pkgs repository on every Onefetch release.

The above is made on the assumption that the account that the token is from (and the fork is present) is @o2sh. If you would like this to be done by another account, the token would have to be from the different user and an extra line would have to be added: fork-user: # Username of other user (this defaults to the repository owner, which is why it doesn't have to be added)

If you would like to read about this action further, the documentation is here and the source code is here.

If you are interested in what a pull request made by this action looks like, here is one from my account: #61982 on winget-pkgs.

If you are concerned about the generated executable (#668) not getting included in the action when it checks the assets, it actually has a retry logic that will retry for up to an hour, checking every ten minutes for the required asset in the created release. If it's still not in the assets at that point, it will fail and you can re-run it at a later date when it is. Merged with CD workflow so this will always run after the assets have been built.

[spenserblack]

🤔 It would probably be ideal if this could be combined with the CD workflow. Then you can set that this job needs deploy, which seems necessary as it looks like this action relies on assets already being published. Probably better than just retrying every 10 minutes up to the 5th try. It's also ideal for this job to simply not run if the deploy job fails.

---

You can ignore my note on uses: vedantmgoyal20009/.... I'm not requesting a change there, just making a note.

[spenserblack]

The WinGet Releaser action can only run on Windows.

It could be made into a docker action to allow it to run on ubuntu/macos, but then it wouldn't be able to run on windows 😆 🙃
(though the docker image itself could run Windows AFAIK)

[russellbanks]

🤔 It would probably be ideal if this could be combined with the CD workflow. Then you can set that this job needs deploy, which seems necessary as it looks like this action relies on assets already being published. Probably better than just retrying every 10 minutes up to the 5th try. It's also ideal for this job to simply not run if the deploy job fails.

I actually made an issue about a similar issue I had: #442, asking for it to be allowed to be ran on other workflow events. However, they said they ran into an issue with this:

@russellbanks I was testing the action with the workflow_run event, but the problem is the action won't be able to get the release information automatically as it does now and my main concern while creating the action was only that a user would not have to supply everything as an input for the action.

[spenserblack]

Huh, just took a quick look, but it seems like this could honestly be automated with winget-create, which also supports submitting PRs.

[spenserblack]

I actually made an issue about a similar issue I had: #442, asking for it to be allowed to be ran on other workflow events.

With the needs: option a job can be delayed until another job is finished, and still be triggered with on: release by being part of the same overall workflow.

Edit: See this as an example. Of course, different workflow (on tag pushed instead of on release), but I hope it's a decent example of delaying one job until the other finishes.

[russellbanks]

With the needs: option a job can be delayed until another job is finished, and still be triggered with on: release by being part of the same overall workflow.

I didn't consider this. Thank you :)

Huh, just took a quick look, but it seems like this could honestly be automated with winget-create, which also supports submitting PRs.

I imagine this reason that this hasn't be done already is because wingetcreate isn't as verbose in its options as the script is maybe? For example, being able to delete a previous version.

Meanwhile, I could tag always vedantmgoyal2009 for visibility on this? I imagine they'd be happy to help

[spenserblack]

I could tag always vedantmgoyal2009 for visibility on this?

No problem, I'm not opposed 🙂
@vedantmgoyal2009

[vedantmgoyal9]

Sorry for the late reply.

onefetch/.github/workflows/cd.yml

Lines 1 to 4 in ac338c8

	name: CD
	on:
	release:
	types: [published]

You'll have to change the event type to released otherwise pull requests will be created for draft and pre-releases too.

[spenserblack]

AFAIK there wouldn't be any problem changing the action trigger type to released, but we should get confirmation from @o2sh since they've been creating the releases so far, and see if they care about the timing. Although wouldn't all needed event attributes (assets, tag, publish date, etc.) be available with the published release type, too?

[o2sh]

TBH, I've just discovered - thanks to @vedantmgoyal2009 comment - the distinction between the published and the released trigger type 😅. I agree with @vedantmgoyal2009, the CD pipeline should only be triggered when a release is published --> 0eb642a

[o2sh]

@russellbanks I created the token:

[russellbanks]

@russellbanks I created the token

Brill, just make sure you've added that token to this repository :)

[o2sh]

done:

I'll let @spenserblack finish his review and approve the PR, did you settle on this?

[spenserblack]

Thanks for the changes, @o2sh! With this, we should be able to add this as a job to the CD workflow, so that it only triggers after a release is created. Something vaguely like this

jobs:
  deploy:
    # ...
  winget-pkg-release:
    needs: [ deploy ]
    runs-on: windows-latest
    # etc.

---

BTW, a max-retries input winget-pkgs-automation/releaser-action might be cool. In our specific case, as long as we have guaranteed that deploy has completed before this action, then it would probably be best to fail as soon as possibly instead of retrying. This is because, if there are no assets available after deploy is finished, something has gone really wrong and another try wouldn't really help.

[spenserblack]

Oh, also I just thought about this:
@vedantmgoyal2009 currently your action requires a special token instead of the built-in GITHUB_TOKEN because the action uses another repository to generate a PR. But you could actually clone winget-pkgs into the same repo and generate a PR from there, thus allowing you to use GITHUB_TOKEN. Here's an example of what that would look like:

git remote add winget https://github.com/microsoft/winget-pkgs.git
git fetch winget
git branch winget-pkg winget/master
git checkout winget-pkg
# make changes
git push -u origin winget-pkg
# make PR from <repo>:winget-pkg to microsoft/winget-pkgs:master

It's not blocking this PR, but just something to think about as a way to make your action more friendly to users 🙂

---

Edit: nevermind, I forgot that making a PR to another repo requires elevated permissions 😞

[vedantmgoyal9]

@russellbanks I think we can now go with #673 (comment).

jobs:
  deploy:
    # ...
  winget-pkg-release:
    needs: [ deploy ]
    runs-on: windows-latest
    # etc.

[russellbanks]

I've made those changes

[spenserblack]

LGTM!