Repository navigation
Allow JSON array parameters in gh api #1484
Description
Activity
Potential additional idea: use a similar syntax to pass nested objects as well, since some APIs require them as inputs. For example, the Gist API:
gh api gists -F files[myfile.txt][content][email protected]
I'm not sure if this is a crossing a line into too magic or complicated 😅
Neither
--fieldnor--raw-fieldaccept JSON arrays right now. To pass a JSON array or a nested object, one needs to construct the JSON payload outside of gh and pass it in via--input. E.g.jq -n '...' | gh api repos/:owner/:repo/deployments --input -I'm trying to GET the
repos/:owner/:repo/contentsendpoint with a specificref.This command returns the file content as expected 🎉:
% gh api repos/:owner/:repo/contents/action.ymlWhen I provide the
refparameter, however, I get 404 😢:% jq -n '{"ref": "main"}' { "ref": "main" } % jq -n '{"ref": "main"}' | gh api repos/:owner/:repo/contents/action.yml -i --input - HTTP/1.1 404 Not Found Access-Control-Allow-Origin: * Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset Content-Security-Policy: default-src 'none' Content-Type: application/json; charset=utf-8 Date: Thu, 31 Dec 2020 16:28:40 GMT Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin Server: GitHub.com Strict-Transport-Security: max-age=31536000; includeSubdomains; preload Vary: Accept-Encoding, Accept, X-Requested-With X-Accepted-Oauth-Scopes: repo X-Content-Type-Options: nosniff X-Frame-Options: deny X-Github-Media-Type: github.v3; format=json X-Github-Request-Id: DC52:1CF9:6DF32A9:BBFEBB9:5FEDFC38 X-Oauth-Scopes: gist, read:org, repo, workflow X-Ratelimit-Limit: 5000 X-Ratelimit-Remaining: 4992 X-Ratelimit-Reset: 1609433238 X-Ratelimit-Used: 8 X-Xss-Protection: 1; mode=block { "message": "Not Found", "documentation_url": "https://docs.github.com/rest" } gh: Not Found (HTTP 404) % gh api repos/:owner/:repo/contents/action.yml -f ref=main { "message": "Not Found", "documentation_url": "https://docs.github.com/rest" } gh: Not Found (HTTP 404) % gh api repos/:owner/:repo/contents/action.yml -F ref=main { "message": "Not Found", "documentation_url": "https://docs.github.com/rest" } gh: Not Found (HTTP 404)I assume I'm missing something that'll be obvious to others. @mislav do you see what I'm missing? Or have suggestions how to debug this?
@solvaholic Not sure if you solved this already but according to the doc you linked, ref is a query parameter. So you would need to do this:
gh api repos/:owner/:repo/contents/action.yml?ref=mainYou may need to quote it:
gh api 'repos/:owner/:repo/contents/action.yml?ref=main'Parameters given via
--field/--raw-fieldcan also be forced to be query parameters by explicitly configuring the method to be GET:gh api -X GET repos/:owner/:repo/contents/action.yml -f ref=mainReacted by Joe Sharp and arturo8383You may need to quote it:
:doh: I'm near certain this was a factor when I tried adding the query parameter.
Parameters given via --field/--raw-field can also be forced to be query parameters by explicitly configuring the method to be GET:
And this as well. I had in mind
ghwould default to GET for this request.Of course, both methods work. Thank you @joe-sharp @mislav 🙇
Reacted by Joe SharpI had in mind
ghwould default to GET for this request.The fact that gh automatically switches to POST once
-for-Fis added is a decision I now regret for its magic-ness 🙈 but we can't back out of it easily due to backwards-compatibility.Reacted by Roger D. Winans and Paul SachsI've managed to workaround this via the
--inputparameter. It would be awesome if arrays could be supported via the--field/--raw-fieldsyntax too.Reacted by Alexey Alekhin, Mislav Marohnić, Michael Gasch, Eva Maxfield Brown, Merouane Atig, Jonas De Kegel and navrkaldHit same issue and spend one hour mapping the OpenAPI spec against
ghbehavior and was wondering why arrays/objects are not supported, e.g.:# does not work gh api repos/:owner/:repo/issues/1/labels -f labels='["wontfix"]' # works jq -n '{"labels":["wontfix"]}' | gh api repos/:owner/:repo/issues/1/labels --input -
Will file a PR because this behavior is not clear from the docs
Pass one or more --raw-field values in "key=value" format to add **JSON-encoded string parameters** to the POST body..Reacted by Alexey Alekhin, Doug Ayers, Eva Maxfield Brown, Mauro Baluda and navrkald- added 2 commits that reference this issue
on Apr 12, 2021 This still seems to be an issue - you can't configure check contexts when setting up branch protection because of this. 😞
I think this issue is missing a label of ~bug ?
Reacted by KanameMotoyama, Dominic Green, Sean, mj-h and navrkald- added a commit that references this issue
on Oct 10, 2022 This still seems to be an issue - you can't configure check contexts when setting up branch protection because of this. 😞
I think this issue is missing a label of ~bug ?
I was able to get this to work, but the syntax was not immediately apparent. Here is an example:
gh api -X PUT /repos/zoomin-software/skins_foo/branches/development/protection -F restrictions=null -F enforce_admins=true -F 'required_pull_request_reviews[require_code_owner_reviews]=true' -F 'required_status_checks[strict]=true' -F 'required_status_checks[contexts][]=null'Note the last param I pass:
-F 'required_status_checks[contexts][]=null', with the second array within the array, but the value beingnull. This is how I was able to pass an "empty" array.Reacted by Drew Dara-Abrams and navrkald
Neither
--fieldnor--raw-fieldaccept JSON arrays right now. To pass a JSON array or a nested object, one needs to construct the JSON payload outside of gh and pass it in via--input. E.g.I propose a new array syntax for fields:
This syntax would allow passing values of any type, including an empty array, and is fully backwards-compatible. The only theoretical drawback is that it would be impossible to pass a parameter name that includes the literal
[]characters, but since no API parameters ever have[]characters in their name, I think this is not a concern.Originally posted by @mislav in #921 (comment)