-
Notifications
You must be signed in to change notification settings - Fork 146
Description
#897 introduces a requirement for the token to be associated with a user that has maintain permission.
That was not necessary in the past, and should probably be considered a breaking change?
Moreover, we've never had issues with just the push permissions - not sure if there was any specific rationale around it? This was picked up in the review, and noted as "probably can't write issues, releases and pull requests" - but I'm not sure that's the case - the standard push permissions gives most of that access?
I'm also not 100% certain how that maps to the concept of roles and actual permissions in Github - it is possible to set things up in such a way that roles have different permissions, so quite possibly the naive maintain check is not enough and needs explicit checks for specific API access?
When the user does not have the maintain permission, it then performs the check to HEAD /installation/repositories - however that is only necessary when running as an app. If semantic-release is running inside e.g. Jenkins - then this check does not make sense, as generally semantic-release does not need to "List repositories accessible to the app installation" anyways to perform a release?