Skip to content
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

Upgrade to v3 : Resource not accessible by integration #49

Closed
RobinMaronier opened this issue Mar 23, 2023 · 9 comments · Fixed by #52
Closed

Upgrade to v3 : Resource not accessible by integration #49

RobinMaronier opened this issue Mar 23, 2023 · 9 comments · Fixed by #52

Comments

@RobinMaronier
Copy link

Hi @mheap,

When i'm upgrading action to v3 from v2, I have the error Resource not accessible by integration. Everything works fine with v1 & v2.
Did I miss something ?

Thanks !!

@QcFe
Copy link

QcFe commented Mar 28, 2023

Same issue here...

@mheap
Copy link
Owner

mheap commented Mar 28, 2023

Could you both please link to the workflow that you're using?

@QcFe
Copy link

QcFe commented Mar 29, 2023

Mine is currently on a private repository (that will be made public in a while but I cannot open it right now). Here's the workflow:

name: Checks
on:
  push:
    branches:
      - main
      - develop
  pull_request:
    types:
      - opened
      - labeled
      - unlabeled
jobs:
  label: 
    name: Ensure PR not in hold
    runs-on: ubuntu-latest
    steps:
      - name: Check
        uses: mheap/github-action-required-labels@v3
        with:
          mode: exactly
          count: 0
          labels: "pr-hold"

I attach the output from the action:
image

Using v2 works correctly (apart from the set-output notice from github).

@RobinMaronier
Copy link
Author

RobinMaronier commented Mar 29, 2023

Hi !
Private repo as well 😕

name: Mandatory labels

on:
  pull_request:
    types: [ labeled, unlabeled, opened, edited, synchronize ]

jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - uses: mheap/github-action-required-labels@v3
        with:
          mode: minimum
          count: 1
          labels: "xx"

@mheap
Copy link
Owner

mheap commented Mar 31, 2023

@QcFe
Copy link

QcFe commented Mar 31, 2023

Then I guess it could happen in case of private repos? I can't see any other difference at this point...

@mheap
Copy link
Owner

mheap commented Apr 1, 2023

Found the issue. The github.token used to have implicit permissions and it no longer does.

Here's a workflow that worked for me with a private repo:

name: Checks
on:
  push:
    branches:
      - main
      - develop
  pull_request:
    types:
      - opened
      - labeled
      - unlabeled
jobs:
  label: 
    name: Ensure PR not in hold
    runs-on: ubuntu-latest
    permissions:
      issues: read
      pull-requests: read
    steps:
      - name: Check
        uses: mheap/github-action-required-labels@v3
        with:
          mode: exactly
          count: 0
          labels: "pr-hold"

@ockham
Copy link

ockham commented Jul 26, 2023

I was just facing a similar issue in our repo. FWIW, the docs on GHA permissions state:

issues: Work with issues. For example, issues: write permits an action to add a comment to an issue.
pull-requests: Work with pull requests. For example, pull-requests: write permits an action to add a label to a pull request.

This means that the suggested workaround

    permissions:
      issues: read
      pull-requests: read

won't work with add_comment set to true, right?

@mheap Would it make sense to document in the README that if people want the action to post comments to their PRs and issues, they'll need to provide a token that has write permissions for issues and PRs?

@mheap
Copy link
Owner

mheap commented Jul 30, 2023

@ockham The README documents the following in the examples:

    permissions:
      issues: write
      pull-requests: write

What would you expect to see in addition?

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

Successfully merging a pull request may close this issue.

4 participants