Skip to content
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

Repositories.UpdateBranchProtection returning 422 Error when restrictions contain empty fields #1546

Closed
anGie44 opened this issue May 30, 2020 · 6 comments · Fixed by #1571
Closed

Comments

@anGie44
Copy link
Contributor

anGie44 commented May 30, 2020

With the release of v32.0.0, a BranchRestrictionsRequest object now omits empty fields in the JSON, however, when passing a ProtectionRequest with the following BranchRestrictionsRequest object to the repositories.UpdateBranchProtection method, the client returns the error below:

restrictions := new(github.BranchRestrictionsRequest)
restrictions.Users := []string{"angie44"}
restrictions.Teams := []string{}
restrictions.Apps := []string{}
Error: PUT https://api.github.com/repos/example-org/example-repo/branches/master/protection: 422 Invalid request.

        No subschema in "anyOf" matched.
        "teams" wasn't supplied.
        Not all subschemas of "allOf" matched.
        For 'anyOf/1', {"users"=>["anGie44"]} is not a null. []

Per the docs, empty fields in the BranchRestrictionsRequest object should be specified with the empty []string{} instead of nil, but even so this results in the above error.

If however, the empty fields are set with a slice of size 1, i.e. make([]string, 1), then the PUT request succeeds without error.

I wonder if there is another way we should be specifying the empty fields now that they are represented differently in the JSON request objects?

@anGie44 anGie44 changed the title repositories.UpdateBranchProtection returning 422 Error when restrictions contain empty fields Repositories.UpdateBranchProtection returning 422 Error when restrictions contain empty fields May 30, 2020
@gmlewis
Copy link
Collaborator

gmlewis commented May 30, 2020

It looks like #1530 broke this behavior.
@anGie44 - can you please take a look at #1530 and see if you think that it needs to be reverted?
If, however, that is still needed, we might need to split this behavior into two endpoints like we have done recently for another similar situation. (I will have to look it up, but later.)

@anGie44
Copy link
Contributor Author

anGie44 commented May 30, 2020

ohh I see, yep i think those changes are still valid b/c that use case was for personal repos and it seems the github API allows for empty users/teams fields..but for some reason that's not the case for organization-owned repos? splitting into 2 endpoints may make sense, or maybe refactor the underlying BranchProtectionRequest struct (1 for personal repos, 1 for org-owned repos)?

@gmlewis
Copy link
Collaborator

gmlewis commented May 30, 2020

@michelangelomo - can you please comment on this issue?

@anGie44
Copy link
Contributor Author

anGie44 commented May 30, 2020

hmm I may have spoken too soon..I just had a chance to test this with my personal account, and I'm still seeing the error (updated example):

   Error: PUT https://api.github.com/repos/anGie44/tf-acc-test-branch-prot-rm2cp/branches/master/protection: 422 Invalid request.

        No subschema in "anyOf" matched.
        "teams", "users" weren't supplied.
        Not all subschemas of "allOf" matched.
        For 'anyOf/1', {"apps"=>["hashibot"]} is not a null. []

This error appears with BranchRetrictionsRequest.Teams and BranchRetrictionsRequest.Users not explicitly set, set with nil or set with []string{} though the error we would expect for personal repos does occur when I set the Teams and Users attributes to non-empty slices (make([]string, 1)):

Error: PUT https://api.github.com/repos/anGie44/tf-acc-test-branch-prot-8cfht/branches/master/protection: 422 Validation Failed [{Resource: Field: Code: Message:Only organization repositories can have users and team restrictions}]

@dcatalano-figure
Copy link

I rolled back from v32 to v31 and the issue disappears. To be fair, I am working with organizational repos not organization-less repos

@ejhayes
Copy link

ejhayes commented Jul 8, 2020

Any idea what might be going on here @anGie44 or @michelangelomo? It looks like the error solved by #1530 might actually be a bit more nuanced. I came across this related issue that seems pretty similar PyGithub/PyGithub#1335

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants