Run Cypress Headless Without Binary

[arahansen]

Current behavior:

npm install cypress downloads the cypress app binary

Desired behavior:

npm install cypress (or something like npm install @cypress/headless) does not install a binary, and only installs necessary dependencies for running tests headlessly on CI.

Additional Info (images, stack traces, etc)

Our CI configuration is pretty strict about what can be externally downloaded. It would be great if cypress could be run without needing to whitelist the cypress domain.

• Operating System: Linux centos
• Cypress Version: 1.4.1
• Browser Version: Chrome 63

[brian-mann]

This is something we've internally talked a lot about and I have a lot of notes for. It is possible to do this - you wouldn't be able to run Electron, but you would be able to spawn an external browser.

The problem comes in where you have conflicting packages. You'd likely check in cypress already for local development and wouldn't want that to npm install in CI, and you also wouldn't want to check in a separate packaged like @cypress/headless.

For this to work I think we'd just need to set an env var like: CYPRESS_INSTALL_BINARY=0 which avoids installing the binary and the CLI would have to be upgraded to run in your node environment as opposed to always expecting the binary to exist. This would then run Cypress in your node environment (which is another can of worms) but it would work.

EDIT: another advantage of this is that if we supported Chrome headless (which we will), this avoids the need to orchestrate or have xvfb installed - since Electron would not need spawning locally. This creates a bit of combinatory explosion since it would require a lot of explaining and documentation, but that's another upside to this method.

[hehex9]

any progress ？

[lgandecki]

This would help putting cypress on aws lambda for amazingly quick parallel testing.

[surf66]

@lgandecki been trying to get Cypress working on AWS Lambda for a day only to come across this GitHub issue!

Anyone got an update?

[lsnape]

Also keen to run Cypress tests on AWS Lambda, although I don't see how installing the binary precludes the tests from running?

[lgandecki]

I don't fully remember. I think the "headful" chrome makes it so the whole thing doesn't fit in the lambda limit of 50 mb? So you have to download and install chrome which makes it slow and expensive (long running?)

[lsnape]

FWIW you can skirt around the 50mb limit by uploading the Lambda package as a zip to S3 first: https://hackernoon.com/exploring-the-aws-lambda-deployment-limits-9a8384b0bec3

If that is the issue then my feeling is 250mb should be enough? But if it takes a while to boot up then yeah that is an issue.

[StevenACoffman]

We are using puppeteer inside an AWS lambda and would like an equivalent cypress setup if someone has worked this out.

[JesterXL]

I tried to manually do this, but your Linux Cypress package is around 499 megs and the AWS Lambda S3 limit is 250 megs. I'd prefer to use Cypress vs. Puppeteer for Lambda, is there a way to get a smaller Linux binary?

[JesterXL]

I put the Linux version on S3, then copied and unzipped in the Lambda. It ran out of RAM. So I pumped the Lambda's RAM up to 3008 megs. It used 1908, but then ran out of hard drive space on the EC2 (Raspberry PI?) used for the Lambda. I TRIED lol

[leonfs]

It's possible to run Cypress in Lambda, look in this link: https://stuartsandine.com/cypress-on-aws-lambda-part-1/

There is a github repo too.

[ZebraFlesh]

While that post is technically interesting, the solution relies on Chromium 59 via Electron (if I'm reading it correctly). That's not super helpful if you want to test more recent features without using polyfills, such as ResizeObserver which landed in Chrome 64 in Jan. 2018.

[WinstonN]

Hello, I am reviving this issue <3

Since the launch of cypress 3.8.0 we now have the ability to run cypress --headless - which is really cool

I've been trying to run cypress in a lambda function, and I have a few questions, which I am hoping someone here could help me with

At first I thought I would be clever, and check in my node_modules into source control, then bring this into a lambda and execute cypress from there, but it didn't work out that well because I got this output, which I didn't expect

Cypress package version: 3.8.0
Cypress binary version: not installed

The cypress binary was a curious one, and I started digging deeper from there

I saw that Cypress saves this binary, in the user's cache directory - as below (taken from a ubuntu 18.04 virtualbox install)

I then tried to bring Cypress into my lambda function via a lambda layer (https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) but I quickly ran into size issues

  Serverless Error ---------------------------------------

  An error occurred: RunLambdaFunction - Function code combined with layers exceeds the maximum allowed size of 262144000 bytes. The actual size is 274082977 bytes. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: aaa9ecec-2cbf-43b8-837e-777).

This got me onto looking at the size of Cypress, in it's entirety

Below are the sizes of directories, in the home directory cache folder for Cypress, that are 1MB and bigger

404MB is taken up by resources/app/packages/ of which 257MB is server node_modules

and below is the same stats from the node_modules folder

which means that pretty much the entire Cypress size comes from

cypress binary 111MB resources/app/packages 404MB

My questions are

1. If I don't want to record tests, or use the graphical UI of cypress at all, what can I remove from these folders to bring the size down? Is that even possible?
2. Inline with the question above, how do I "build" cypress after removing these? Is there some contributors documentation that will help me answer the technical bits
3. I can already run chrome headless in lambda, and looking at this documentation (https://docs.cypress.io/guides/guides/launching-browsers.html#Customize-available-browsers) it should be possible to setup/add new browsers, and specify their paths. My question is, how do I run cypress with these browsers in the command line? That documentation only cover the graphical bit

And in closing, I just want to say, wow man, wow! You've built something so amazing an pretty and functional here, and I am so blown away by the quality of it all

Thank you for every little bit of effort you put into cypress because it's really such a wonderful product

[kyler-hyuna]

Guessing there's no update on this?

[WinstonN]

Not yet I'm afraid. Anyone want to join me on this? I hit a wall with the needed libs

[kyler-hyuna]

How feasible is the layer option? Here's a git-lambda layer that allows using the git binary in lambdas https://github.com/lambci/git-lambda-layer. It builds it using bash scripts

[WinstonN]

With the layer option, as you'll see above, I have still run into size issues for cypress size The other issue will be missing libraries that cypress needs

[kyler-hyuna]

While doing some other options, I had some success with puppeteer via https://github.com/alixaxel/chrome-aws-lambda.

They use this lambda layer for the browser https://github.com/shelfio/chrome-aws-lambda-layer. Maybe the cypress team can look into integration with this browser?

[cortopy]

I went a bit further than @WinstonN and tried to pack the big runtime with success by doing:

• Download runtime as zip
• create a tarball
• Create a layer with the tarball
• Attach the layer to lambda and untar within the lambda

I got really excited because all this is within the limits of Lambda. The function runs!!

However, there is a problem in that cypress expects in addition to the runtime to also have Xvfb as a dependency.

So it's not just about the size of the runtime, it's the fact that cypress requires Electron and a graphical environment. The article already quoted in this issue is very relevant to this

[MeStrak]

@cortopy were you able to get Xvfb installed? I was following the same article you referenced, but since it was written AWS changed the runtime in node.js lambdas to AWS Linux 2 and a lot of the dependencies don't work.

[tomasbjerre]

I created a tool to package cypress binaries in an npm-package. So that one can publish it to a private npm registry and use it in applications.

See comment in https://github.com/cypress-io/cypress/issues/5141#issuecomment-622774084in

[cortopy]

@MeStrak I'm afraid not. I didn't want to go down the route, as the documentation on the Lambda environment is sparse and, as you've experienced, may change

[WinstonN]

I've been looking at this https://github.com/grycap/scar - but getting an error when I try to run cypress docker in a lambda, tbh I think that is the only way we will achieve this. Even though I did not document it in my comments on this issue, I also ran in to library issues, and the libraries between the blog post out there, and later versions differ greatly - to the point where the original article is no longer helpful Will give it another shot at some point when I have time

[MeStrak]

@WinstonN This would be amazing, I had looked for something like this but didn't come across this project.

Let me know if I can help. I'm still hacking away with the stuartsandine approach which worked in node8.10 Amazon Linux 1. The linked articles are very useful for finding the needed dependencies.

[WinstonN]

@MeStrak I would love to connect with you and maybe between us we can make this work? I think we can do it using scar (https://github.com/grycap/scar) if you want, you can find me on LinkedIn, and connect with me there. We can then exchange contact details, and perhaps, if you want, we can setup a google hangout and exchange notes?

[MeStrak]

@WinstonN Deal!

[dandobrescu]

I'd like to help. Ping me if you create a communication channel

[WinstonN]

I'd like to help. Ping me if you create a communication channel

@dandobrescu connect with me on LI (Winston Nolan) I'll loop you in 👍

[WinstonN]

hey hey, a quick update from me

I've managed to run docker in lambda, using scar, which I think will take care of the dependencies issues

With that out of the way, I started looking at building a small cypress docker, that only need to run cli - I am still busy with this I was looking at cypress/base:12 and what docker build --squash could bring to the table - but I must be doing something horribly wrong because

cypress-lambda/cypress-4.5.0-squash   latest              bd26ff4e9cb1        44 hours ago        1.04GB
cypress-lambda/cypress-4.5.0          latest              9332fe0b4f0e        3 days ago          1.03GB

LOL :P

Looking into the size issue of cypress I looked at the node folder, and using node-prune I could get the size down from

1.1G    ./node_modules_before
987M    ./node_modules_after

Looking at where the size comes from in node_modules I see

278M    ./node_modules_after/puppeteer
277M    ./node_modules_after/percy
102M    ./node_modules_after/app-builder-bin
 49M    ./node_modules_after/typescript
 22M    ./node_modules_after/aws-sdk
 12M    ./node_modules_after/babel-core
 11M    ./node_modules_after/rxjs
10.0M   ./node_modules_after/nuclide-format-js
8.9M    ./node_modules_after/sinon
8.5M    ./node_modules_after/7zip-bin
7.2M    ./node_modules_after/core-js
6.8M    ./node_modules_after/@babel
5.6M    ./node_modules_after/@cypress
4.8M    ./node_modules_after/moment
4.8M    ./node_modules_after/lodash
4.8M    ./node_modules_after/jsdom
4.8M    ./node_modules_after/eslint
4.1M    ./node_modules_after/rx
3.8M    ./node_modules_after/@lerna
3.4M    ./node_modules_after/execa-wrap
3.4M    ./node_modules_after/@octokit
3.3M    ./node_modules_after/decaffeinate
3.2M    ./node_modules_after/percy-client
3.2M    ./node_modules_after/flow-parser
3.2M    ./node_modules_after/app-builder-lib
3.1M    ./node_modules_after/eslint-plugin-mocha
3.1M    ./node_modules_after/caniuse-lite
3.0M    ./node_modules_after/snap-shot-it
3.0M    ./node_modules_after/snap-shot-core
2.9M    ./node_modules_after/expect
2.8M    ./node_modules_after/handlebars
2.7M    ./node_modules_after/es-abstract
2.6M    ./node_modules_after/lodash-es
2.6M    ./node_modules_after/date-fns
2.4M    ./node_modules_after/@fellow
2.2M    ./node_modules_after/@typescript-eslint
2.1M    ./node_modules_after/mout
2.1M    ./node_modules_after/babel-plugin-proto-to-assign
2.0M    ./node_modules_after/detective
1.9M    ./node_modules_after/gulp-coffee
1.8M    ./node_modules_after/regenerate-unicode-properties
1.8M    ./node_modules_after/es5-ext
1.8M    ./node_modules_after/decaffeinate-parser
1.7M    ./node_modules_after/node-gyp
1.6M    ./node_modules_after/regexpu
1.6M    ./node_modules_after/ramda
1.5M    ./node_modules_after/commoner
1.4M    ./node_modules_after/regenerator
1.3M    ./node_modules_after/react-test-renderer
1.3M    ./node_modules_after/node-notifier
1.2M    ./node_modules_after/js-codemod
1.2M    ./node_modules_after/@jest
1.1M    ./node_modules_after/mocha
1.1M    ./node_modules_after/babel-register
1.0M    ./node_modules_after/acorn-globals
1.0M    ./node_modules_after/acorn

This caused me to open up this issue: https://github.com/cypress-io/cypress/issues/7377 For example, I am not sure what role puppeteer, and percy plays in the cypress eco system

278M    ./node_modules_after/puppeteer
277M    ./node_modules_after/percy

Even with that out of the way, we still have a massive size on the binary

❯❯❯ du -h -d 3 ~/Library/Caches/Cypress/4.5.0
 14M    /Users/WinstonN/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/_CodeSignature
204K    /Users/WinstonN/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/MacOS
385M    /Users/WinstonN/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Resources
158M    /Users/WinstonN/Library/Caches/Cypress/4.5.0/Cypress.app/Contents/Frameworks
557M    /Users/WinstonN/Library/Caches/Cypress/4.5.0/Cypress.app/Contents
557M    /Users/WinstonN/Library/Caches/Cypress/4.5.0/Cypress.app
557M    /Users/WinstonN/Library/Caches/Cypress/4.5.0

I'll continue to chip away at this but let me know what you could find out?

[MeStrak]

I think this issue is very relevant, it could remove the Xvfb dependency meaning that maybe a docker wouldn't be required as we could use Chromium headless.

Marked as ready for work it year ago but with no news since.

https://github.com/cypress-io/cypress/issues/3899

[dandobrescu]

@WinstonN , if you run npm run binary-build -- --platform linux --version 3.5.0 (whatever version) from the root of the project (and get it to run successfully, you'll probably have some missing deps) you'll see that the yarn installs are being ran with --production successfully in all the packages. Just follow the package.json and the sequential places where this is defined. I'm not getting the percy (puppeteer is it's dependency) installed because it's specified as a devDependency in the core package. I might be wrong, I only got to this point a couple of hours yersterday, so double check the info.

I'm trying to strip out parts of the project for the sake of the proof of concept in trying to build something without electron and the gui modules and i'm having troubles understanding where is what compiled into the bytecode that is the ~/.cache/Cypress/version/Cypress/Cypress binary. I'm definitely missing something, but I couldn't see the past the coffee build flows which don't seem to contain anything about a compiler nor how the stuff in the packages relates to the binary. I'll continue looking into it, but if you can point me to more info in this direction it would be great.

I think this issue is very relevant, it could remove the Xvfb dependency meaning that maybe a docker wouldn't be required as we could use Chromium headless.

@MeStrak Yep, it's not sustainable to chop the project on every release to get what you need and even if AWS decides to increase the size limits this doesn't mean that the Cypress project isn't also going to grow even more. I'm also don't think it's in Cypress' interest in pursuing such thing since this is not a problem for the solution their offering. Still, it's also related to their maintainability so perhaps as it grows they're going to find it important.

[WinstonN]

I have made some progress, but I get some error still

/tmp/lib/Cypress: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory

I have copied this lib, and it is in the right place

./lib/libelf.so.1
./lib64/libelf.so.1

These libs and others, that have been gathered through ldd and have been placed in ./lib and ./lib64 are the right file, and if I stat them, they are files and not symlinks

I have this set in the env of lambda

LD_LIBRARY_PATH:
   '/tmp/lib64:/tmp/lib:/var/task/lib64:/var/task/lib:/var/lang/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib:/opt/lib',

My question is. I am sure these libs exist. And they are correct. Why is cypress not picking them up? Is this a cypress issue, or a lambda issue?

[WinstonN]

I'm still stuck on this issue

/tmp/lib/Cypress: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory

I gather the libraries cypress needs like this

# lib
ldd /root/.cache/Cypress/4.7.0/Cypress/Cypress | awk '{ print $3 }' | grep '\/lib\/' \
  | xargs -I{} cp -R -L {} ./lib/
#lib64
ldd /root/.cache/Cypress/4.7.0/Cypress/Cypress | awk '{ print $3 }' | grep '\/lib64\/' \
  | xargs -I{} cp -R -L {} ./lib64/

I verify the above by checking the file in the folders that will be transferred to the lambda function

# check libelf.so.1 exists in ./lib64 (will be transferred to lambda)
bash-4.2# ls -lah ./lib64/ | grep libelf.so.1
-rwxr-xr-x 1 root root  98K May 29 09:46 libelf.so.1
# check libelf.so.1 exists in /lib64 (just to compare size)
bash-4.2# ls -lah /lib64/libelf-0.176.so
-rwxr-xr-x 1 root root 98K Aug 14  2019 /lib64/libelf-0.176.so
# check libelf.so.1 exists in /usr/lib64 (just to compare size)
bash-4.2# ls -lah /usr/lib64/libelf-0.176.so
-rwxr-xr-x 1 root root 98K Aug 14  2019 /usr/lib64/libelf-0.176.so

I set the LD_LIBRARY_PATH (notice I even moved around /tmp/lib and /tmp/lib64)

LD_LIBRARY_PATH:
   '/tmp/lib64:/tmp/lib:/var/task/lib64:/var/task/lib:/var/lang/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib:/opt/lib',

Yet I still get that error Is there a way to see in which location cypress is looking for this lib?

I am running cypress with DEBUG on

cypress
      .run({
        spec: event.cypressSpec || '/tmp/cypress/integration/**/*.spec.js',
        env: {
          DEBUG: "cypress:*",
          XDG_CONFIG_HOME: "/tmp"
        },
        config: {
          video: false
        },
        record: false,
        project: "/tmp",
        reporter: 'mochawesome',
        headless: true
      })
      .then(results => {
        const report = fs.readFileSync('/tmp/mochawesome-report/mochawesome.json').toString()
        done(null, report);
      })
      .catch(err => {
        done(err);
      });

cc @jennifer-shehane

[MeStrak]

@WinstonN I'm not sure if it's related or not, but in Stuart Sandine's article there's something about hard linking some libraries the Cypress (Electron) needs: https://stuartsandine.com/cypress-on-aws-lambda-part-1/

Search for link.sh on that page and you'll find the section I'm referring to.

[WinstonN]

Game changer! https://docs.aws.amazon.com/lambda/latest/dg/configuration-filesystem.html

[dandobrescu]

Game changer! https://docs.aws.amazon.com/lambda/latest/dg/configuration-filesystem.html

I've tried a first round of tests but i'm blocked at Could not start Xvfb,for the n-th time but this time without any other error message. Anyway, i guess i should cleanup what i have and try to sync/align to make it work :D . I'm a bit worried about the start-up time, but i guess we'll see when we get there.

[idosal]

@WinstonN @dandobrescu Now that we can throw the Cypress binary into EFS, have you had any luck with solving the dependency issue? Any pointers would be a huge help.

[dandobrescu]

In theory i don't think the dependency chain is an issue but i couldn't get a hold of @WinstonN in a while, since i got stuck myself into one - can't "find" libelf.so.1 when starting cypress in EFS . I'm saying in theory because most probably with some proper dependency management like i've seen here https://stuartsandine.com/cypress-on-aws-lambda-part-1/ or in Winston's repo, running Cypress may be already achievable at the cost of running more expensive builds. I'm also thinking that this is already achievable because he closed the dependency question as not being needed anymore https://github.com/cypress-io/cypress/issues/7377 :D

[idosal]

@dandobrescu Thanks for the prompt reply. I started playing with @WinstonN 's fork and managed to get past the libelf.so.1 problem after setting LD_LIBRARY_PATH. However, I'm now stumped by this error:

Verifying Cypress can run /tmp/lib [started]
2020-07-07T11:36:09.657Z    d92439d1-bdbf-14e8-cd39-75ee227ab85e    INFO    [11:36:09]  Verifying Cypress can run /tmp/lib [failed]
2020-07-07T11:36:09.658Z    d92439d1-bdbf-14e8-cd39-75ee227ab85e    INFO    [11:36:09] → Cypress failed to start.

This is usually caused by a missing library or dependency.

The error below should indicate which dependency is missing.

https://on.cypress.io/required-dependencies

If you are using Docker, we provide containers with all required dependencies installed.

----------

Fontconfig error: Cannot load default config file: No such file: (null)

(Cypress:42): GdkPixbuf-WARNING **: 11:35:53.006: Cannot open pixbuf loader module file '/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
[42:0707/113553.676142:ERROR:bus.cc(393)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
[42:0707/113553.677762:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
Fontconfig error: Cannot load default config file: No such file: (null)
[64:0707/113553.718610:ERROR:gl_surface_glx.cc(453)] glxQueryVersion failed
[64:0707/113553.718688:ERROR:gl_initializer_x11.cc(148)] GLSurfaceGLX::InitializeOneOff failed.
[64:0707/113553.719193:ERROR:broker_posix.cc(43)] Invalid node channel message

(Cypress:53): GdkPixbuf-WARNING **: 11:35:53.728: Cannot open pixbuf loader module file '/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
[53:0707/113554.562223:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[53:0707/113554.569634:ERROR:bus.cc(393)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
[220:0707/113554.614658:ERROR:broker_posix.cc(43)] Invalid node channel message
[64:0707/113608.720952:INFO:child_thread_impl.cc(831)] ChildThreadImpl::EnsureConnected()
[220:0707/113609.630542:INFO:child_thread_impl.cc(831)] ChildThreadImpl::EnsureConnected()

----------

Platform: linux (Amazon Linux - 2 (Karoo))
Cypress Version: 4.9.0

I haven't found any complaints about pixbuf anywhere else. Any ideas? Obviously, if Winston managed to pull it off his input would solve all of our problems. :)

[MeStrak]

@idosal pixbuf is one of the binaries mentioned in Stuart Sandine's article where he creates a hard link for a few files using link.sh.

(See my comment earlier in this thread).

Could it be related?

[MeStrak]

In theory i don't think the dependency chain is an issue but i couldn't get a hold of @WinstonN in a while, since i got stuck myself into one - can't "find" libelf.so.1 when starting cypress in EFS . I'm saying in theory because most probably with some proper dependency management like i've seen here https://stuartsandine.com/cypress-on-aws-lambda-part-1/ or in Winston's repo, running Cypress may be already achievable at the cost of running more expensive builds. I'm also thinking that this is already achievable because he closed the dependency question as not being needed anymore #7377 :D

Does this mean that the workaround to patch Xvfb for xkbcomp worked for you? For some reason I couldn't get it to work at all, though it worked for me on the earlier version of AWS Linux.

[idosal]

@idosal pixbuf is one of the binaries mentioned in Stuart Sandine's article where he creates a hard link for a few files using link.sh.

(See my comment earlier in this thread).

Could it be related?

I tried linking the files he mentioned. It didn't solve the issue.

[craig-dae]

Has anyone made any progress on this? Our devops lead wants to put cypress in a lambda. I've been trying to get us to use cypress instead of selenium, but we were able to put selenium in a lambda.

Any help to get cypress running in a lambda would be appreciated. We are struggling with getting the correct linux packages into the lambda in order to run cypress.

Edit: Going to get my guy who's currently working on this to chime in in a second ...

[AndyDinh]

Has anyone made any progress on this? Our devops lead wants to put cypress in a lambda. I've been trying to get us to use cypress instead of selenium, but we were able to put selenium in a lambda.

Any help to get cypress running in a lambda would be appreciated. We are struggling with getting the correct linux packages into the lambda in order to run cypress.

Edit: Going to get my guy who's currently working on this to chime in in a second ...

So to follow up on this, I've currently been working inside of a local docker container that emulates a node12.x environment for lambda, as provided by AWS.

While I've made some progress on this, one of the biggest hang-ups currently happens to be with certain shared lib. files that the Cypress environment is looking for which I cannot seem to install/find. I was able to extract other library files from some of the github repos I have come across and copied them into place under ~/.cache/Cypress/4.10.0/Cypress to run, but there are still a few shared lib. files that I am struggling with.

Shown below, I am listing the files in place under the mentioned path inside the container and run ldd ~/.cache/Cypress/4.10.0/Cypress/Cypress | grep "not found" to retrieve the missing dynamic dependencies.

Initially setting this up, there was an attempt to retrieve all of the RPMs and their dependencies inside an external CentOS environment with the use of repoquery -R --resolve --recursive $CYPRESS_DEP | xargs -r yumdownloader --destdir=/path/to/folder and replaced export CYPRESS_DEP=<cypress-dep> for each Cypress system dependency listed (xorg-x11-server-Xvfb, gtk2-devel, gtk3-devel, libnotify-devel, GConf2, nss, libXScrnSaver, alsa-lib)

After all of these dependencies were retrieved and sent up to Docker, using a script to run rpm -ivh --nodeps <RPM-Packages>.rpm for all of the packages, it ran pretty smoothly with minor errors that did not prevent continuation of the Cypress processes from running. The minor errors returned with: Fontconfig warning: "/etc/fonts/fonts.conf", line 86: unknown element "blank", and with a few google searches, figured out the fix.

That being said, the latter solution was entirely too large and would never fit inside an AWS Lambda or as a Lambda Layer (over 1GB in RPM packages). If anyone can make further progress/has made further progress and has a solution for this, any help/resources would be greatly appreciated.

NOTE: We are trying to run Cypress as a replacement to Selenium in AWS Lambda as Cypress is a much better framework in our situation but either of these frameworks must be run in Lambda due to customer needs.

[WinstonN]

:) here we all are! still struggling to get our favourite testing software to run in lambda :)

Apologies for being Missing In Action, I was swamped at work :(

In short, I gave up on the trying to do this in Amazon linux 2 (which is what lambda runs), the reasons are

1. I don't think it can be done due to missing dependencies, and probably electron too, see https://github.com/cypress-io/cypress/issues/1439 https://github.com/cypress-io/cypress/issues/419 https://github.com/electron/electron/issues/2727 https://github.com/cypress-io/cypress-docker-images/issues/110

2. Looking at cypress slim docker base image, it's 1.2GB

   cypress/base                                    12                  7977a2889cc5        4 months ago        1.26GB

   I built an ubuntu image, that's ~480MB

   winstonnolan/cypress-lambda-ubuntu              latest              03d4ce90b89b        6 hours ago         483MB

   You can find it here: https://hub.docker.com/r/winstonnolan/cypress-lambda-ubuntu

I need to make it smaller, because, the route that I decided to go was, to run it using scar (https://github.com/grycap/scar), to get all the dependencies out of the way, but trying to run it, it seems my image is still too large

2020-07-13T18:25:41.384+12:00 | START RequestId: 0cb269b8-15e4-4f7c-b56f-fc2897873b40 Version: $LATEST
  | 2020-07-13T18:25:41.392+12:00 | 2020-07-13 06:25:41,391 - supervisor - INFO - Reading storage configuration
  | 2020-07-13T18:25:41.397+12:00 | 2020-07-13 06:25:41,397 - supervisor - WARNING - There is no output defined for this function.
  | 2020-07-13T18:25:41.403+12:00 | 2020-07-13 06:25:41,403 - supervisor - WARNING - There is no storage provider defined for this function.
  | 2020-07-13T18:25:41.403+12:00 | 2020-07-13 06:25:41,403 - supervisor - INFO - SUPERVISOR: Initializing AWS Lambda supervisor
  | 2020-07-13T18:25:41.414+12:00 | 2020-07-13 06:25:41,414 - supervisor - INFO - Found 'LOCAL' input provider
  | 2020-07-13T18:25:41.415+12:00 | 2020-07-13 06:25:41,415 - supervisor - INFO - INPUT_FILE_PATH variable set to '/tmp/tmpq26snp4c/event-file-0919bd98-0adb-4059-b136-c01c3542f268'
  | 2020-07-13T18:25:41.552+12:00 | 2020-07-13 06:25:41,552 - supervisor - INFO - Pulling container 'winstonnolan/cypress-lambda-ubuntu' from Docker Hub
  | 2020-07-13T18:26:21.755+12:00 | Downloading layer: sha256:d7c3167c320d7a820935f54cf4290890ea19567da496ecf774e8773b35d5f065
  | 2020-07-13T18:26:21.755+12:00 | Downloading layer: sha256:131f805ec7fd68d45a887e2ef82de61de0247b4eb934ab03b7c933650e854baa
  | 2020-07-13T18:26:21.755+12:00 | Downloading layer: sha256:322ed380e680a77f30528ba013e3a802a7b44948a0609c7d1d732dd46a9a310d
  | 2020-07-13T18:26:21.755+12:00 | Downloading layer: sha256:6ac240b130982ad1c3ba3188abbf18ba4e54bdd9e504ce2d5c2eff6d3e86b8dd
  | 2020-07-13T18:26:21.755+12:00 | Downloading layer: sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
  | 2020-07-13T18:26:21.755+12:00 | Downloading layer: sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
  | 2020-07-13T18:26:21.755+12:00 | Downloading layer: sha256:6dbfcf73bd2811e885bcc5bf0dc4fa6710ef5b0c83a6b67291c44980f763e49d
  | 2020-07-13T18:26:21.755+12:00 | Downloading layer: sha256:a4141361df59fec03535b6282c7f1f0a76e71a5d6c3d633b3109569900ccbc0a
  | 2020-07-13T18:26:21.755+12:00 | Info: creating repo: /tmp/shared/udocker
  | 2020-07-13T18:26:21.876+12:00 | 2020-07-13 06:26:21,876 - supervisor - INFO - Creating container based on image 'winstonnolan/cypress-lambda-ubuntu'.
  | 2020-07-13T18:26:29.855+12:00 | Info: creating repo: /tmp/shared/udocker
  | 2020-07-13T18:26:29.855+12:00 | 895663f5-8d7a-316a-a821-a9c98d4c2049
  | 2020-07-13T18:26:30.023+12:00 | Info: creating repo: /tmp/shared/udocker
  | 2020-07-13T18:26:30.032+12:00 | Traceback (most recent call last):
  | 2020-07-13T18:26:30.032+12:00 | File "/opt/udocker/udocker.py", line 7154, in <module>
  | 2020-07-13T18:26:30.032+12:00 | sys.exit(Main().start())
  | 2020-07-13T18:26:30.032+12:00 | File "/opt/udocker/udocker.py", line 7142, in start
  | 2020-07-13T18:26:30.032+12:00 | exit_status = self.execute()
  | 2020-07-13T18:26:30.032+12:00 | File "/opt/udocker/udocker.py", line 7125, in execute
  | 2020-07-13T18:26:30.032+12:00 | status = cmds[command](self.cmdp) # executes the command
  | 2020-07-13T18:26:30.032+12:00 | File "/opt/udocker/udocker.py", line 6752, in do_setup
  | 2020-07-13T18:26:30.032+12:00 | return exec_mode.set_mode(xmode.upper(), force)
  | 2020-07-13T18:26:30.032+12:00 | File "/opt/udocker/udocker.py", line 3701, in set_mode
  | 2020-07-13T18:26:30.032+12:00 | status = FileUtil(self.container_execmode).putdata(xmode)
  | 2020-07-13T18:26:30.032+12:00 | File "/opt/udocker/udocker.py", line 985, in putdata
  | 2020-07-13T18:26:30.032+12:00 | filep.close()
  | 2020-07-13T18:26:30.032+12:00 | OSError: [Errno 28] No space left on device
  | 2020-07-13T18:26:30.051+12:00 | 2020-07-13 06:26:30,050 - supervisor - INFO - Executing udocker container. Timeout set to '241' seconds
  | 2020-07-13T18:26:30.217+12:00 | 2020-07-13 06:26:30,217 - supervisor - INFO - Searching for files to upload in folder '/tmp/tmpp3p23j46'
  | 2020-07-13T18:26:30.217+12:00 | 2020-07-13 06:26:30,217 - supervisor - INFO - Creating response
  | 2020-07-13T18:26:30.219+12:00 | END RequestId: 0cb269b8-15e4-4f7c-b56f-fc2897873b40
  | 2020-07-13T18:26:30.219+12:00 | REPORT RequestId: 0cb269b8-15e4-4f7c-b56f-fc2897873b40  Duration: 48834.35 ms   Billed Duration: 48900 ms   Memory Size: 3000 MB    Max Memory Used: 628 MB Init Duration: 554.66 ms

Almost there, and it's fun anyways, so why not? I'm doubtful that I will get it working, and even if I do, it will be heavy for my use-case, to keep pulling these docker images

I'm starting to lean towards puppeteer, for my use-case

Anyways, let me know what you think - Good luck!

PS. Cypress I love you so much! What a wonderful awesome software, and I love working with it. To the creators, and contributors, I'm in awe of what you have created <3

[WinstonN]

OK, we're getting there. The below output is from the custom ubuntu, with all the dependencies, running inside of lambda

❯❯❯ docker image ls
REPOSITORY                                      TAG                 IMAGE ID            CREATED             SIZE
winstonnolan/cypress-lambda-ubuntu              latest              7c7ba1f6c8d0        14 minutes ago      391MB

❯❯❯ python3 scar/scarcli.py run -n cypress-lambda-ubuntu df -h
Request Id: a91cc17a-7f6b-441a-ac86-9c4cc4fcca3d
Log Group Name: /aws/lambda/cypress-lambda-ubuntu
Log Stream Name: 2020/07/13/[$LATEST]dbc7487c79334d369957d80c15cac7cb
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       526M  509M  5.9M  99% /
/dev/vdb        1.5G   20M  1.4G   2% /dev

❯❯❯ python3 scar/scarcli.py run -n cypress-lambda-ubuntu cat /etc/issue
Request Id: a3829ddc-f0f7-4b18-91f3-767c452a5810
Log Group Name: /aws/lambda/cypress-lambda-ubuntu
Log Stream Name: 2020/07/13/[$LATEST]dbc7487c79334d369957d80c15cac7cb
Ubuntu 18.04.4 LTS \n \l

[WinstonN]

Almost there,

❯❯❯ python3 scar/scarcli.py run -n cypress-lambda-ubuntu -s ../project/cypress-in-lambda/run.sh
Request Id: e3b213d2-8401-47e9-99f8-1279c459d5bb
Log Group Name: /aws/lambda/cypress-lambda-ubuntu
Log Stream Name: 2020/07/15/[$LATEST]87c3b0027784481e823b2bcfefc57499
Cypress package version: 4.10.0
Cypress binary version: 4.10.0

Still fails on cypress info on the lambda, on the docker it works, as seen below

❯❯❯ docker run -it -v "$PWD":/data:rw cypress-project-lambda/ubuntu/base-image bash
ubuntu 🐳  95cb16232665 / # export CYPRESS_INSTALL_BINARY=0
ubuntu 🐳  95cb16232665 / # export CYPRESS_RUN_BINARY=/data/cypress/4.10.0/Cypress/Cypress
ubuntu 🐳  95cb16232665 / # export CYPRESS_CACHE_FOLDER=/data/tmp
ubuntu 🐳  95cb16232665 / # cd /data/cypress/4.10.0/
ubuntu 🐳  95cb16232665 4.10.0 # ./node_modules/cypress/bin/cypress info
Displaying Cypress info...

Detected no known browsers installed

Proxy Settings: none detected
Environment Variables:
CYPRESS_RUN_BINARY: /data/cypress/4.10.0/Cypress/Cypress
CYPRESS_INSTALL_BINARY: 0
CYPRESS_CACHE_FOLDER: /data/tmp

Application Data: /root/.config/cypress/cy/development
Browser Profiles: /root/.config/cypress/cy/development/browsers
Binary Caches: /data/tmp

Cypress Version: 4.10.0
System Platform: linux (Ubuntu - 18.04)
System Memory: 4.13 GB free 1.01 GB

[WinstonN]

Sweet, we've got a beautiful stack trace to work with <3 I finally got this, after many fixes, and using these commands in the lambda

How I got this far is basically

1. Build a tiny docker container with all the cypress dependencies - got it down to 386MB (wow this was difficult)

   REPOSITORY                                      TAG                 IMAGE ID            CREATED             SIZE
   winstonnolan/cypress-lambda-ubuntu              latest              ede520fcf313        3 hours ago         386MB

2. Using scar to wire up the lambda, layer, and containerisation, using udocker (made some fixes in my fork of their faas-supervisor repo) https://github.com/grycap/scar/issues/360 https://github.com/WinstonN/faas-supervisor/commits/master

3. Wire up the AWS portion, of EFS, DataSync to sync my files from S3 to EFS

4. Grab cypress files from docker

5. Finally, we are here

# run.sh
#!/bin/bash
cd /mnt/efs/cypress/4.10.0/node_modules/cypress/bin
echo 'cypress version'
DEBUG=cypress:* ./cypress version
echo 'cypress verify'
DEBUG=cypress:* ./cypress verify

Stack trace

❯❯❯ python3 scar/scarcli.py run -n cypress-lambda-ubuntu -s ../project/cypress-in-lambda/run.sh
Request Id: 92e51531-f924-4aab-9905-6ad45984b776
Log Group Name: /aws/lambda/cypress-lambda-ubuntu
Log Stream Name: 2020/07/15/[$LATEST]372c847919a04a2f85130cb5f596ed4b
cypress version
2020-07-15T09:56:14.268Z cypress:cli:cli cli starts with arguments ["/lib/x86_64-linux-gnu/ld-2.27.so","/mnt/efs/cypress/4.10.0/node_modules/cypress/bin/cypress","version"]
2020-07-15T09:56:14.269Z cypress:cli NODE_OPTIONS is not set
2020-07-15T09:56:14.270Z cypress:cli:cli printing Cypress version
2020-07-15T09:56:14.280Z cypress:cli Using CYPRESS_RUN_BINARY from environment variable
2020-07-15T09:56:14.280Z cypress:cli Using CYPRESS_RUN_BINARY from environment variable
2020-07-15T09:56:14.306Z cypress:cli CYPRESS_RUN_BINARY has realpath: /mnt/efs/cypress/4.10.0/Cypress/Cypress
2020-07-15T09:56:14.306Z cypress:cli CYPRESS_RUN_BINARY has binaryDir: /mnt/efs/cypress/4.10.0/Cypress
2020-07-15T09:56:14.306Z cypress:cli Reading binary package.json from: /mnt/efs/cypress/4.10.0/Cypress/resources/app/package.json
Cypress package version: 4.10.0
Cypress binary version: 4.10.0
cypress verify
2020-07-15T09:56:19.093Z cypress:cli:cli cli starts with arguments ["/lib/x86_64-linux-gnu/ld-2.27.so","/mnt/efs/cypress/4.10.0/node_modules/cypress/bin/cypress","verify"]
2020-07-15T09:56:19.095Z cypress:cli NODE_OPTIONS is not set
2020-07-15T09:56:19.095Z cypress:cli:cli program parsing arguments
2020-07-15T09:56:19.097Z cypress:cli parsed cli options {}
2020-07-15T09:56:21.511Z cypress:cli verifying Cypress app
2020-07-15T09:56:21.512Z cypress:cli checking environment variables
2020-07-15T09:56:21.512Z cypress:cli Using CYPRESS_RUN_BINARY from environment variable
2020-07-15T09:56:21.513Z cypress:cli Using CYPRESS_RUN_BINARY from environment variable
2020-07-15T09:56:21.513Z cypress:cli CYPRESS_RUN_BINARY exists, = /mnt/efs/cypress/4.10.0/Cypress/Cypress
Note: You have set the environment variable:

CYPRESS_RUN_BINARY=/mnt/efs/cypress/4.10.0/Cypress/Cypress

This overrides the default Cypress binary path used.

2020-07-15T09:56:21.525Z cypress:cli CYPRESS_RUN_BINARY is executable? : true
2020-07-15T09:56:21.527Z cypress:cli CYPRESS_RUN_BINARY has realpath: /mnt/efs/cypress/4.10.0/Cypress/Cypress
2020-07-15T09:56:21.527Z cypress:cli CYPRESS_RUN_BINARY has binaryDir: /mnt/efs/cypress/4.10.0/Cypress
2020-07-15T09:56:21.527Z cypress:cli checking if executable exists /mnt/efs/cypress/4.10.0/Cypress/Cypress
2020-07-15T09:56:21.528Z cypress:cli Binary is executable? : true
2020-07-15T09:56:21.528Z cypress:cli binaryDir is  /mnt/efs/cypress/4.10.0/Cypress
2020-07-15T09:56:21.528Z cypress:cli Reading binary package.json from: /mnt/efs/cypress/4.10.0/Cypress/resources/app/package.json
2020-07-15T09:56:21.541Z cypress:cli Found binary version 4.10.0 installed in: /mnt/efs/cypress/4.10.0/Cypress
2020-07-15T09:56:21.548Z cypress:cli could not read binary_state.json file at "/mnt/efs/cypress/4.10.0/binary_state.json"
2020-07-15T09:56:21.548Z cypress:cli {}
2020-07-15T09:56:21.548Z cypress:cli is Verified ? undefined
2020-07-15T09:56:21.548Z cypress:cli force verify
2020-07-15T09:56:21.548Z cypress:cli running binary verification check 4.10.0

[09:56:21]  Verifying Cypress can run /mnt/efs/cypress/4.10.0/Cypress [started]
2020-07-15T09:56:21.552Z cypress:cli clearing out the verified version
2020-07-15T09:56:21.603Z cypress:cli undefined DISPLAY environment variable
2020-07-15T09:56:21.603Z cypress:cli Cypress will spawn its own Xvfb
2020-07-15T09:56:21.603Z cypress:cli needs Xvfb? true
2020-07-15T09:56:21.603Z cypress:cli Starting Xvfb
2020-07-15T09:56:21.612Z cypress:xvfb _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
_XSERVTransSocketCreateListener: failed to bind listener
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for unix

2020-07-15T09:56:21.622Z cypress:cli disabling Electron sandbox
2020-07-15T09:56:21.622Z cypress:cli running smoke test
2020-07-15T09:56:21.622Z cypress:cli using Cypress executable /mnt/efs/cypress/4.10.0/Cypress/Cypress
2020-07-15T09:56:21.622Z cypress:cli smoke test command: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=489
2020-07-15T09:56:21.622Z cypress:cli smoke test timeout 30000 ms
2020-07-15T09:56:51.658Z cypress:cli Smoke test failed: { Error: Command failed: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=489

    at makeError (/mnt/efs/cypress/4.10.0/node_modules/cypress/node_modules/execa/index.js:174:9)
    at Promise.all.then.arr (/mnt/efs/cypress/4.10.0/node_modules/cypress/node_modules/execa/index.js:278:16)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  code: null,
  stdout: '',
  stderr: '',
  failed: true,
  signal: 'SIGTERM',
  cmd: '/mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=489',
  timedOut: true,
  killed: true }
2020-07-15T09:56:51.659Z cypress:cli error message: Command failed: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=489

2020-07-15T09:56:51.659Z cypress:cli error timedOut is true
2020-07-15T09:56:51.680Z cypress:cli Stopping Xvfb
[09:56:51]  Verifying Cypress can run /mnt/efs/cypress/4.10.0/Cypress [failed]
[09:56:51] → Cypress verification timed out.

This command failed with the following output:

/mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=489

----------

Command failed: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=489

----------

Platform: linux (Ubuntu - 18.04)
Cypress Version: 4.10.0
Cypress verification timed out.

This command failed with the following output:

/mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=489

----------

Command failed: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=489

----------

Platform: linux (Ubuntu - 18.04)
Cypress Version: 4.10.0

[WinstonN]

hey everyone, I'm stuck with Cypress and Xvfb I have a pretty neat operation now, and can iterate fairly fast

Essentially, I'm stuck with When Cypress tries to spawn Xvfb, the socket is not owned by root uid=0 and throws an error

2020-07-15T09:56:21.612Z cypress:xvfb _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
_XSERVTransSocketCreateListener: failed to bind listener
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for unix

see https://phabricator.wikimedia.org/T202710

I tried to get around it by following the instructions here: https://docs.cypress.io/guides/guides/continuous-integration.html#Xvfb As suggested by @bahmutov in https://github.com/cypress-io/cypress/issues/4034

I now have this startup

#!/bin/bash

echo 'start xvfb'
Xvfb :99 -screen 0 1280x1024x24 -ac -nolisten tcp -nolisten unix &
export DISPLAY=:99
echo 'checking Xvfb'
ps aux | grep Xvfb

echo 'running cypress'
cd /mnt/efs/cypress/4.10.0/node_modules/cypress/bin
echo 'cypress version'
DEBUG=cypress:cli,xvfb ./cypress version
echo 'cypress verify'
DEBUG=cypress:cli,xvfb ./cypress verify

echo 'running verify command'
cd /mnt/efs/cypress/4.10.0/Cypress/
./Cypress --no-sandbox --smoke-test --ping=537

echo 'killing Xvfb'
pkill Xvfb
rm -rf /tmp/.X99-lock

Which produces, this cypress output

❯❯❯ python3 scar/scarcli.py run -n cypress-lambda-ubuntu -s ../project/cypress-in-lambda/run.sh
Request Id: fad1535b-15a4-4ca4-aad0-5202b5325e20
Log Group Name: /aws/lambda/cypress-lambda-ubuntu
Log Stream Name: 2020/07/15/[$LATEST]a4afdb010ec84e77ad6f9c371d97348d
killing Xvfb
start xvfb
checking Xvfb
root      1272  0.0  0.1  80056  4140 ?        R    22:56   0:00 /tmp/shared/udocker/containers/f793ee49-3f97-3e06-b776-4c66daceb789/ROOT//lib64/ld-linux-x86-64.so.2 /tmp/shared/udocker/containers/f793ee49-3f97-3e06-b776-4c66daceb789/ROOT/usr/bin/Xvfb :99 -screen 0 1280x1024x24 -ac -nolisten tcp -nolisten unix
root      1274  0.0  0.0  15724   596 ?        S    22:56   0:00 /tmp/shared/udocker/containers/f793ee49-3f97-3e06-b776-4c66daceb789/ROOT//lib64/ld-linux-x86-64.so.2 /tmp/shared/udocker/containers/f793ee49-3f97-3e06-b776-4c66daceb789/ROOT/bin/grep Xvfb
running cypress
cypress version
2020-07-15T22:56:29.685Z cypress:cli:cli cli starts with arguments ["/lib/x86_64-linux-gnu/ld-2.27.so","/mnt/efs/cypress/4.10.0/node_modules/cypress/bin/cypress","version"]
2020-07-15T22:56:29.686Z cypress:cli NODE_OPTIONS is not set
2020-07-15T22:56:29.687Z cypress:cli:cli printing Cypress version
2020-07-15T22:56:29.699Z cypress:cli Using CYPRESS_RUN_BINARY from environment variable
2020-07-15T22:56:29.699Z cypress:cli Using CYPRESS_RUN_BINARY from environment variable
2020-07-15T22:56:29.723Z cypress:cli CYPRESS_RUN_BINARY has realpath: /mnt/efs/cypress/4.10.0/Cypress/Cypress
2020-07-15T22:56:29.723Z cypress:cli CYPRESS_RUN_BINARY has binaryDir: /mnt/efs/cypress/4.10.0/Cypress
2020-07-15T22:56:29.723Z cypress:cli Reading binary package.json from: /mnt/efs/cypress/4.10.0/Cypress/resources/app/package.json
Cypress package version: 4.10.0
Cypress binary version: 4.10.0
cypress verify
2020-07-15T22:56:34.462Z cypress:cli:cli cli starts with arguments ["/lib/x86_64-linux-gnu/ld-2.27.so","/mnt/efs/cypress/4.10.0/node_modules/cypress/bin/cypress","verify"]
2020-07-15T22:56:34.463Z cypress:cli NODE_OPTIONS is not set
2020-07-15T22:56:34.463Z cypress:cli:cli program parsing arguments
2020-07-15T22:56:34.466Z cypress:cli parsed cli options {}
2020-07-15T22:56:37.083Z cypress:cli verifying Cypress app
2020-07-15T22:56:37.084Z cypress:cli checking environment variables
2020-07-15T22:56:37.084Z cypress:cli Using CYPRESS_RUN_BINARY from environment variable
2020-07-15T22:56:37.084Z cypress:cli Using CYPRESS_RUN_BINARY from environment variable
2020-07-15T22:56:37.084Z cypress:cli CYPRESS_RUN_BINARY exists, = /mnt/efs/cypress/4.10.0/Cypress/Cypress
Note: You have set the environment variable:

CYPRESS_RUN_BINARY=/mnt/efs/cypress/4.10.0/Cypress/Cypress

This overrides the default Cypress binary path used.

2020-07-15T22:56:37.096Z cypress:cli CYPRESS_RUN_BINARY is executable? : true
2020-07-15T22:56:37.100Z cypress:cli CYPRESS_RUN_BINARY has realpath: /mnt/efs/cypress/4.10.0/Cypress/Cypress
2020-07-15T22:56:37.100Z cypress:cli CYPRESS_RUN_BINARY has binaryDir: /mnt/efs/cypress/4.10.0/Cypress
2020-07-15T22:56:37.100Z cypress:cli checking if executable exists /mnt/efs/cypress/4.10.0/Cypress/Cypress
2020-07-15T22:56:37.100Z cypress:cli Binary is executable? : true
2020-07-15T22:56:37.100Z cypress:cli binaryDir is  /mnt/efs/cypress/4.10.0/Cypress
2020-07-15T22:56:37.100Z cypress:cli Reading binary package.json from: /mnt/efs/cypress/4.10.0/Cypress/resources/app/package.json
2020-07-15T22:56:37.111Z cypress:cli Found binary version 4.10.0 installed in: /mnt/efs/cypress/4.10.0/Cypress
2020-07-15T22:56:37.111Z cypress:cli could not read binary_state.json file at "/mnt/efs/cypress/4.10.0/binary_state.json"
2020-07-15T22:56:37.112Z cypress:cli {}
2020-07-15T22:56:37.112Z cypress:cli is Verified ? undefined
2020-07-15T22:56:37.112Z cypress:cli force verify
2020-07-15T22:56:37.112Z cypress:cli running binary verification check 4.10.0

[22:56:37]  Verifying Cypress can run /mnt/efs/cypress/4.10.0/Cypress [started]
2020-07-15T22:56:37.115Z cypress:cli clearing out the verified version
2020-07-15T22:56:37.168Z cypress:cli DISPLAY environment variable is set to :99 on Linux
Assuming this DISPLAY points at working X11 server,
Cypress will not spawn own Xvfb

NOTE: if the X11 server is NOT working, Cypress will exit without explanation,
  see https://github.com/cypress-io/cypress/issues/4034
Solution: Unset the DISPLAY variable and try again:
  DISPLAY= npx cypress run ...
2020-07-15T22:56:37.168Z cypress:cli needs Xvfb? false
2020-07-15T22:56:37.168Z cypress:cli spawning, should retry on display problem? true
2020-07-15T22:56:37.168Z cypress:cli disabling Electron sandbox
2020-07-15T22:56:37.168Z cypress:cli running smoke test
2020-07-15T22:56:37.168Z cypress:cli using Cypress executable /mnt/efs/cypress/4.10.0/Cypress/Cypress
2020-07-15T22:56:37.168Z cypress:cli smoke test command: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=21
2020-07-15T22:56:37.168Z cypress:cli smoke test timeout 30000 ms
2020-07-15T22:57:07.212Z cypress:cli Smoke test failed: { Error: Command failed: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=21

    at makeError (/mnt/efs/cypress/4.10.0/node_modules/cypress/node_modules/execa/index.js:174:9)
    at Promise.all.then.arr (/mnt/efs/cypress/4.10.0/node_modules/cypress/node_modules/execa/index.js:278:16)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  code: null,
  stdout: '',
  stderr: '',
  failed: true,
  signal: 'SIGTERM',
  cmd: '/mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=21',
  timedOut: true,
  killed: true }
2020-07-15T22:57:07.213Z cypress:cli error message: Command failed: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=21

2020-07-15T22:57:07.213Z cypress:cli error timedOut is true
[22:57:07]  Verifying Cypress can run /mnt/efs/cypress/4.10.0/Cypress [failed]
[22:57:07] → Cypress verification timed out.

This command failed with the following output:

/mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=21

----------

Command failed: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=21

----------

Platform: linux (Ubuntu - 18.04)
Cypress Version: 4.10.0
Cypress verification timed out.

This command failed with the following output:

/mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=21

----------

Command failed: /mnt/efs/cypress/4.10.0/Cypress/Cypress --no-sandbox --smoke-test --ping=21

----------

Platform: linux (Ubuntu - 18.04)
Cypress Version: 4.10.0
killing Xvfb

It could be that Xvfb is not working correctly, and I need to patch it, as Stuart did here: https://github.com/stuartsan/cypress-lambda/blob/master/lambda/patch.sh

If anyone wants to jump in, you'd be most welcome

[kentan88]

Did anyone eventually figured out how to make https://github.com/stuartsan/cypress-lambda work on AWS Linux 2 on node 10 or 12? Have been hacking away for a while with minimal success