Winget manifest uploader

[Gijsreyn]

PR Summary

This PR adds a function to the build script to upload the assets related to Windows machines to the winget-pkg repository.

PR Context

The function grabs the relevant content types for Windows machines. One switch is introduced to submit the manifest, including a parameter to add the GitHub token.

The only two things remaining is to have it added to the workflow after a release is created and not rebuild the enter project. I was thinking something of this:

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

jobs:
  publish:
    runs-on: <agentName>
    env:
      WINGETCREATE_TOKEN: ${{ secrets.WINGETCREATE_TOKEN }}
    steps:
    - name: Create manifest and submit PR to winget-pkgs
      run: |
        ./build.ps1 -SubmitWinGetManifest -GitToken $env:WINGETCREATE_TOKEN

[!NOTE] The OTBS setting formatted some code in the build.ps1 file.

[SteveL-MSFT]

@Gijsreyn thanks for this, but I think the team needs to discuss if we want to separately publish to winget given that winget can install from the Store. Just not sure if we want to support this different way of installing.

[Gijsreyn]

@SteveL-MSFT Got it Steve. Personally with all the issues related to the store, having the ability to choose the installerType and the source, just throws in a better installation experience. When a user installs it from the winget source, the user in itself can choose for .zip or .msixbundle.

[SteveL-MSFT]

@denelon do you think there's value/reason to publish to WinGet repo in addition to the Store?

[denelon]

I think there are folks who would prefer WinGet as it can support making earlier versions available as opposed to the store just offering the latest version. If you add the packaged version here in addition to the other methods, users can choose which type they prefer, but WinGet would still default to the MSIX package for a new installation unless the user specifies via arguments or settings.

[SteveL-MSFT]

@Gijsreyn can you resolve the merge conflict and I'll review and get this merged. Thanks!

[Gijsreyn]

@SteveL-MSFT Merge conflicts resolved. I had to rewrite a little part, because the PR was quite outdated. There's a new switch introduced that switches between Microsoft.DSC or Microsoft.DSC.Preview based on -PreRelease. Do note: the current WinGet repository requires 3 URLs. The .msixbundle is missing from the assets. See earlier talks at #638

[denelon]

@Gijsreyn, I'd also suggest taking a look at how PowerToys publishes to WinGet using wingetcreate. @mdanish-kh has done a bunch of these at GitHub.

[mdanish-kh]

While this script approach can definitely work, it involves a lot more "plumbing" than what could be simplified into a relatively straightforward post-publish GitHub Action. Examples:

• microsoft/terminal <--- Handles both preview and stable releases
• microsoft/edit
• microsoft/PowerToys

Regardless, if it works it works :)

[SteveL-MSFT]

I don't think we've addressed the underlying issue for us to be able to automate this properly, which is we don't know what release assets are gonna be available when the release is created / published. Is it gonna be both ZIP & MSIX?

Would it make sense to only support MSIX for now? Or do you think users would prefer ZIP since they can just install MSIX via Store (except for Server)?

[mdanish-kh]

Would it make sense to only support MSIX for now? Or do you think users would prefer ZIP since they can just install MSIX via Store (except for Server)?

I'm not particularly aware of the user preferences, since I haven't seen an issue at winget-pkgs requesting a particular installer for DSC. Personally I would prefer the packaged MSIX version to be available via WinGet for convenience. Users can install it once & future updates can be handled automatically via the MSFT Store (or manually by WinGet as well). But I don't see why we would want to support "only" MSIX since ZIP is always available in the release assets. No reason to exclude that installation medium when it's always available in the release assets. I feel the question should be should we support MSIX or no, and to that I feel we should. WinGet will always default to MSIX installation if user doesn't specify, but having all installation mediums available gives users more choices.

[SteveL-MSFT]

Would it make sense to only support MSIX for now? Or do you think users would prefer ZIP since they can just install MSIX via Store (except for Server)?

I'm not particularly aware of the user preferences, since I haven't seen an issue at winget-pkgs requesting a particular installer for DSC. Personally I would prefer the packaged MSIX version to be available via WinGet for convenience. Users can install it once & future updates can be handled automatically via the MSFT Store (or manually by WinGet as well). But I don't see why we would want to support "only" MSIX since ZIP is always available in the release assets. No reason to exclude that installation medium when it's always available in the release assets. I feel the question should be should we support MSIX or no, and to that I feel we should. WinGet will always default to MSIX installation if user doesn't specify, but having all installation mediums available gives users more choices.

That makes sense. In that case, we should support both MSIX and ZIP

[Gijsreyn]

@mdanish-kh can you do one more review of this? Thanks!

@Gijsreyn there's an empty build.ps1 file?

Either I don't have my glasses on, or there is a little bug in GitHub @SteveL-MSFT, as you can see it's correctly in my branch: https://github.com/Gijsreyn/operation-methods/blob/winget-manifest-uploader/build.ps1

[mdanish-kh]

Either I don't have my glasses on, or there is a little bug in GitHub @SteveL-MSFT, as you can see it's correctly in my branch: Gijsreyn/operation-methods@winget-manifest-uploader/build.ps1

@Gijsreyn You've updated the file permissions somehow it seems & that's why it's being shown in the GitHub diffs

To reset the changes to the file, you can run git checkout main -- .\build.ps1 in your branch and then commit & push the changes

[Gijsreyn]

Either I don't have my glasses on, or there is a little bug in GitHub @SteveL-MSFT, as you can see it's correctly in my branch: Gijsreyn/operation-methods@winget-manifest-uploader/build.ps1

@Gijsreyn You've updated the file permissions somehow it seems & that's why it's being shown in the GitHub diffs

To reset the changes to the file, you can run `git checkout main -- .\build.ps1` in your branch and then commit & push the changes

And you just spared me a couple of hours debugging. Thanks for both the comments. Should be resolved!