WingetCreate update command failing during Pull Request submission due to issue with permission

[TechWatching]

Brief description of your issue

I use WingetCreate update command in a GitHub Actions workflow that aims at generating the manifest and submitting the PR to the winget packages repository. The manifest generation works fine but the Pull Request submission fails with a permission error although the PAT was generated with the public_repo permission: Octokit.ForbiddenException: Must have admin rights to Repository.

Steps to reproduce

• Create a PAT with the public_repo permission, set it in the secrets of a GitHub repository (Nushell in my case with a secret named NUSHELL_PAT)
• Use that secret with the wingetcreate update command in a github actions workflow
  My workflow is the following (triggered by a release):

name: Submit Nushell package to Windows Package Manager Community Repository 

on:
  release:
    types: [published]

jobs:

  winget:
    name: Publish winget package
    runs-on: windows-latest
    steps:
      - name: Submit package to Windows Package Manager Community Repository
        run: |
          iwr https://aka.ms/wingetcreate/latest -OutFile wingetcreate.exe
          $github = Get-Content '${{ github.event_path }}' | ConvertFrom-Json
          $installerUrl = $github.release.assets | Where-Object -Property name -match 'windows.msi' | Select -ExpandProperty browser_download_url -First 1
          .\wingetcreate.exe update Nushell.Nushell -s -v $github.release.tag_name -u $installerUrl -t ${{ secrets.NUSHELL_PAT }}

Expected behavior

Update command should work and the PR should be created like in the following screenshot

(the same github action script worked on my fork of the main repository)

Actual behavior

Pull Request submission is failing with the following error:

This raises the following questions:

• Is the public_repo permission not enough to make wingetcreate work ? => It would be weird as I succeeded making it work with this permission in another fork.
• Should the creator of the PAT be the owner of the original repo (Nushell in my case) ? I don't see why as the submission is mainly about forking winget-pkgs and submitting a PR if I understood correctly.

It seems to me that what is failing is the push of the autogenerated branch to the winget-pkgs fork. But I don't know what is the problem exactly.

Environment

Latest version of winget create is used (latest version is downloaded each time the workflow is run): currently 0.2.0.29

[ryfu-msft]

Hey @TechWatching,

Can you create a PAT with full repo access and try again? It looks as if the PAT didn't have the right permissions to execute propertly. Let us know if that resolves the issue. If not, we'll need to dive further into your logs.

I don't think its related to you not being the owner of the main Nushell repo as this should only be involving you and winget-pkgs.

[TechWatching]

Well what is weird is that with my PAT (with public_repo permission only) it works fine, I was able to create a PR from a github action workflow.

But when the PAT generated by the nushell owner with the same permission failed : https://github.com/nushell/nushell/runs/3250328625?check_suite_focus=true

I don't know what could explain this difference.

[ryfu-msft]

Hey @TechWatching,

I apologize for the delay, we are currently working on resolving this issue. From your logs, its showing an Octokit.Forbidden exception when it tries to delete a repository, which means the PAT token doesn't have the permission to delete a repo.

However, I believe this exception is misleading and not truly the main issue. We only delete a repo if something goes wrong when submitting a PR as to not clutter a user's repo. This means that something else is going on that is causing the submission to fail. I believe that if you gave you token permission to delete a repo, it might produce a different error exception. If you could try that and let us know what the result is, that might help us uncover the root issue.

[TechWatching]

I see, you are probably right.

But unfortunately I am not able to reproduce the problem on the github action workflow on my fork or locally. So I have to wait for the nushell repo to release a new version that will trigger the workflow and that only happens every 3 weeks 😐

By the way the repo you are deleting is the fork of the winget-pkgs repo, right ?

I was laso wondering if enabling logs on the repo would help to see more information on the workflow run or not.

[ryfu-msft]

I see, you are probably right.

But unfortunately I am not able to reproduce the problem on the github action workflow on my fork or locally. So I have to wait for the nushell repo to release a new version that will trigger the workflow and that only happens every 3 weeks 😐

By the way the repo you are deleting is the fork of the winget-pkgs repo, right ?

I was laso wondering if enabling logs on the repo would help to see more information on the workflow run or not.

Hey @TechWatching ,

I have linked the PR to address this issue. Looks like there was a timing issue when trying to immediately reference the forked repo that was just created. If a forked repo already exists, this issue doesn't repro. I believe if you were to try triggering the workflow again and the owner of the PAT already has a fork of winget-pkgs, it should work without issues.

To answer your question, yes, we would only delete the fork of the winget-pkgs repo if the PR submission fails and we created the fork for you. So if the fork had already existed but the PR submission failed, we still wouldn't delete the fork.

Once my PR gets checked in, we hope to get a new release out soon that can resolve your issues. Thanks for your help with this confusing issue and sorry for the inconvenience it may have caused you.

[TechWatching]

@ryfu-msft This solved the issue we had. Thanks for the fix and the explaination. By the way I wrote an article about winget create and in particular about using it from github actions like we did on nushell repository: https://www.techwatching.dev/posts/wingetcreate. I have not seen documentation about doing that so I hope it will help others doing the same.