Deployment fails if the branchname contains special characters

[oliverosz]

Steps to reproduce:

1. Create a new repository containing a static HTML file
2. Add static.yml starter workflow with the branch rules removed
3. Remove the branch protection rules from github-pages environment in repository settings
4. Push a branch with a name containing non-ASCII characters (eg.: büg)

The action fails with a similar error message given in #158, without indication about the source of the problem:

Error: Creating Pages deployment failed
Error: HttpError: invalid json response body at https://api.github.com/repos/oliverosz/gh-pages-test/pages/deployments reason: Unexpected end of JSON input
    at /home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/node_modules/@octokit/request/dist-node/index.js:108:1
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at createPagesDeployment (/home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/src/internal/api-client.js:116:1)
    at Deployment.create (/home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/src/internal/deployment.js:58:1)
    at main (/home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/src/index.js:30:1)
Error: TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'TLSSocket'
    |     property '_httpMessage' -> object with constructor 'ClientRequest'
    --- property 'socket' closes the circle

[saxbophone]

I am also experiencing this with branch name aͫseͭr:

Run actions/deploy-pages@v2
Artifact exchange URL: https://pipelines.actions.githubusercontent.com/QRhO5Qwi44yJZSzU4Bzf4CeJcvefDq[9](https://github.com/saxbophone/project-macktentooger/actions/runs/5257905240/jobs/9501415676#step:2:10)VAjmHkx8rwQZJ3Z5Lk3/_apis/pipelines/workflows/5257905240/artifacts?api-version=6.0-preview
Creating Pages deployment with payload:
{
	"artifact_url": "https://pipelines.actions.githubusercontent.com/QRhO5Qwi44yJZSzU4Bzf4CeJcvefDq9VAjmHkx8rwQZJ3Z5Lk3/_apis/pipelines/1/runs/2/artifacts?artifactName=github-pages&%24expand=SignedContent",
	"pages_build_version": "7d122e257d8f168a151aae015716d3e44ac1fbbf",
	"oidc_token": "***"
}
Error: Creating Pages deployment failed
Error: HttpError: invalid json response body at https://api.github.com/repos/saxbophone/project-macktentooger/pages/deployments reason: Unexpected end of JSON input
    at /home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/node_modules/@octokit/request/dist-node/index.js:[10](https://github.com/saxbophone/project-macktentooger/actions/runs/5257905240/jobs/9501415676#step:2:11)8:1
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at createPagesDeployment (/home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/src/internal/api-client.js:[12](https://github.com/saxbophone/project-macktentooger/actions/runs/5257905240/jobs/9501415676#step:2:13)6:1)
    at Deployment.create (/home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/src/internal/deployment.js:79:1)
    at main (/home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/src/index.js:30:1)
Error: TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'TLSSocket'
    |     property '_httpMessage' -> object with constructor 'ClientRequest'
    --- property 'socket' closes the circle

[JamesMGreene]

The action fails with a similar error message given in #158, without indication about the source of the problem

The core error message is Error: HttpError: invalid json response body, so it sounds like something isn't getting properly serialized on the REST API side. We'll have to investigate further. 🔍

I've addressed the subsequent [but unrelated] circular structure TypeError in #197. 🧹

[saisonxiang]

I run into a similar issue now with my account. The main branch is ⊂(◉‿◉)つ and it worked fine for about 6 months but all of a sudden I can't modify anything on the pages website without it failing. I get an error that says Error: HttpError: invalid json response body at https://api.github.com/repos/pages/deployments reason: Unexpected end of JSON input

[eduramirezh]

Same here, GHES 3.9.1

[saisonxiang]

Same here, GHES 3.9.1

I figured it out with a rep from github support. I got rid of all the special characters (in the branch names and also in the names of the files) and the error resolved.

[eduramirezh]

thanks @saisonxiang! I'm not able to find any special chars, though. Did you use any commands or tools to find them? could they be also part of the contents of the files, or just file names and branches?

[saisonxiang]

thanks @saisonxiang! I'm not able to find any special chars, though. Did you use any commands or tools to find them? could they be also part of the contents of the files, or just file names and branches?

I was foolish and named everything with emoji. If you didn't specifically name a branch or a file with an abnormal character they wouldn't be hiding in your files. Just make sure your files and branches have all alphabetical/numerical names and you should have dodged that problem set. You may have another issue.

[gdw2]

I'm seeing this issue on GHE 3.8, but I have no unusual branch names or filenames that I know of. Is there anyway I can see the response coming from the github api that is malformed? That might give me insight into what is wrong.

[gdw2]

I updated src/index.js to output the "error.response" and it's undefined with a status of 500.

[eduramirezh]

My company ran into other issues as well after upgrading to 3.9.1, so I'm guessing in my case it's related to that

[MattSnow-amd]

We started seeing this issue about a week ago without any upgrades or changes. GHES 3.8.9.

[noraj]

I think my issue #236 is may be due to the branch name being maîtresse.

[JamesMGreene]

Just for assurance: we've filed an internal bug to investigate this one further. In the meanwhile, please try to avoid branch names with non-ASCII characters as a temporary workaround.

Thank you for the report and patience! 🙇

[2m]

I am also getting Unexpected end of JSON input error, but I started getting it because of a different reason.

The deployment was working fine for a couple of months. However yesterday I was mucking about in the repository settings and switched "Source" under "Build and deployment" to "Deploy from a branch" and then back to "GitHub Actions".

After this deployment started failing with:

Creating Pages deployment with payload:
{
	"artifact_url": "https://pipelinesghubeus9.actions.githubusercontent.com/SlI0u2ZU2hyLE2M9QqGJQD0ZQy5w4xsmfJdtsJIPd245izVRkd/_apis/pipelines/1/runs/974/artifacts?artifactName=github-pages&%24expand=SignedContent",
	"pages_build_version": "0ce45d3bb5d7abce7ec4286a707b180ff1ef796f",
	"oidc_token": "***"
}
Error: Creating Pages deployment failed
Error: HttpError: invalid json response body at https://api.github.com/repos/2m/rallyeye/pages/deployments reason: Unexpected end of JSON input
    at /home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/node_modules/@octokit/request/dist-node/index.js:108:1
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at createPagesDeployment (/home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/src/internal/api-client.js:126:1)
    at Deployment.create (/home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/src/internal/deployment.js:80:1)
    at main (/home/runner/work/_actions/actions/deploy-pages/v2/webpack:/deploy-pages/src/index.js:30:1)
Error: HttpError: invalid json response body at https://api.github.com/repos/2m/rallyeye/pages/deployments reason: Unexpected end of JSON input

Failed job output: https://github.com/2m/rallyeye/actions/runs/6983378084/job/19014225515

I tried switching "Source" a couple of times again, but the error persists.

[MattSnow-amd]

We started seeing this issue about a week ago without any upgrades or changes. GHES 3.8.9.

For Everyone's Information - I double the RAM and increased CPU cores on the appliance VMs during downtime and this issue stopped happening.
I suspect that either a magical reboot resolves a bug, or there is memory pressure issue with one of the backend services that handles this API endpoint.

[saxbophone]

We started seeing this issue about a week ago without any upgrades or changes. GHES 3.8.9.

For Everyone's Information - I double the RAM and increased CPU cores on the appliance VMs during downtime and this issue stopped happening. I suspect that either a magical reboot resolves a bug, or there is memory pressure issue with one of the backend services that handles this API endpoint.

Can you confirm whether this workaround addresses the issue even when the branch name has non-ASCII characters in it, such as mÿ-§uper-ünicode-brånch-næme ?

[MattSnow-amd]

We started seeing this issue about a week ago without any upgrades or changes. GHES 3.8.9.

For Everyone's Information - I double the RAM and increased CPU cores on the appliance VMs during downtime and this issue stopped happening. I suspect that either a magical reboot resolves a bug, or there is memory pressure issue with one of the backend services that handles this API endpoint.

Can you confirm whether this workaround addresses the issue even when the branch name has non-ASCII characters in it, such as mÿ-§uper-ünicode-brånch-næme ?

Yes I can confirm the issue does not happen on branches with non-ASCII characters. I used the exact string you provided in the simple test repo we used to isolate and reproduce the issue.

[Okeanos]

We started seeing this issue about a week ago without any upgrades or changes. GHES 3.8.9.

For Everyone's Information - I double the RAM and increased CPU cores on the appliance VMs during downtime and this issue stopped happening. I suspect that either a magical reboot resolves a bug, or there is memory pressure issue with one of the backend services that handles this API endpoint.

I/we experience the issue on GHES as well … not sure I like the idea of throwing resources at the problem (not that I could) or that a reboot fixes it (I can't do anything about that either) because who is to say it wouldn't happen again 2 days later?

A proper investigation or document on how to debug the issue and find the individual root cause and get that fixed would be much more helpful to me.