add Winget Releaser workflow

[sitiom]

This action automatically generates manifests for Winget Community Repository (microsoft/winget-pkgs) and submits them.

ugrep has been added to Winget (https://github.com/microsoft/winget-pkgs/pull/122139), and this workflow will be used to update it.

Before merging this:

1. Add a classic PAT with public_repo scope as a repository secret named WINGET_TOKEN.

2. Fork https://github.com/microsoft/winget-pkgs under @Genivia. The action will use that fork for making a branch and creating a PR with the upstream winget-pkgs repository on every release.
3. Install Pull on the winget-pkgs fork to ensure that it is constantly updated.

If you want to see an example of a PR created using this action, see microsoft/winget-pkgs/pulls (Pull request has been created with WinGet Releaser).

[genivia-inc]

Thank you for contributing to the ugrep project! I was out of town. I will will look at this asap. Thanks for the detailed steps.

[genivia-inc]

OK. I've forked https://github.com/Genivia/winget-pkgs to organization @Genivia, installed the Pull app, and added WINGET_TOKEN to my PAT @genivia-inc as instructed.

[genivia-inc]

I've followed the steps to the point with the classic PAT WINGET_TOKEN for @genivia-inc, but I see this workflow error appear after v4.3.1 was released a few minutes ago:

https://github.com/Genivia/ugrep/actions/runs/6563930847/job/17829245912

This does not look familiar to me. I suppose an authentication error happened. Perhaps the token should be associated with @Genivia instead of @genivia-inc? But the developer settings are different for @Genivia and do not align with the instructions.

The personal token I've generated shows:

[sitiom]

1. Add a classic PAT with public_repo scope as a repository secret named WINGET_TOKEN.

You should add the PAT as a repository secret in this repo so that the workflow can use it:

I have manually created a PR for now:

• https://github.com/microsoft/winget-pkgs/pull/123100

[genivia-inc]

That is definitely more clear to me now. I've added the generated PAT as a secret to the ugrep repository. It wasn't clear where to look in the repo settings to do just that.

[sitiom]

Now it works 🎉

• https://github.com/microsoft/winget-pkgs/pull/124671

[genivia-inc]

Thank you for helping out with the silly mistake I had made earlier. Glad it works now!

[genivia-inc]

The winget release is taking some time to get reviewed, which is to be expected when reviews are needed. But I plan to release update 4.3.3 sometime this week with new additions and a fix that are ready. Will the 4.3.3 release interfere with the pending winget 4.3.2 release?

[sitiom]

Will the 4.3.3 release interfere with the pending winget 4.3.2 release?

No, it won't. It will just simply create a new PR with a new version.

[genivia-inc]

Thanks!

[genivia-inc]

When installing ugrep with winget, we only get the ugrep command installed. I would strongly suggest to also install the ug command by renaming ugrep.exe to ug.exe. This renaming forces ug.exe to use options --pretty and --sort which are essential for interactive CLI use. This internally works in ugrep by checking for its command name and when ug or ug.exe it enables options --pretty and --sort. Or an alias ug to execute ugrep should also work to install instead of a copy of ugrep.exe, as long as --pretty and --sort are both passed to the command. The ug command also loads the .ugrep configuration file when present. This is quite useful.

Please consider this recommendation. Thanks!

[sitiom]

Unfortunately, Winget does not support multiple aliases from a single executable yet: https://github.com/microsoft/winget-cli/issues/2884. However, a workaround exists if the binary is wrapped under a .zip file (https://github.com/microsoft/winget-cli/issues/2884#issuecomment-1406137630).

If you can release the zipped builds, I can add the ug alias. Thanks!

[genivia-inc]

Thank you for your suggestion. Are you saying that bundling ugrep.exe together with ug.exe in one zip suffices? Or should these be separate zip? Then add this/those ugrep.zip as a release artifact? I need a bit more info to understand.

[sitiom]

Are you saying that bundling ugrep.exe together with ug.exe in one zip suffices?

Yes, this would be the best way to do it.

[genivia-inc]

One more question: will this create an alias for ug pointing to ugrep? If an alias is set with:

New-Alias -Name ug -Value ugrep

then this will not work. It will not work, because the executing program is still ugrep. The program itself does not know it has been aliased as ug. A copy of ugrep.exe to ug.exe works. Also symlinks work:

New-Item -ItemType SymbolicLink -Path "ug.exe" -Target "ugrep.exe"

[sitiom]

You said about bundling two copies of the same executable (ugrep.exe and ug.exe), so that would work. You can also just bundle ugrep.exe inside a zip file and let Winget symlink the alias. However, symlinks only work in Windows under either admin permissions or when developer mode is on. So, it might be best to bundle two executables to cover all cases.

[genivia-inc]

Got it. Instead of ugrep.exe a ug.exe.zip is now added as a release artifact. This contains ug.exe and ugrep.exe. I named the zip with exe to make sure people understand the purpose and don't get confused with the repo zip file. Is this OK?

[sitiom]

Got it. Instead of ugrep.exe a ug.exe.zip is now added as a release artifact. This contains ug.exe and ugrep.exe. I named the zip with exe to make sure people understand the purpose and don't get confused with the repo zip file. Is this OK?

Ideally, the proper naming of the file should be something like ugrep-windows-x64.zip as that's what other projects usually do 😅 (you can see the platform and architecture of the binary at a glance).

[genivia-inc]

OK. Will do.

[genivia-inc]

The v4.4.0 release is updated with the zip file. I've largely automated the file creations and zipping on my side, so I can't forget this extra step.

[sitiom]

Thanks. I have created PRs for Winget and Scoop to update the URLs:

• https://github.com/microsoft/winget-pkgs/pull/131108
• https://github.com/ScoopInstaller/Main/pull/5364

[sitiom]

@genivia-inc ugrep-windows-x64.zip downloads to ug.exe.zip. Can you please reupload the actual renamed file instead of renaming it directly on GitHub itself?

[genivia-inc]

OK. I didn't know that would be a problem. Sorry about that. There is a minor update coming anyway, which will be tagged v4.4.1. So please stay tuned. The minor update is to fix #335 for distribution packagers when dealing with bash, fish and zsh autocompletion installation. On that note, I wonder if PowerShell autocompletion would be nice for ugrep. I will look into that for a future update.

[genivia-inc]

I've released v4.4.1.

I keep seeing the "Manifest Validation Error" on https://github.com/microsoft/winget-pkgs/pull/131159#event-11291342716 so do I need to include a multi-file manifest as described here https://github.com/microsoft/winget-pkgs/tree/master/doc/manifest/schema/1.4.0

It is not clear where to add a manifest. I assume this needs to be added to the ugrep-windows-x64.zip file? I could automate that.

[sitiom]

Since my 4.4.0 PR hasn't been merged yet (https://github.com/microsoft/winget-pkgs/pull/131108), Komac (the underlying tool Winget Releaser uses) hasn't picked up the updated changes for the manifest yet.

I will go ahead and close the PR in favor of the latest one. I have created a suggestion in your PR to fix the problem; please take a look: https://github.com/microsoft/winget-pkgs/pull/131159#discussion_r1431605869.

[genivia-inc]

I saw your PR suggestion and already committed it, which appears to have resolved the Manifest Validation Error.

[genivia-inc]

@sitiom Just FYI there was a Winget 4.4.0 PR error message https://github.com/microsoft/winget-pkgs/pull/131029#issuecomment-1866982150 after 4.4.1 was released. I will close that PR and delete its branch.

[genivia-inc]

Release v4.5.1 got stuck in the pipeline somehow:

Error: Command failed: & /usr/lib/jvm/temurin-17-jdk-amd64/bin/java -jar komac.jar update --id 'Genivia.ugrep' --version 4.5.1 --urls 'https://github.com/Genivia/ugrep/releases/download/v4.5.1/ugrep-windows-x64.zip' --submit

See https://github.com/Genivia/ugrep/actions/runs/7432086076/job/20223497334

I don't see anything out of the ordinary that could have caused this on my side. Releasing 4.5.0 the day before went OK.

[sitiom]

The error above shows:

  Failed to create branch from upstream default branch
  node:internal/errors:866
    const err = new Error(message);

Did the token you have provided expire somehow?

[genivia-inc]

It's a mystery to me. The token never expires:

The WINGET_TOKEN is still part of the repo secrets:

When I look at its value (via edit, but then go back to keep it unchanged), then I don't see a value for the token at all. It may or may not be there? Is this normal that no value shows up when editing the value? Everything worked fine a few days ago.

Have you ever seen this before? Should I try to regenerate it and assign the value to the WINGET_TOKEN as a repo secret?

Sorry to bother you with this. Thanks in advance for your help.

[sitiom]

No worries 🙂

When I look at its value (via edit, but then go back to keep it unchanged), then I don't see a value for the token at all. It may or may not be there? Is this normal that no value shows up when editing the value? Everything worked fine a few days ago.

Yeah, that's normal for a secret.

Have you ever seen this before? Should I try to regenerate it and assign the value to the WINGET_TOKEN as a repo secret?

Not sure what the problem is, but maybe regenerate and update the WINGET_TOKEN just to be sure 🤔.

[genivia-inc]

No luck. I've generated a new WINGET_TOKEN PAT (classic) under my account dev settings and updated the repo's WINGET_TOKEN value. Re-running the jobs still fails with the same error. Perhaps that could be because the workflow has a stale token, although I would assume re-running all jobs would use the updated info.

[sitiom]

Ping @vedantmgoyal2009

[genivia-inc]

Also the next update 4.5.2 failed: https://github.com/Genivia/ugrep/actions/runs/7475947513/job/20345225591

[vedantmgoyal9]

Please re-run the workflow after updating https://github.com/Genivia/winget-pkgs manually. The last update made by bot was 5 days ago (https://github.com/Genivia/winget-pkgs/pulls?q=is%3Apr+is%3Aclosed).

[genivia-inc]

@vedantmgoyal2009 thanks! A manual sync of the fork worked. I'll enable auto-sync, if I can find that setting. It's not an option of the "sync fork" button. It would be really nice if GitHub had an "auto-sync" option with the "sync fork" button.

[genivia-inc]

@sitiom The ugrep v6.5 winget workflow failed today with a zip decompression error. However, when I checked the release artifact ugrep-windows-x64.zip it is absolutely fine.

Perhaps the zip file could not be retrieved by the workflow action? Do you know what this means?

Could this be related to PR #420?

FYI manual sync as explained in this GitHub doc is no longer selectable in a forked repo, i.e. does not show in my winget-pkgs to keep winget-pkgs in sync.

[sitiom]

@sitiom The ugrep v6.5 winget workflow failed today with a zip decompression error. However, when I checked the release artifact ugrep-windows-x64.zip it is absolutely fine. Perhaps the zip file could not be retrieved by the workflow action? Do you know what this means?

Perhaps it's a one-off error (possibly got corrupted on download?); have you tried running it again? I tried running the exact same command, and it worked:

• https://github.com/microsoft/winget-pkgs/pull/168930

Let's see if the problem persists in the next release.

FYI manual sync as explained in this GitHub doc is no longer selectable in a forked repo, i.e. does not show in my winget-pkgs to keep winget-pkgs in sync.

Perhaps it's because there's an existing PR against the master branch:

• https://github.com/Genivia/winget-pkgs/pull/245

[genivia-inc]

Thank you for your reply. Sorry this happened on a Friday + weekend. I was confident the release has no issues after testing etc. So I went ahead.

Reran the job and it passed.

Strange to see a zip download and unzip fail, but it's perhaps the best explanation. Friday releases are cursed...