The current abort_if_fail takes a general message, and most uses were passing along the response.reason, response.status_code, and response.json()['message']. However, without the errors section of the json, it's impossible to know why the request failed. This PR will make it standard to print the entire response within the function. E.g., imagine for this request if we could not see the "errors" - it would be an error akin to #56 that isn't easiily known.
$ curl -X POST -H "Accept: application/vnd.github.v3+json" -H "Authorization: token $GITHUB_TOKEN" https://api.github.com/repos/$REPO/pulls -d '{"head":"$HEAD", "base":"$BRANCH", "body": "This is the body", "title": "This is the title"}'
{
"message": "Validation Failed",
"errors": [
{
"resource": "PullRequest",
"field": "head",
"code": "invalid"
}
],
"documentation_url": "https://docs.github.com/rest/reference/pulls#create-a-pull-request"
}
The current abort_if_fail takes a general message, and most uses were passing along the response.reason, response.status_code, and response.json()['message']. However, without the errors section of the json, it's impossible to know why the request failed. This PR will make it standard to print the entire response within the function. E.g., imagine for this request if we could not see the "errors" - it would be an error akin to #56 that isn't easiily known.
Signed-off-by: vsoch vsochat@stanford.edu