-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Comments
It looks like #1530 broke this behavior. |
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 |
@michelangelomo - can you please comment on this issue? |
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):
This error appears with
|
I rolled back from v32 to v31 and the issue disappears. To be fair, I am working with organizational repos not organization-less repos |
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 |
With the release of
v32.0.0
, aBranchRestrictionsRequest
object now omits empty fields in the JSON, however, when passing aProtectionRequest
with the followingBranchRestrictionsRequest
object to therepositories.UpdateBranchProtection
method, the client returns the error below:Per the docs, empty fields in the
BranchRestrictionsRequest
object should be specified with the empty[]string{}
instead ofnil
, 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 thePUT
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?
The text was updated successfully, but these errors were encountered: