cypress: Cypress should not require write access of root folder

npm install --unsafe-perm solved it for me

FYI this may become a blocker for using Cypress under Angular CLI at some point, when we use a buildtool that creates a readonlyFS for hermeticity during testing

Here is Cypress attempting to gain access to root of a docker image where our install is happening. Please note that this isn’t even us running cypress. The project is simply running it’s normal build process but this time we have added cypress to the project and during a yarn/npm install cypress attempts to access root to make a /.cache/Cypress directory. It seems like an install script that cypress attempts to run regardless of whether it’s CI or not and in our jenkins pipeline it will fail as these are being built on docker images. Our options then are either to disable all scripts which could be detrimental with other dependencies, or to remove Cypress completely from the project… which we would rather not do… just yet…

error An unexpected error occurred: "/tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/node_modules/cypress: Command failed.

Exit code: 1

Command: sh

Arguments: -c node index.js --exec install

Directory: /tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/node_modules/cypress

Output:

Cypress cannot write to the cache directory due to file permissions

----------



Failed to access /.cache/Cypress:



EACCES: permission denied, mkdir '/.cache/Cypress'

----------



Platform: linux (Debian - 8.10)

Cypress Version: 3.0.2".

info If you think this is a bug, please open a bug report with the information provided in "/tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/yarn-error.log".

info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

error An unexpected error occurred: "Command failed.

Exit code: 1

Command: sh

Arguments: -c yarn install --frozen-lockfile

Directory: /tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2

Output:

".

info If you think this is a bug, please open a bug report with the information provided in "/tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/yarn-error.log".

info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

error An unexpected error occurred: "Command failed.

Exit code: 1

Command: sh

Arguments: -c yarn log:sha && yarn i

Directory: /tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2

Output:

".

info If you think this is a bug, please open a bug report with the information provided in "/tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/yarn-error.log".

info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

script returned exit code 1```

Any update on this? Would be great for the check to be removed for the read only FS use case. And Videos/Screenshots will be written into a custom writable location.

I am currently experiencing the same issue while running it on Bitrise. Is there an expected timeline as to when this will get completed? If there is a working solution already I’d love to take a look at it.

Because we seed the project with cypress.json and the cypress folder and example spec code, and plugins, and fixtures, etc.

Could we get some movement here? It’s a pretty easy code change from the looks of it.

@brian-mann So if we disabled video / screenshot generation. And you disable the hard coded write access check (replace with warning) Then there shouldn’t be anything stopped us from using Cypress in a containerized read only FS, correct?

Here’s Angular’s use case: for performance, we are rolling out a remote execution system where a farm of machines can run build/test actions. When a test runs remotely, we copy over the declared inputs, run the test executor, then collect the outputs written to specified locations back to your machine. The remote execution uses a containerized FS where we prevent writes to the project directory, as these would be lost and not copied back to your machine.

I would like to run Cypress on such a remote build/test farm, which requires that we be able to configure the locations where it writes files, and it shouldn’t check for write access in other locations.

I assume that stdout is used for the primary pass/fail UI. I’d like to configure a directory where those additional files are written.

On Sat, Jul 7, 2018, 11:04 AM Brian Mann notifications@github.com wrote:

@alexeagle https://github.com/alexeagle can you explain how if you want to disable write access to the project - Cypress would be able to generate any assets from the run? Things like logs, screenshots, videos, etc?

Can you suggest to us what you’d like Cypress to do instead?

Currently you can turn off taking screenshots and video in the configuration. Although we do have a hardcoded check to ensure the project root has write access. We can remove that check (or turn it into a warning) if need be. But I still don’t understand how this really achieves anything considering you won’t be able to capture anything from the test runs.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/cypress-io/cypress/issues/1281#issuecomment-403233375, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC5Iyk2aeqdeEegx3ZQFLWxHdGVNc8Uks5uEPg3gaJpZM4R-hlS .

@brian-mann Right. We’re using this in Docker and common practice is to run the app as non-root. This means that we’d have to give the user access to write to the root of the app which is unnecessary since our app already has cypress.json and cypress/. Just giving you more context.

That said, seeding the project happens once and probably locally, right? Is this check really necessary?

The code for this is done in cypress-io/cypress#7126, but has yet to be released. We’ll update this issue and reference the changelog when it’s released.

@bahmutov this happens beffore the (Run Starting) message

npx cypress run -s .cypress/integration/meteor_spec.js 
Warning: We failed to trash the existing run results.

This error will not alter the exit code.

Error: EACCES: permission denied, mkdir '/.Trash-1002'



====================================================================================================

  (Run Starting)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Cypress:    3.0.3                                                                              │
  │ Browser:    Electron 59 (headless)                                                             │
  │ Specs:      1 found (meteor_spec.js)                                                           │
  │ Searched:   .cypress/integration/meteor_spec.js                                                │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘

Whats the resolution here? Are we getting the FS check removed? (or replaced with a warning)

@brian-mann ty for the tip about the advanced installation. Adding an env var for caching the binary pointed somewhere within the working directory path helped.

For anyone else with a similar error to the one I mentioned, using CYPRESS_CACHE_FOLDER as referenced in https://on.cypress.io/installing-cypress#Overriding-the-Binary-Cache-Folder might help.

@Bhavik-P to get on the same page I think we need to define terms a bit better.

You say: root access to apps but this makes no sense to me. Cypress does not require root access - it requires write access to the project’s root directory. This is simply the folder that contains cypress.json. It would be the same folder that’s created with the git clone command.

We only write inside of that project folder. This is the same level of access that any node_module would need when running npm install.

In fact… how does your project ever run npm install? That needs the same level of write access as Cypress does to node_modules.

Yes. And this is why when the official Docker image set the user to a non-root user, many people were simply unable to work with it because of permission denied errors. See https://github.com/cypress-io/cypress-docker-images/issues/10. The solution then was just to use root and let user’s do whatever they want on their own images.

Just wanted to check with you guys if you’re aware of this use case and the implications of this part of the code to that use case.

That said, I think my work is done. I’m not sure if I should keep this open or not. 🤔