Automate winget release

[cderv]

Process needs to be manual because wingetcreate can't be use due to limitation as we are using two scope in our manifest with one url. See https://github.com/microsoft/winget-create/issues/166 and https://github.com/microsoft/winget-create/issues/291 (cc @dpprdan)

Also, it can't be used interactively either due to this.

For now, I am doing manual update using YAMLCreate.ps1 in winget-pks repo.

We could try modifying the manifests manually to automate, but probably more work than doing update manually, until they solve the issue.

[dpprdan]

Also, it can't be used interactively either due to this.

FWIW, wingetcreate update RStudio.quarto --version 1.1.189 --interactive works fine for me. I just have to provide the URL to the installer twice after that and can post to the repo directly afterwards.

We could try modifying the manifests manually to automate, but probably more work than doing update manually, until they solve the issue.

Third option/workaround: only provide user scope in the manifest (until this is solved) and automate.

[cderv]

I just have to provide the URL to the installer twice after that and can post to the repo directly afterwards.

For some reason, I couldn't because the second time I passed the URL it tolds me that the file is locked.

Third option/workaround: only provide user scope in the manifest (until this is solved) and automate.

I thought about that, but it seems that it was added for a reason, was it ?

[dpprdan]

I thought about that, but it seems that it was added for a reason, was it ?

Yes, I thought it would be better to make the scope more explicit, see https://github.com/quarto-dev/quarto-cli/issues/1977. When it is not defined, the scope seems to be "it depends". If that is not a problem (AFAICT it isn't) just revert to non-scoped installer.

I am not sure if it is possible to submit manifests with user-scope only (in case this would be preferable from your/quarto's POV). But might be worth a shot.

For some reason, I couldn't because the second time I passed the URL it tolds me that the file is locked.

Haven't had that kind of problem and have been using this for a year now. Is the repo on a network drive or OneDrive? Or maybe a virus scanner is hitting the installer file in the winget cache at the same time (in temp dir, I assume).

[cderv]

Or maybe a virus scanner is hitting the installer file in the winget cache at the same time (in temp dir, I assume).

I'll look into that. Thanks !

[dpprdan]

it would be better to make the scope more explicit

Meaning: Make it possible to choose the scope on installation with winget.

[cderv]

We should have a closer look at latest version of https://github.com/vedantmgoyal2009/winget-releaser

see https://github.com/quarto-dev/quarto-cli/issues/3334#issue-1450154849 suggestion by @russellbanks

We need to check if it handles the two scopes with same url correctly

[russellbanks]

From https://github.com/quarto-dev/quarto-cli/issues/3334#issuecomment-1318474776:

This is covered by https://github.com/quarto-dev/quarto-release-bundles/issues/1 but had limitation at the time because of the Quarto manifest using two scope with same url

WinGet Releaser can handle this; it will just use the same URL twice.

Note also that we currently not publishing every release on Winget, mostly our last officially released stable version and not the pre-release. Otherwise there would be too much versions to publish.

WinGet Releaser would run on release (ignoring any draft or pre-release releases) (other events can be used if needed though):

on:
  release:
    types: [released]

[russellbanks]

We need to check if it handles the two scopes with same url correctly

See https://github.com/microsoft/winget-pkgs/pull/88822 as an example of WinGet Releaser handling two scopes with the same url correctly.

[cderv]

Awesome thank you @russellbanks !

[russellbanks]

Would be good to note VSCodium (with their insider channel) has done a similar thing here, where they have their releases kept in a separate repository to where their workflow is. See https://github.com/vedantmgoyal2009/winget-releaser/issues/21

This is possible with the release-repository option in WinGet Releaser.

This is their workflow, for reference.

[cderv]

This is possible with the release-repository option in WinGet Releaser

Yes this was my plan once we decide to automate the release on winget from release from CLI. Currently, it is a choice to have it manually trigger release on Winget and Chocolatey.

[cderv]

Interesting new project to look at: https://github.com/russellbanks/Komac found in https://github.com/microsoft/winget-pkgs/issues/500

[cderv]

With WinGet-Create 1.2.6.0 there should not be any issue more as these are solved

• https://github.com/microsoft/winget-create/issues/166
• https://github.com/microsoft/winget-create/issues/291

[cderv]

So I wanted to wait for this release, and see if there was new stuff. And it seems they do update automatically now 🎉

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

Or maybe it was manual but it says

This pull request is automatically generated by 🥟 Dumplings

So it seems this is handled by the community - maybe at some point we can do the work to automate like chocolatey, but it seems this is available quickly with current process. That is cool !

[eitsupi]

vedantmgoyal2009/winget-releaser uses Komac internally, and it is also used in very popular projects like bat.

https://github.com/sharkdp/bat/blob/196a4cb18f3be9b5a04e47a07bc3d3299158b0fb/.github/workflows/CICD.yml#L456-L466 https://github.com/microsoft/winget-pkgs/pull/122417