feat: Refactor repository collaborators#3233
Conversation
|
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with |
55043eb to
4be7e25
Compare
deiga
left a comment
There was a problem hiding this comment.
Partial review. Loving the direction here!
4be7e25 to
42a9206
Compare
42a9206 to
9e51b07
Compare
|
@robert-crandall please could you review this PR? |
robert-crandall
left a comment
There was a problem hiding this comment.
Overall this looks good. I left some questions double checking intent.
Signed-off-by: Steve Hipwell <[email protected]>
9e51b07 to
cce7ad0
Compare
|
@robert-crandall this should be good for a re-review. |
Signed-off-by: Steve Hipwell <[email protected]>
When the invitee of `github_repository_collaborators` is an organization
member who is not yet a direct collaborator, GitHub's REST API returns
`204 No Content` from `PUT /repos/{owner}/{repo}/collaborators/{username}`
(the user is promoted to direct collaborator immediately, no invitation is
issued). The Go client surfaces this as `inv == nil, err == nil`.
Since #3233 the create/update path in `updateUserCollaboratorsAndInvites`
unconditionally dereferences `inv.ID`, causing a nil pointer panic for
any configuration that adds an org member as a direct collaborator for
the first time.
Guard the invitation-tracking branch on `inv != nil`. On the 204 path
there is no invitation to record; the user is a direct collaborator
already and will be picked up by the next `listUserCollaborators` call.
Signed-off-by: bofus10 <[email protected]>
Resolves #2874
Before the change?
github_repository_collaboratorserrored if the repo was renamedgithub_repository_collaboratorsprefered team ID and made extra calls if slug was usedgithub_repository_collaboratorsused unnecessary API calls to re-readAfter the change?
github_repository_collaboratorssupports the repository being renamedgithub_repository_collaboratorsuses the minimum number of API callsPull request checklist
Does this introduce a breaking change?
Please see our docs on breaking changes to help!