Skip to content

Potentially breaking change introduced in #897 - clarification needed #914

@dominykas

Description

@dominykas

#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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions