Failed step "success" of plugin "@semantic-release/github"

[hashem78]

I'm getting this error on the final step of my action, weirdly enough it releases and tags correctly but the error appears nonetheless.

here's the relevant part from my .releaserc

[
            "@semantic-release/github",
            {
                "successComment": false,
                "assets": {
                    "path": "some-path",
                    "name": "some-name",
                    "label": "some-label"
                }
            }
        ]

this is the relevant part of the workflo

      - name: Semantic Release
        uses: cycjimmy/semantic-release-action@v4
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

here's the error dump

Error Dump

 [9:25:46 AM] [semantic-release] › ✘  Failed step "success" of plugin "@semantic-release/github"
[9:25:46 AM] [semantic-release] › ✘  An error occurred while running semantic-release: RequestError [HttpError]: Validation Failed: {"message":"The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.","resource":"Search","field":"q","code":"invalid"}
    at /home/runner/work/_actions/cycjimmy/semantic-release-action/v4/node_modules/@octokit/request/dist-node/index.js:112:21
Error: AggregateError: 
    HttpError: Validation Failed: {"message":"The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.","resource":"Search","field":"q","code":"invalid"}
        at /home/runner/work/_actions/cycjimmy/semantic-release-action/v4/node_modules/@octokit/request/dist-node/index.js:112:21
        at async requestWithGraphqlErrorHandling (/home/runner/work/_actions/cycjimmy/semantic-release-action/v4/node_modules/@octokit/plugin-retry/dist-node/index.js:71:20)
        at async Job.doExecute (/home/runner/work/_actions/cycjimmy/semantic-release-action/v4/node_modules/bottleneck/light.js:405:18)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async requestWithGraphqlErrorHandling (/home/runner/work/_actions/cycjimmy/semantic-release-action/v4/node_modules/@octokit/plugin-retry/dist-node/index.js:71:20)
    at async Job.doExecute (/home/runner/work/_actions/cycjimmy/semantic-release-action/v4/node_modules/bottleneck/light.js:405:18) {
  status: 422,
  response: {
    url: 'https://api.github.com/search/issues?q=in%3Atitle+repo%3AMYORG%2FMYREPO+type%3Aissue+state%3Aopen+The%20automated%20release%20is%20failing%20%F0%9F%9A%A8',
    status: 422,
    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',
      'cache-control': 'no-cache',
      'content-length': '301',
      'content-security-policy': "default-src 'none'",
      'content-type': 'application/json; charset=utf-8',
      date: 'Sun, 12 Nov 2023 09:25:46 GMT',
      'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin',
      server: 'GitHub.com',
      'strict-transport-security': 'max-age=31536000; includeSubdomains; preload',
      vary: 'Accept, Authorization, Cookie, X-GitHub-OTP, Accept-Encoding, Accept, X-Requested-With',
      'x-content-type-options': 'nosniff',
      'x-frame-options': 'deny',
      'x-github-api-version-selected': '2022-11-28',
      'x-github-media-type': 'github.v3; format=json',
      'x-github-request-id': '2480:222D:2A7410:2CEC77:65509A1A',
      'x-ratelimit-limit': '30',
      'x-ratelimit-remaining': '29',
      'x-ratelimit-reset': '1699781206',
      'x-ratelimit-resource': 'search',
      'x-ratelimit-used': '1',
      'x-xss-protection': '0'
    },
    data: {
      message: 'Validation Failed',
      errors: [Array],
      documentation_url: 'https://docs.github.com/v3/search/'
    }
  },
  request: {
    method: 'GET',
    url: 'https://api.github.com/search/issues?q=in%3Atitle+repo%3ALabiba-AI%2FLabiba.Integration+type%3Aissue+state%3Aopen+The%20automated%20release%20is%20failing%20%F0%9F%9A%A8',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': '@semantic-release/github v9.0.4 octokit-core.js/5.0.0 Node.js/20.8.1 (linux; x64)',
      authorization: 'token [REDACTED]'
    },
    request: { agent: undefined, hook: [Function: bound bound register] }
  },
  pluginName: '@semantic-release/github'
}

please note that the flow is supposed to be for a .net project, not sure if that makes a difference but alas, I've seen #415, I don't think it's relevant to my case.

[travi]

are you granting the necessary permissions to the token in your workflow?

also, this is not the team that supports the action you are using. that adds variables to your setup that complicate our ability to help you. please try to reproduce your issue in a public minimal repo without the use of the action wrapping the official project if you want help directly from us. otherwise, you may be able to get better help from the maintainers of that action instead

[kristof-mattei]

@travi same issue with semantic-release directly.

The release itself is published correctly (which is proof of correct credentials), yet the success step fails.

[IrisPeres]

Any news on this issue?

[travi]

The release itself is published correctly (which is proof of correct credentials), yet the success step fails.

different parts of the github api require different permissions. success of one step is not proof of the necessary permissions for other steps. this is a permissions problem. review the github token used and add the missing permissions based on the needs documented in the link provided above

[travi]

Affecting us as well, for whatever it's worth.

@jodelamo looking at your release workflow logs, your error is different than the on that this thread was opened for. please open new issues for different errors rather than adding to unrelated threads

[jedwards1211]

I wish @semantic-release/github would try to check permissions that all steps need up front, including the success step, and abort before doing any release if permissions are lacking. It already checks some permissions in verifyGithub, but it could check more.

That way, if the token is lacking permission to add issue comments, instead of having to manually add those comments after the success step fails, my release would just be blocked until I fix the permissions, and then the success step would add the desired comments.

It seems like GitHub's API doesn't give us perfect ability to check permissions, but in the case of OP's issue, running octokit.rest.issues.listForRepo before release to see if the request fails would have caught their problem.

Checking permission for write requests would be harder, but there is a way to get the scopes of a classic PAT. It would be nice if GitHub's API provided a dry-run mode that checks permissions but doesn't write anything, we could certainly feature request it and make a case for how it would be beneficial.

I'm willing to investigate this more and work on a PR if you're open to it, I was working on #886 the other day so the codebase is fresh in my mind.

[babblebey]

I wish @semantic-release/github would try to check permissions that all steps need up front, including the success step, and abort before doing any release if permissions are lacking. It already checks some permissions in verifyGithub, but it could check more.

Great stuff @jedwards1211, just like you confirmed, there's already a step in the verifyGithub that checks the required permission in that specific part of the success step.

We sure want to continue to improve in most especially the verifyCondition lifecycle of the plugin, so by all means please proceed with your investigation and open an issue/PR with your observations/solutions 😉

[jedwards1211]

@gr2m It would greatly benefit us here if the GitHub API provided a way to pre-check the permissions of write operations (commits, tags, releases, issues) without actually making modifications. I see you work at GitHub, do you think it's possible we could get such a feature added to the GitHub API?

What I've found out so far is:

• We can check push permission by running git push with no changes
• We can get the scopes of a classic PAT but this doesn't work for fine-grained PATs right now
• GitHub devs seem open to making the permissions on a GitHub action token visible via the api, but haven't done so yet

Maybe we can check permission to update issues and releases by doing a no-op update on one (sending the title it already has in an update, etc), I will have to experiment. But we'd be able to avoid hacky workarounds if the GitHub API provided an explicit way to check if we have permissions to do a certain operation.

[gr2m]

I always wanted to add a GET /actor, it's been my number 1 ask since long before I started working at GitHub 🤣
https://github.com/gr2m/github-api-wishlist

Maybe we can check permission to update issues and releases by doing a no-op update on one

Clever! Would only work if there is an existing issue or release but better than nothing

running git push with no changes

The github plugin does not use the git app, only semantic-release core does that. The github plugin exclusively interacts with APIs.

---

I think we should move this into a separate issue about improving the verify step, could you do that?

[jedwards1211]

Done, also added semantic-release/npm#848