[BUG] - Github Action cannot assign teams

adussarps · September 8, 2020, 1:35pm

Hello there;

I have a little issue with github actions. Using curl and the default “GITHUB_TOKEN” from the github action; I can successfully add a user as a reviewer or refer to a user in a comment (with the @notation). But when it comes to teams, this doesnt work, it’s seems to be due to an authorization issue.

I don’t want to use a PAT as it’s not generic enough. Would you know a way to work around this or grant authorization to the github-action bot to have access to teams?

Regards

Antoine Dussarps

PS: The issue is also referenced here: https://github.com/peter-evans/create-pull-request/issues/155

kingthorin · September 8, 2020, 3:11pm

What makes you think this is a bug? Is it documented somewhere that it should work?

brightran · September 9, 2020, 3:15am

@adussarps ,

This is not a bug.

When using the GitHub REST API “Request reviewers for a pull request” to add the team reviewers, the following preparations are required:

The teams has been added into the repository as the collaborators.
The authorization token of the API requires the “repo” scope.

The GITHUB_TOKEN does not have the “repo” scope, so you need to create a personal access token (PAT) with the “repo” scope at least.

Here is an example as reference:

github.com

TestWorkflowsRML/Event-Triggers/blob/f201a638566bc806c387dfb2ab60268e536d8c96/.github/workflows/pull-request.yml#L14



jobs:
  job1:
    runs-on: ubuntu-latest
    steps:
      - name: view the github context
        run: echo "$GITHUB_CONTEXT"
        env:
          GITHUB_CONTEXT: ${{ toJson(github) }}

      - name: Add team reviewers
        if: ${{ github.event_name == 'pull_request' }}
        run: |
          curl \
          -X POST \
          -H "Authorization: token ${{ secrets.REPO_SCOPE }}" \
          -H "Accept: application/vnd.github.v3+json" \
          https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/requested_reviewers \
          -d '{"team_reviewers":["allme"]}'

adussarps · September 9, 2020, 7:41am

Well, as it does work for standalone users and not for teams, I assumed it was not an intended behavior; but it might be just expected.

My point is, that it does work well with a “PAT” but it’s not a good and maintainable solution; as the token could get revoked or I might delete my account.

Would you know another way to work around this?

brightran · September 9, 2020, 9:49am

@adussarps ,

As mentioned above, accessing teams needs more permission scopes (“repo”) than accessing users. The GITHUB_TOKEN does not have the “repo” scope.

The GITHUB_TOKEN is automatically created by GitHub when before each job begins in the workflow. Is contains the “read/write” access for many permissions, and we can’t customize the permission scopes of this token.
Any users (include the external users) who can trigger workflows in your repository, they can use the GITHUB_TOKEN to do any thing ( read/write ) allowed by the permissions of the token in the workflow.
In the workflow triggered from the forked repository, the GITHUB_TOKEN only has the “read” access for the allowed permissions.
If extending the permission scopes of GITHUB_TOKEN, this may bring some security risk.

When you create a personal access token (PAT), you can customize and limit the permission scopes of the token so that other users can’t use this PAT to do some things you don’t want them to do in the workflow.

MaxHorstmann · November 24, 2020, 1:55pm

Having just dealt with this same issue, I agree with OP this is not the expected/ideal behavior.

It feels like a relatively common use case that some sort of workflow (GitHub Actions or other) would make some changes in a branch (e.g. update dependencies, run linter…), and then automatically create a PR and request a review from an entire team.

As pointed out in this thread, it would be easier to use GITHUB_TOKEN for this scenario than a custom PAT (which needs to be maintained, associated with a service accout etc). It would appear that GITHUB_TOKEN generally exists for that reason.

It makes sense not to add the repo scope to GITHUB_TOKEN for security reasons.

However, I don’t quite follow why the repo scope is required in the first place to request a review from a team. It’s already possible to request reviews from individual users with GITHUB_TOKEN. Why not also allow requesting a review from an existing team which already has been added as a collaborator to the repo?

dreyks · November 26, 2020, 10:08am

Bumped into this too. Was even gonna create a support ticket because this looked like a bug to me. Like the above people said it’s extremely unexpected that a single token can request individual reviews but fails to do that for teams

I would’ve understood had this required read:org permissions (just like /orgs/{org}/teams/{team_slug}/memberships/{username}) but doesn’t need it and wants a repo scope instead. This looks rather inconsistent

Maybe it’s not about adding scopes to GITHUB_TOKEN (which as mentioned above would be a security concern) but about changing /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers to not require the repo scope for requesting team reviews?

Also, lacking this permission results in a 422, not a 403, that’s why it looked like a bug to me