Permissions nesecary to comment on a PR

Been working on a workflow that will comment based on changes in the PR. But when the PR comes from the outside or Dependabot it doesn’t have all the write permissions the repo’s owner has. Does anyone know which permissions have to be set to what to make an action be allowed to comment on a PR, when that PR isn’t coming from the repo owner?

Dependabot is fun.

Technically according to the documentation:

All you need is:

    permissions:
      issues: write

Practically, you need a PAT

And practically, the scopes don’t align well with comment:

What I’ve managed to do in general is rely on pull_request_target
But do read

Because if you mess up, the consequences are pretty grave.

It’d be really nice if there was a comment scope available. Because a huge portion of GitHub actins really only need this permission. But, sadly, it doesn’t appear to exist today.

1 Like

Thanks! Been really hoping to avoid using a PAT because that widens the attack possibilities with it significantly rather than reducing it. And just setting the issues to write permissions works fine when I make the PR. But any external party still gets blocked, currently attempting the route as described here: "Error: Resource not accessible by integration" when using Dependabot · Issue #298 · marocchino/sticky-pull-request-comment · GitHub

Still feels as way to much work for something that should be handled more securely by the platform. Right now having to jump through hoops makes it to easy to implement something insecurely.

1 Like

Yeah, I’m currently playing with variations.

I’m still working on getting all of my pieces to support outputs so that I could talk to that action.

I agree, it’s incredibly inelegant.

Although, one complaint people have about my thing is that it leaves too many comments, whereas a single running comment would be nice, so it’s possible that I’ll want to use that action (I’ve been thinking about it for the past week or two).

So I currently came to this after a Twitter thread with one of the Dependabot people:

name: Composer Diff
on:
  pull_request_target:
    types:
      - opened
      - synchronize
      - reopened
permissions:
  pull-requests: write
jobs:
  comment-composer-lock-diff:
    name: Comment composer.lock diff
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Comment composer.lock diff
        uses: WyriHaximus/github-action-composer.lock-diff@main
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

For reference that Twitter thread can be found here: https://twitter.com/WyriHaximus/status/1393679576828686340

1 Like

Btw, I’m shocked to see anyone using actions/checkout@v1 at this point.

v1 has been dead since:

Why? That commit is included in the v1 tag, I’m rather shocked that you didn’t notice that as it’s right there when you open the page:

Because v2 was a major change from v1; v1 is clearly not getting updates. So, unless there’s a specific reason to use v1, one really shouldn’t.

Ow absolutely, most of my workflows (that I haven’t forgotten to update) are running on v2, especially ones with big repositories. However, that specific action I’ve build has a very specific git use case that I’ve been unable to get working on v2, so yeah it uses v1 because that just works.