Bundle analysis comment error in CI

[mikeesto]

URL:

N/A

Browser Name:

N/A

Browser Version:

N/A

Operating System:

N/A

How to reproduce the issue:

Looking through some recent PRs (for example, #5566), the bundle analysis comment step keeps failing in CI with the following error:

/home/runner/work/_actions/peter-evans/create-or-update-comment/c6c9a1a66007646a28c153e2a8580a5bad27bcfa/dist/index.js:4694
      const error = new requestError.RequestError(toErrorMessage(data), status, {
                    ^

RequestError [HttpError]: Resource not accessible by integration
    at /home/runner/work/_actions/peter-evans/create-or-update-comment/c6c9a1a66007646a28c153e2a8580a5bad27bcfa/dist/index.js:4694:21
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  status: 403,
  response: {
    url: 'https://api.github.com/repos/nodejs/nodejs.org/issues/comments/[16](https://github.com/nodejs/nodejs.org/actions/runs/5709007356/job/15467258076?pr=5566#step:11:17)5720[18](https://github.com/nodejs/nodejs.org/actions/runs/5709007356/job/15467258076?pr=5566#step:11:19)44',
    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',
      connection: 'close',
      'content-encoding': 'gzip',
      'content-security-policy': "default-src 'none'",
      'content-type': 'application/json; charset=utf-8',
      date: 'Sun, 30 Jul [20](https://github.com/nodejs/nodejs.org/actions/runs/5709007356/job/15467258076?pr=5566#step:11:21)23 23:50:49 GMT',
      'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin',
      server: 'GitHub.com',
      'strict-transport-security': 'max-age=31536000; includeSubdomains; preload',
      'transfer-encoding': 'chunked',
      vary: 'Accept-Encoding, Accept, X-Requested-With',
      'x-content-type-options': 'nosniff',
      'x-frame-options': 'deny',
      'x-github-api-version-selected': '20[22](https://github.com/nodejs/nodejs.org/actions/runs/5709007356/job/15467258076?pr=5566#step:11:23)-11-28',
      'x-github-media-type': 'github.v3; format=json',
      'x-github-request-id': '0A04:79BC:82DA6F:10E8DFC:64C6F758',
      'x-ratelimit-limit': '15000',
      'x-ratelimit-remaining': '14980',
      'x-ratelimit-reset': '16907645[24](https://github.com/nodejs/nodejs.org/actions/runs/5709007356/job/15467258076?pr=5566#step:11:25)',
      'x-ratelimit-resource': 'core',
      'x-ratelimit-used': '20',
      'x-xss-protection': '0'
    },
    data: {
      message: 'Resource not accessible by integration',
      documentation_url: 'https://docs.github.com/rest/issues/comments#update-an-issue-comment'
    }
  },
  request: {
    method: 'PATCH',
    url: 'https://api.github.com/repos/nodejs/nodejs.org/issues/comments/1657201844',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': 'octokit-core.js/3.6.0 Node.js/16.16.0 (linux; x64)',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },
    body: '{"body":"## 📦 Next.js Bundle Analysis for nodejs.org\\n\\nThis analysis was generated by the [Next.js Bundle Analysis action](https://github.com/hashicorp/nextjs-bundle-analysis). 🤖\\n\\nThis PR introduced no changes to the JavaScript bundle! 🙌<!-- __NEXTJS_BUNDLE_nodejs.org -->"}',
    request: {
      agent: Agent {
        _events: [Object: null prototype] {
          free: [Function (anonymous)],
          newListener: [Function: maybeEnableKeylog]
        },
        _eventsCount: 2,
        _maxListeners: undefined,
        defaultPort: 443,
        protocol: 'https:',
        options: [Object: null prototype] { path: null },
        requests: [Object: null prototype] {},
        sockets: [Object: null prototype] {},
        freeSockets: [Object: null prototype] {},
        keepAliveMsecs: 1000,
        keepAlive: false,
        maxSockets: Infinity,
        maxFreeSockets: [25](https://github.com/nodejs/nodejs.org/actions/runs/5709007356/job/15467258076?pr=5566#step:11:26)6,
        scheduling: 'lifo',
        maxTotalSockets: Infinity,
        totalSocketCount: 0,
        maxCachedSessions: 100,
        _sessionCache: {
          map: {
            'api.github.com:4[43](https://github.com/nodejs/nodejs.org/actions/runs/5709007356/job/15467258076?pr=5566#step:11:44):::::::::::::::::::::': [Buffer [Uint8Array]]
          },
          list: [ 'api.github.com:[44](https://github.com/nodejs/nodejs.org/actions/runs/5709007356/job/15467258076?pr=5566#step:11:45)3:::::::::::::::::::::' ]
        },
        [Symbol(kCapture)]: false
      },
      hook: [Function: bound bound register]
    }
  }
}

[MattIPv4]

This is a result of switching the workflow to being triggered based on pull_request rather than pull_request_target, to avoid random folks being able to create PRs that trigger workflows instantly and dump secrets from the repository config.

Although the workflow specifies pull-requests: write in the permissions stanza, GitHub automatically restricts it to read-only by default, for security. It sounds like it is possible to overwrite this: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs#changing-the-permissions-in-a-forked-repository

I believe @ovflowd set PR workflow runs to always require manual approval, so I think it'd probably be safe to allow tokens to have write permissions on forks, as a human will always be in the loop to check things first.

[ovflowd]

@mikeesto can you re-run your workflows? And test?

Edit: Apparently that setting is only for private repositories.

[ovflowd]

@MattIPv4 I didn't find this setting on the nodejs.org settings (Specifically: "Send write tokens to workflows from pull requests")

I've only seen it on the org-wide settings but they only apply for private repositories. Do you have any idea where this setting might be?

[ovflowd]

Sadly I have no clue what else can be done. But as I mentioned, @MattIPv4 that's genuinely a big bummer, and I would definitely then consider going back to pull_request_target if no other solution is found 😢

[ovflowd]

@MattIPv4 could you check this PR? #5577