Motivation
Currently when bootstraping a new organization we get this error:
The GET /repos/{owner}/{repo}/collaborators/{username}/permission endpoint returns a permission field that provides legacy base roles rather than the full role names. According to GitHub's documentation (https://docs.github.com/en/rest/collaborators/collaborators#get-repository-permissions-for-a-user):
"The permission attribute provides the legacy base roles of admin, write, read, and none, where the maintain role is mapped to write and the triage role is mapped to read."
Our validation in validations.go only accounted for the legacy values push, maintain, and admin (write access) and pull, triage (read-only). When the API returns "write" (modern legacy base role for push/maintain access) or "read" (modern legacy base role for pull/triage access), the switch statement falls through to the default case and incorrectly reports that the user lacks write access, even when they have sufficient permissions.
This causes a false-positive validation failure for any repository where the collaborator's permission is reported as "write" or "read" by the GitHub API, breaking the bootstrap workflow for users with valid credentials.
Motivation
Currently when bootstraping a new organization we get this error:
The
GET /repos/{owner}/{repo}/collaborators/{username}/permissionendpoint returns a permission field that provides legacy base roles rather than the full role names. According to GitHub's documentation (https://docs.github.com/en/rest/collaborators/collaborators#get-repository-permissions-for-a-user):Our validation in validations.go only accounted for the legacy values push, maintain, and admin (write access) and pull, triage (read-only). When the API returns "write" (modern legacy base role for push/maintain access) or "read" (modern legacy base role for pull/triage access), the switch statement falls through to the default case and incorrectly reports that the user lacks write access, even when they have sufficient permissions.
This causes a false-positive validation failure for any repository where the collaborator's permission is reported as "write" or "read" by the GitHub API, breaking the bootstrap workflow for users with valid credentials.