Bug: EROFS gh-pages/.cache on yarn-2 - git clone targets .zip file

[Adrian-Grimm]

I'm using yarn2 to deploy a gatsby page to github.
"gh-pages": "^2.2.0"
node_js is on version 13

Command NODE_DEBUG=gh-pages GH_TOKEN=**** yarn deploy gets following output with an error:

success onPostBuild - 0.174s info Done building in 15.140969228 sec GH-PAGES 15514: Cloning https://TEST@github.com/****************.github.io.git into .yarn/cache/gh-pages-npm-2.2.0-7dddbcd165-2.zip/node_modules/gh-pages/.cache/github.com!****************.github.io.git EROFS: read-only filesystem, mkdir '/node_modules/gh-pages/.cache'
He ties to write into the zip file... don't know why...

[Adrian-Grimm]

I think the issue is in this method of gh-pages/lib/index.js:

function getCacheDir() { return path.relative(process.cwd(), path.resolve(__dirname, '../.cache')); }

the cache sould be somewhere else.. __dirname is in case of yarn2 a zip file - read_only.

perfect would be an optional "GitSyncTmpDir" folder param where everything goes for the git operations...

[s5no5t]

I have the same issue, and it is blocking my use of gh-pages in a CI pipeline.

@tschaub what would be a proper solution here? A new cache dir param in options, or a different default cache dir in the current dir, as suggested by @Adrian-Grimm ? Would you be interested in a PR?

[tschaub]

I think it would be preferable to solve this without adding another option.

[s5no5t]

@tschaub would it make sense to set the default cache dir to .gh-pages (in the project folder)?

[Adrian-Grimm]

@jugglingthebits: there is already a pull for my quick fix: #344

Until the official version is fixed you can solve it (hacky) like me: cursorbeat/cursorbeat.github.io@838e6df (.yarn/cache/gh-pages-npm-2.2.0-7dddbcd165-2.zip) - commit the whole modified .zip file and modify the .lock file to the new hash: (checksum: 2/85c5bb5506d1eeade54087d4c90211159533a1291854a9318fdd046e4a8a7a8c26327c7667a31af0c812ffa0d58639ca54c879f7ec062bf1d15ccf02f457ddb8)

After a official patch you can revert this commit.

[Adrian-Grimm]

@jugglingthebits: there is already a pull for my quick fix: #344

Until the official version is fixed you can solve it (hacky) like me: cursorbeat/cursorbeat.github.io@838e6df (.yarn/cache/gh-pages-npm-2.2.0-7dddbcd165-2.zip) - commit the whole modified .zip file and modify the .lock file to the new hash: (checksum: 2/85c5bb5506d1eeade54087d4c90211159533a1291854a9318fdd046e4a8a7a8c26327c7667a31af0c812ffa0d58639ca54c879f7ec062bf1d15ccf02f457ddb8)

After a official patch you can revert this commit.

Updated hack/workaround for V3 comp. with yarn2 (rc34): cursorbeat/cursorbeat.github.io@7119ef8

pull of this is still open: #344

[tschaub]

Thanks for the report on this. It should be fixed in gh-pages@3.1.0. Please open another issue if things still don't work with yarn.