"RequestError [HttpError]: Resource not accessible by integration" for .github/workflows /translation.yml

[IamLizu]

As seen in #1552, the translation.yml gives the following error,

RequestError [HttpError]: Resource not accessible by integration
    at /home/runner/work/_actions/actions/github-script/v5/dist/index.js:4560:21
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async eval (eval at callAsyncFunction (/home/runner/work/_actions/actions/github-script/v5/dist/index.js:4888:16), <anonymous>:17:1)
    at async main (/home/runner/work/_actions/actions/github-script/v5/dist/index.js:4943:20) {
  status: 403,
  response: {
    url: 'https://api.github.com/repos/expressjs/expressjs.com/issues/1552/labels',
    status: 403,
    headers: {
      'access-control-allow-origin': '*',
      'access-control-expose-headers': 'ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset',
      'content-encoding': 'gzip',
      'content-security-policy': "default-src 'none'",
      'content-type': 'application/json; charset=utf-8',
      date: 'Thu, 01 Aug 2024 05:28:32 GMT',
      'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin',
      server: 'github.com',
      'strict-transport-security': 'max-age=[31](https://github.com/expressjs/expressjs.com/actions/runs/10192586788/job/28195713099?pr=1552#step:3:32)536000; includeSubdomains; preload',
      'transfer-encoding': 'chunked',
      vary: 'Accept-Encoding, Accept, X-Requested-With',
      'x-accepted-github-permissions': 'issues=write; pull_requests=write',
      'x-content-type-options': 'nosniff',
      'x-frame-options': 'deny',
      'x-github-api-version-selected': '2022-11-28',
      'x-github-media-type': 'github.v3',
      'x-github-request-id': '3841:1809F2:10FEF4:1FA623:66AB1D00',
      'x-ratelimit-limit': '5000',
      'x-ratelimit-remaining': '4997',
      'x-ratelimit-reset': '1722493712',
      'x-ratelimit-resource': 'core',
      'x-ratelimit-used': '3',
      'x-xss-protection': '0'
    },
    data: {
      message: 'Resource not accessible by integration',
      documentation_url: 'https://docs.github.com/rest/issues/labels#add-labels-to-an-issue',
      status: '403'
    }
  },
  request: {
    method: 'POST',
    url: 'https://api.github.com/repos/expressjs/expressjs.com/issues/1552/labels',
    headers: {
      accept: 'application/vnd.github.-preview+json',
      'user-agent': 'actions/github-script octokit-core.js/3.5.1 Node.js/20.13.1 (linux; x64)',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },
    body: '{"labels":["requires-translation-uz"]}',
    request: { agent: [Agent], hook: [Function: bound bound register] }
  }
}
Error: Unhandled error: HttpError: Resource not accessible by integration

I assume the token used to run this action has permission problem? Perhaps we should give full access to repo?

[UlisesGascon]

Good point @IamLizu! I was having similar issues recently with other actions that are generating PRs, I was thinking that maybe it is a GitHub issue, but maybe we need to do some changes in our side 🤔

Maybe we need to define a pull-requests level access (Docs).

Do you want to work on it?

[IamLizu]

@UlisesGascon sure, I will be happy to sort this one out.

Edit: There's another thing, do you think we should only call the addLabels when we labelsToAdd is not-empty?

[bjohansebas]

This workflow is still failing, as can be seen in the following PR (#1575) with the same error.

[IamLizu]

Strange, could it be related with who is triggering the action run? I remember that @UlisesGascon ran one manually and it worked.

[bjohansebas]

Maybe updating actions/github-script@v5 to the latest version could resolve these errors by using a more up-to-date version of Node.js.

Edit: https://github.com/expressjs/expressjs.com/actions/runs/10464179650/job/28977347683?pr=1554

[bjohansebas]

I've noticed that in some cases, the script tries to add all the labels for the translation when only a single image or a simple page has been modified, that's what I've seen in the logs.

Some actions:

• https://github.com/expressjs/expressjs.com/actions/runs/10430000337/job/28888057823?pr=1575
• https://github.com/expressjs/expressjs.com/actions/runs/10207738610/job/28243057792?pr=1555

Edit: I tested it on my repository in this PR (https://github.com/bjohansebas/expressjs.com/pull/3), and it does exhibit that behavior. Should this be happening, or is it a bug? Additionally, it's curious how the pipeline works, which makes me think it might be a repository permissions issue or, as @IamLizu mentioned, it could be related to who is triggering the action run.

[IamLizu]

Hey 👋

While I was working on a personal project yesterday, I have faced this as well. It appears we need to specify GitHub token in the workflow and the GitHub token should have all required permissions.

I will go ahead and create a PR for this one. I hope we can later check our existing token or setup if needed by someone who has access.

[carlosstenzel]

I checked the execution of the action

is not running with write permission

[IamLizu]

Hi @carlosstenzel 👋

is not running with write permission

Yes, I think that even after specifying write for pull_request the GITHUB_TOKEN is being generated for a read-only scope for the PRs for those who do not have write access to the repository.

Assuming that, I suggest that we specify a PAT for this. I had actually implemented this PAT approach in one of my repos recently. There might be other ways, I am open to other instructions or thoughts.

In case we move with the PAT approach, I have push a fix for this specifying the PAT token in the workflow like I did in my repository. But I will need to know the name of the PAT token. PAT has to have necessary permissions and should be set in repository secret.

And if someone else wants to do this another way other than PAT, please feel free to open a PR. I will assign it to you.

cc: @jonchurch @crandmck

[carlosstenzel]

@IamLizu #1480 (comment)

[IamLizu]

Hey @carlosstenzel 👋

Sorry I guess I missed this one somehow. Thanks for marking that related comment, and yes, it is what's happening so far. I agree with you as I have already said this in my earlier comments.

I wonder if its possible to solve without using a PAT.

[bjohansebas]

@IamLizu I think there is no other way to solve it unless they fix the repository/organization permissions or use the PAT as you suggested

[italojs]

Agree with the PAT option
In terms of security, creating a Personal Access Token (PAT) is better than configuring the default GITHUB_TOKEN, the GITHUB_TOKEN can be used for other (bad)purposes and pass in PR review.
By using a PAT specifically for this purpose, it becomes easier to detect any misuse in pull requests and simpler to revoke the token if we encounter any problems or leaks.

[IamLizu]

cc: @expressjs/express-tc

[IamLizu]

I have noticed that nodejs has a process for requesting classic access tokens when needed, https://github.com/nodejs/admin/blob/main/request-an-access-token.md

[bjohansebas]

It's interesting that despite having write permissions, it still doesn't work.

[carlosstenzel]

The fine-grained token must have at least one of the following permission sets:

"Issues" repository permissions (write)
"Pull requests" repository permissions (write)

https://docs.github.com/en/rest/issues/labels?apiVersion=2022-11-28#add-labels-to-an-issue

[carlosstenzel]

@bjohansebas

please, add a modified translation page, to test the action in #1642

[jonchurch]

This has to do with permission model for PRs originating from Forks in actions. docs

You can see the Action history that any PR which is a branch in the repo itself has the right perms.

After looking into this, idk that there's a safe way to do this tbh. We can use pull_request_target to give forks the right permissions, but then they could possibly leak the token w/ those elevated perms. Same w/ the PAT approach, could trigger a workflow run, alter the workflow fil ein the PR, leak the token.

A github bot or github app might be the safest way to do this, can edit the PRs w/o having elevated permissions in a workflow file that can be altered by PRs coming from forks.

[bjohansebas]

I think we should have our own GitHub bot, there are many things that can be automated (like documentation between organizations) and it would avoid security risks like the one with pull_request_target.