Skip to content

Winget manifest uploader #620

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

Gijsreyn
Copy link
Contributor

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
Copy link
Member

@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
Copy link
Contributor Author

Gijsreyn commented Mar 7, 2025

@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
Copy link
Member

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

@denelon
Copy link
Collaborator

denelon commented Jun 5, 2025

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
Copy link
Member

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

@Gijsreyn
Copy link
Contributor Author

Gijsreyn commented Jun 6, 2025

@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
Copy link
Collaborator

denelon commented Jun 6, 2025

@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
Copy link

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:

Regardless, if it works it works :)

Where-Object -Property prerelease -EQ $IsPreRelease.IsPresent |
Select-Object -First 1 -Property assets).assets # ExpandProperty did not work
# Grab the download URLs for supported WinGet
$downloadUrls = $assets.Where({ $_.content_type -in @('application/zip', 'application/octet-stream') }).browser_download_url

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will break if a new zip based asset is added in the future. I suggest regex matching specific installers from the assets. One can refer to the sample workflows I shared above on how

Comment on lines +760 to +767
$url = $downloadUrls[0]
if ($url -match 'v(\d+\.\d+\.\d+)-preview\.(\d+)') {
$firstPart = $matches[1].Remove(3) # Remove the last digit
$lastPart = $matches[2] + ".0"
$version = "$firstPart.$lastPart"

$packageId = "$packageId.Preview"
}
Copy link

@mdanish-kh mdanish-kh Jun 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not grab the version from the GitHub API response itself (there's a tag_name field in the response) instead of manually parsing it from the URL?

}


& wingetcreate.exe update $packageId --version $version --urls $downloadUrls --submit --token $GitToken

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With wingetcreate, you have to be explicit with how many URLs you're passing to the update command, because otherwise the update command will fail if the number of installers in the latest manifest at winget-pkgs don't match what's passed in the update command.

What this means is - if we're including MSIX in the latest manifest at winget-pkgs, this update command must also contain the MSIX URL otherwise the update will fail. I know the MSIX installer availability is delayed for any DSC releases so that may be an area of concern. If we're not including MSIX in the latest winget-pkgs manifests, then the workflow will work as intended

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @mdanish-kh, thanks for jumping in, I appreciate it!

I have now created a winget.yml file. Do you mind having a glimpse one more time? If it's okay, I'll remove the other content from the build.ps1.

Coming back to the MSIX, it depends if it will be added to the assets. @SteveL-MSFT ?

Copy link
Member

@SteveL-MSFT SteveL-MSFT Jun 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

msixbundle will be added to the assets in the near future for 3.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants