Repository navigation
Can't use GitHub CLI with GITHUB_TOKEN to mark PR as ready from GitHub Action #1314
Description
This looks a bit similar to #1026, but I don't think it's the same.
gh has been added to the virtual environment for GitHub actions recently; as per the README, it's version 10.1 since the 20200625.0 update of the environment.
I'm using it to create a new branch and then a pull request from a GitHub Actions workflow; to authenticate, I use the GITHUB_TOKEN, support for which has been added in #976.
To create a branch, I'm running this command in my workflow:
GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }} \
gh api repos/:owner/:repo/git/refs \
--raw-field ref=refs/heads/sandbox-release-2020-07-03 \
--raw-field sha="$(git rev-parse --verify HEAD)"which works fine.
To create the pull request, I run
git fetch origin
git checkout sandbox-release-2020-07-03
GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }} \
gh pr create --base sandbox --label release \
--title 'Sandbox release 2020-07-03' --body ''which also works fine.
Now, I have a Slack channel listening to this repo, for PRs with the release label. However, the label seems to be applied to the PR after it has been created, so the Slack notification isn't triggered (see integrations/slack#1039).
To get a notification, I'm creating the PR as a draft first, then switch it to ready; this does trigger the notification. However, I'm running into a problem with the auth scopes required for this. This is what I run:
git fetch origin
git checkout sandbox-release-2020-07-03
export GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }}
gh pr create --base sandbox --label release --draft \
--title 'Sandbox release 2020-07-03' --body ''
gh pr ready sandbox-release-2020-07-03Each gh command generates a warning:
Warning: gh now requires the `read:org` OAuth scope.
Visit https://github.com/settings/tokens and edit your token to enable `read:org`
or generate a new token for the GITHUB_TOKEN environment variable
and the gh pr ready command fails with
API call failed: Resource not accessible by integration
When I use a personal access token instead of GITHUB_TOKEN and give it the read:org OAuth scope, the PR can be marked as ready, but then everything will show up as created by my user instead of the GitHub Actions user, and it also feels like this should work out of the box.
Is this something that can be fixed in gh? Why does marking a PR as ready even require read:org permissions?
Activity
mislav commentedon Jul 6, 2020
This is interesting; thanks for letting us know! I'll be looking into this, since I know no reason why this resource wouldn't be available when using GITHUB_TOKEN in Actions.
It doesn't, but creating a PR and asking for reviewers does need
read:org, since reviewers can be teams. Because of that, we just issue a blanket notice about needingread:org. I understand that it's noisy and unnecessary in your use-case. We will consider removing the notice for endpoints where it's not necessary, or removing it at all in the context of Actions. 🤔bewuethr commentedon Jul 6, 2020
I have teams as code owners defined in that repository, and marking a PR as ready is actually requesting a review from them – might that be the reason?
mislav commentedon Jul 6, 2020
@bewuethr That's a really good lead for reproducing; thank you!
I would still classify that as an API bug, though. Let me first try to reproduce it and then I will report internally.
davereid-pfg commentedon Mar 1, 2022
I'm still running into this today trying to use our default ${{ secrets.GITHUB_TOKEN }} within a Github action to run
gh pr readyand running into the same issue:github: remove broken workflow to enable auto-merge for Dependabot
github: remove broken workflow to enable auto-merge for Dependabot
mislav commentedon Sep 15, 2022
@bewuethr @davereid-pfg @martinvonz If you enable
GH_DEBUG=apienvironment variable, gh will print full HTTP logs to stderr. That will allow you to inspect the full GraphQL API response from the server and see exactly which part of the query reportsResource not accessible by integration. This information would be helpful; thanks!bewuethr commentedon Oct 15, 2022
I have created a POC repo with a workflow that tries to mark a PR as ready.
Here is an example workflow run, with the mutation to mark the PR as ready starting here.
This is the response:
{ "data": { "markPullRequestReadyForReview": null }, "errors": [ { "type": "FORBIDDEN", "path": [ "markPullRequestReadyForReview" ], "extensions": { "saml_failure": false }, "locations": [ { "line": 1, "column": 80 } ], "message": "Resource not accessible by integration" } ] }mislav commentedon Oct 17, 2022
@bewuethr Thank you! I've used this information to internally search for what could be causing this and found an open issue where this limitation is known. For now, a generated GITHUB_TOKEN is not allowed to mark a PR as ready to review, but you might be able to circumvent this by creating a Personal Access Token and storing it as an Actions secret to be used in the workflow.
bewuethr commentedon Oct 17, 2022
Yeah, that's how I work around this currently. Thanks for the follow-up!
mislav commentedon Nov 28, 2022
Update: the above has now changed on the platform and doing
gh pr readyto mark a PR as ready orgh pr ready --undoto convert a PR back to draft now works with the generated GITHUB_TOKEN in GitHub Actions.github: new attempt at auto-enabling merge of Dependabot PRs
github: new attempt at auto-enabling merge of Dependabot PRs
github: new attempt at auto-enabling merge of Dependabot PRs
martinvonz commentedon Dec 5, 2022
Does it work only for
gh pr ready? I was hoping to use it for enabling auto-merge on Dependabot PRs so I don't have to enable it and confirm it myself (since I have branch protection set up so I have to approve it anyway).mislav commentedon Dec 7, 2022
@martinvonz I'm not sure if
gh pr merge --autowill work with GITHUB_TOKEN generated in Actions. That operation (enabling auto-merge) is completely separate from what we were discussing in this thread (marking a PR as "ready" for review). If it doesn't work, please open a new issue with your findings.Note that if you have branch protection enabled, it's intentionally hard (or impossible) to allow automation to bypass said protections. It's maybe best to then review and merge all PRs by hand, even Dependabot ones.
martinvonz commentedon Dec 7, 2022
Will do. Thanks.
Yes, I still want to approve the PRs. I just want to not have to also click the button (twice) to enable auto-merge.
suzuki-shunsuke commentedon Apr 2, 2024
I think this issue is occurring again.
I opened a new issue.
gh pr readydoesn't work with GitHub Actions' GITHUB_TOKEN secret #8910fix(cicd): find PR via GraphQL search instead of gh pr list --head
Drop `contents: write` from the Copilot review workflow