Setting mediaType doesn't work #243
Copy link
Copy link
Closed
Labels
bugSomething isn't workingSomething isn't working
Description
What version of octokit is used in this action? I'm trying to get the contents of a file in a repository with:
github.rest.repos.getContent({
owner,
repo,
path,
mediaType: {
format: "raw+json"
}
});
but it doesn't work. I always get the default response as if mediaType isn't set. Maybe this is not yet supported in the octokit client used in this action?
I looked at the debug information of the request and the headers don't include an Accept header. I expect the Accept header to be set to application/vnd.github.v3.raw+json
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working
Activity
joshmgross commentedon Mar 3, 2022
If you're on the latest version of this action, we're using Octokit 3.5.1
https://github.com/actions/github-script/blob/main/package.json#L39
T3rm1 commentedon Mar 3, 2022
I see, thanks for the response. I figured out what I misunderstood. I thought that setting the media type to
raw+jsonwould be the same as doing the request with the headerAccept; application/vnd.github.v3.raw+json. Apparently that is not the case. The only thing that changes is the data key in the returned json object.Example: https://api.github.com/repos/actions/github-script/contents/README.md
If you open the link in the browser you get json object.
If you open the link in the browser and set the header
Accept; application/vnd.github.v3.rawyou only get the contents of the file.If you use octokit to request the conent with
you get a different json object although the requested url is the same. That's totally confusing and I haven't found anything about this in the octokit documentation.
T3rm1 commentedon Mar 4, 2022
Ok I have to reopen this. I did the above test directly with node and not in the context of the GitHub script action.
This morning I tested it again with this action and it doesn't work, although the mediaType is set. I still get the base64 encoded data as a response.
I also noticed that the User-Agent is set to
actions/github-script. Maybe this is the issue or maybe even more fields are changed by this action so that it won't pass on the mediaType.T3rm1 commentedon Mar 4, 2022
@joshmgross
I set up a reproducible test case here: https://github.com/T3rm1/github-script-bug/runs/5419408653?check_suite_focus=true#step:2:57
As you can see, the content is encoded as base64 although the mediaType format is set to raw. As I don't get this error when I run this with the latest octokit in node directly, I assume this must be a bug of this action.
Can you have a look, please?
avonengel commentedon Apr 27, 2022
I ran into the same issue and was able to work around it like this:
Of course this is suboptimal, but at least it behaves the same as when run directly via node locally, or from within custom JS actions.
starsagar21 commentedon May 25, 2022
bug level is on march 3 not updating
mjpieters commentedon Mar 30, 2023
I've traced this down to how the action handles
getInput()responses for missing settings; it assumes that if you don't set an option, thatcore.getInput()returnsnull. This is incorrect, but the error then leads tomediaTypehandling being broken bymediaType.previewsbeing set to an array with an empty string.You can see this by running the following script:
This outputs:
Note the
-previewstrings in theAcceptheaders there; these are invalid and GitHub then falls back to the default media type for a given endpoint. The correct output would look like:The issue is this line:
github-script/src/main.ts
Line 43 in 98814c5
previews != nullis always true, because at the very least, it'll be the empty string, see the implementation forcore.getInput():Inputs are read from environment variables and when the variable is missing or empty, the empty string is used. Splitting an empty string results in an array with a single empty string.
The work-around is to pop that empty string off the defaults:
I'll create a PR to fix the input handling (it also affects setting the user agent, and the debug flag should really use
core.getBooleanInput()).