-
Notifications
You must be signed in to change notification settings - Fork 128
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
Failed step "success" of plugin "@semantic-release/github" #738
Comments
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 |
@travi same issue with The release itself is published correctly (which is proof of correct credentials), yet the success step fails. |
Any news on this issue? |
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 |
This comment was marked as off-topic.
This comment was marked as off-topic.
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 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 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. |
Great stuff @jedwards1211, just like you confirmed, there's already a step in the We sure want to continue to improve in most especially the |
@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:
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. |
I always wanted to add a
Clever! Would only work if there is an existing issue or release but better than nothing
The I think we should move this into a separate issue about improving the |
Done, also added semantic-release/npm#848 |
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
this is the relevant part of the workflo
here's the error dump
Error Dump
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.
The text was updated successfully, but these errors were encountered: