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 #5141 (comment)

[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?

[kevinold]

@tomardern @WinstonN Would you have an example repo with your Dockerfile, lambda and any other relevant files with the modifications you've mentioned?

[tomardern]

@kevinold Sorry for late reply. I've added the files here - https://gist.github.com/tomardern/822642988be2851beef930f94ba62fa2

[kevinold]

@tomardern Thanks for the gist. That said, it is difficult to diagnose and assist with limited structure and missing files from the overall project.

In order to investigate this further, please provide a git repo with all applicable files that can be deployed via Serverless, AWS SAM, or other utility to AWS.

[WinstonN]

This should be possible now, since AWS lambda supports container images - see https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/

I recommend starting fresh, using the above link documentation

When this thread was created lambda did not support container images, and the route that I went was simply not feasible, since I wanted to run this at scale (millions of invocations)

I therefore went the puppeteer / playwright route which works fine

Hope this helps, and good luck!

[smccarthy-godaddy]

Has anyone gotten this working yet?

[smccarthy-godaddy]

@tomardern I have been trying to get this working the past few days. I have it working for Selenium (on AWS Lambda) by using these Chrome flags:
[
'--disable-background-timer-throttling',
'--disable-breakpad',
'--disable-client-side-phishing-detection',
'--disable-cloud-import',
'--disable-default-apps',
'--disable-dev-shm-usage',
'--disable-extensions',
'--disable-gesture-typing',
'--disable-hang-monitor',
'--disable-infobars',
'--disable-notifications',
'--disable-offer-store-unmasked-wallet-cards',
'--disable-offer-upload-credit-cards',
'--disable-popup-blocking',
'--disable-print-preview',
'--disable-prompt-on-repost',
'--disable-setuid-sandbox',
'--disable-speech-api',
'--disable-sync',
'--disable-tab-for-desktop-share',
'--disable-translate',
'--disable-voice-input',
'--disable-wake-on-wifi',
'--enable-async-dns',
'--enable-simple-cache-backend',
'--enable-tcp-fast-open',
'--disable-webgl',
'--hide-scrollbars',
'--ignore-gpu-blacklist',
'--media-cache-size=33554432',
'--metrics-recording-only',
'--mute-audio',
'--no-default-browser-check',
'--no-first-run',
'--no-pings',
'--no-sandbox',
'--no-zygote',
'--password-store=basic',
'--prerender-from-omnibox=disabled',
'--use-mock-keychain',
'--single-process',
'--headless',
'--disable-gpu',
'--user-data-dir=/tmp/user-data',
'--data-path=/tmp/data-path',
'--homedir=/tmp',
'--disk-cache-dir=/tmp/cache-dir',
'--remote-debugging-port=9222',
"--window-size=1920,1080"
]

I also use the version of Chrome from https://github.com/alixaxel/chrome-aws-lambda (I do an npm i for this package@version and take the chrome binary out of node_modules). Do any of these flags or specific version of Chrome work for you ?

[kevinold]

The Cypress DX Team has examined this landscape and determined a recommended approach.

We recommend that the orchestration be performed by AWS CodeBuild combined with the Cypress Dashboard (vs a command-and-control/fan-out pattern based approach).

This has been implemented in the Cypress Real World App using the build-matrix of AWS CodeBuild's Batch Build feature with a parallelization of 25 machines, for example.

Please refer to this buildspec.yml:

https://github.com/cypress-io/cypress-realworld-app/blob/develop/buildspec.yml

In the buildspec, we are:

• Using a Cypress Docker Image published to a Public Amazon ECR (a formal Cypress Public Amazon ECR is forthcoming with a catalog of images) https://github.com/cypress-io/cypress-realworld-app/blob/develop/buildspec.yml#L17

• Defining variations of jobs using a delimited variable (https://github.com/cypress-io/cypress-realworld-app/blob/develop/buildspec.yml#L19)

• Utilizing shell scripting (the cut command) in the worker (https://github.com/cypress-io/cypress-realworld-app/blob/develop/buildspec.yml#L37-L40) to create environment variables relevant for the worker

• Finally, we are relying on the Cypress Dashboard to handle the parallelization of the spec files among the workers - https://github.com/cypress-io/cypress-realworld-app/blob/develop/buildspec.yml#L52

Reference:

AWS CodeBuild now supports parallel and coordinated executions of a build project
https://aws.amazon.com/about-aws/whats-new/2020/07/aws-codebuild-now-supports-parallel-and-coordinated-executions-of-a-build-project/

[smccarthy-godaddy]

@kevinold Is that above solution you posted about today, to get it to run in AWS Lambda ?

[kevinold]

@smccarthy-godaddy Yes, technically CodeBuild uses Lambda's to run the container, but abstracts that away from you.

[smccarthy-godaddy]

@kevinold I tried looking at the cypress-realworld-app. I see it uses public.ecr.aws/s9l6w2o6/cypress-browsers-node14.15.0-chrome86-ff82. Does this public image do something special to get Cypress to work on Lambda ? For example, how does it get around the xvfb issues mentioned above in this issue? Thank you !

[kevinold]

@smccarthy-godaddy

The public image is simply one of our Cypress Docker Image hosted in a Public ECR.

I mentioned in my previous message that we will be creating a Cypress Public ECR to house most, if not all of our images currently on DockerHub.

In the buildspec, we are:

• Using a Cypress Docker Image published to a Public Amazon ECR (a formal Cypress Public Amazon ECR is forthcoming with a catalog of images) https://github.com/cypress-io/cypress-realworld-app/blob/develop/buildspec.yml#L17

In the meantime, you can clone Cypress Docker Image repo and use this browsers/node14.15.0-chrome86-ff82 or any other browsers image and compile and push it up to your own AWS ECR (Public or Private).

One note is that you will need to adjust the build.sh line to remove the slashes and colons (AWS ECR's do not allow these characters):

Before:

LOCAL_NAME=cypress/browsers:node14.15.0-chrome86-ff82

After:

LOCAL_NAME=cypress-browsers-node14.15.0-chrome86-ff82

[stevenlafl]

I did manage to run Cypress in Lambda myself.. but it's complicated. Before I forget, I wanted to brain-dump this here and outline the challenges I encountered and how I solved them.

Lambda has a maximum of 512mb /tmp space, it mounts read-only all other directories, has a maximum layer size of 250mb, and it has no GPU or multithreading capabilities. There is no shared-space memory: /dev/shm doesn’t exist, and dbus access is forbidden. This makes it very hard to run most things. Cypress and all its binaries are large, and using either layers or /tmp space maximum was a non-starter because Cypress goes beyond even that. I couldn’t fit it in multiple layers, and because Cypress needs write access I’d have to move it all to /tmp anyways, defeating the 512mb maximum. So to save space, I decided to build a docker container for this implementation with Cypress binaries and other dependencies separated out as much as possible. As a result, I had to:

1. Install a special version of Chromium that uses the swiftshader GL library (https://github.com/alixaxel/chrome-aws-lambda/tree/master/bin)
2. Chromium will complain even when launched with --version, so I faked the version number output via an “echo” in a shell script that I aliased to /opt/bin/chromium which runs the real chromium binary if the argument isn’t --version. This allows Cypress to detect and use it without generating an error
3. Other environment variables like XDG_CONFIG_HOME set to /tmp style paths
4. I needed special command-line arguments to disable a few features (which you’ll find in the repo above) added to Chromium when it started, so I put those in the "before:browser:launch" section of the plugins/index.js file.
5. Add similar same command-line arguments via ELECTRON_EXTRA_LAUNCH_ARGS environment variable, or Cypress will say that "GPU process has died" a bunch of times and fail before you even run tests.
6. Install cypress globally via npm, and set the npm cache and Cypress cache directories via environment variables to point to a different directory (in our case /opt/nodejs/.npm and /opt/nodejs/.cypress)
7. Patch the cypress binary to replace occurrences of /dev/shm to /tmp/shm
8. Make the lambda function handler chdir into the /tmp space, and then copy the test project’s cypress and node_modules folders, cypress.json, package.json and package-lock.json files there prior to attempting to require any NPM modules. The function also creates some directories under /tmp that are expected, like the chrome user-data directory and fake /tmp/shm

Right now, my /tmp space total is around 124MB, which leaves some room for screenshots and video output. I did add output of video to s3 and observed the result. Right now, for some reason, the video freezes frame at "loading tests," I suspect I'll have to do some more work to get that going properly, but underneath it all I can confirm that the tests run and are returning the desired result.

[Anteneh82]

@stevenlafl can you share your docker file and handler function ?

[stevenlafl]

@stevenlafl can you share your docker file and handler function ?

I sure can, here is the repository I wrote it under https://github.com/mobomo/cypress-qa

Last I checked this was working. But you might have to insert your own tests, I might have removed those.

[TechFounder]

@stevenlafl Hi just saw your post and repo. Are you using SAM as a substitute for AWS CodeBuild that Kevinold@cypress is recommending? What's the tradeoff of using one and not the other? I've not had experience with either. Thanks!

[nhayes84]

If anyone is still interested I managed to get cypress to run both headless and headed using chromium on an AWS Lambda using a docker image. It's a .Net container image and the Dockerfile looks like this:

FROM public.ecr.aws/lambda/dotnet:6 as chrome
RUN yum install -y unzip && \   
    curl -Lo "/tmp/chrome-linux.zip" "https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F1027016%2Fchrome-linux.zip?alt=media" && \        
    unzip /tmp/chrome-linux.zip -d /opt/

FROM public.ecr.aws/lambda/dotnet:6

WORKDIR /var/task

# Dependencies for Cypress
RUN curl --silent --location https://rpm.nodesource.com/setup_16.x | bash -
RUN yum install -y xorg-x11-server-Xvfb gtk2-devel gtk3-devel libnotify-devel GConf2 nss libXScrnSaver alsa-lib binutils nodejs gdk-pixbuf2

# Install Cypress
RUN unset NODE_OPTIONS
ENV CYPRESS_CACHE_FOLDER=/opt/.cache/Cypress
ENV XDG_CONFIG_HOME=/tmp
ENV HOME=/tmp
ENV NODE_PATH=/var/task/node_modules 

# Speed up builds by not having to redownload cypress
RUN npm install -g npm@8.19.2
RUN npm install --unsafe-perm=true --allow-root cypress@10.8.0 --save-dev
RUN npm install typescript --save-dev

RUN npx cypress verify

RUN rm -rf /opt/.cache/Cypress/10.8.0/Cypress/resources/app/packages/server/lib/environment.js
COPY environment.js /opt/.cache/Cypress/10.8.0/Cypress/resources/app/packages/server/lib/environment.js

RUN rm -rf /opt/.cache/Cypress/10.8.0/Cypress/resources/app/packages/server/lib/browsers/chrome.js
COPY chrome.js /opt/.cache/Cypress/10.8.0/Cypress/resources/app/packages/server/lib/browsers/chrome.js

#Install chrome
RUN yum install atk cups-libs gtk3 libXcomposite alsa-lib \
    libXcursor libXdamage libXext libXi libXrandr libXScrnSaver \
    libXtst pango at-spi2-atk libXt xorg-x11-server-Xvfb which procps \
    xorg-x11-xauth xorg-x11-utils dbus-glib dbus-glib-devel -y

COPY --from=chrome /opt/chrome-linux /opt/chrome

ENV PATH="/var/task:/opt:/opt/chrome:/opt/.cache/Cypress/10.8.0/Cypress:${PATH}"
ENV DISPLAY=":99"
RUN chmod +x /opt/chrome

COPY "bin/Release/lambda-publish"  .

I had to edit the environment.js & chrome.js file to include the following additional flags, I tried to add these in the cypress.config.js file but it never picked them up:

    '--window-size=1920,1080',
    '--force-device-scale-factor=1',
    '--lang=en-GB',
    '--no-sandbox',
    '--incognito',
    '--disable-gpu', // to disable hardware acceleration             
    '--single-process',
    '--no-zygote',
    '--disable-dev-tools',
    '--remote-debugging-port=9222',
    '--disable-setuid-sandbox',
    '--ignore-certificate-errors',
    '--hide-scrollbars',
    '--disable-extensions',
    '--disable-logging',
    '--log-level=3',    
    '--disable-features=VizDisplayCompositor',
    '--disable-features=NetworkService',
    '--dns-prefetch-disable',
    '--disable-extensions',

These flags worked with headed chrome in lambdas when running selenium tests

Finally I started Xvfb with the following:

"Xvfb $DISPLAY -nolisten inet6 -nolisten tcp -nolisten unix -screen 0 1920x1080x24 +extension RANDR >/dev/null 2>&1 &"
"for i in 1 2 3 4 5; do /usr/bin/xdpyinfo -display $DISPLAY >/dev/null 2>&1 && break || sleep '1s'; done" //wait for Xvfb to start
"/usr/bin/xdpyinfo -display $DISPLAY >/dev/null 2>&1 && echo 'In use' || echo 'Free'"; //Check Xvfb has started 

Then run the following cypress run command:

$(npm bin)/cypress run --config '{"video":false,"specPattern":[\"**/actions.cy.js"]}' --project /tmp --browser /opt/chrome/chrome --headed --reporter junit --reporter-options mochaFile=/tmp/result.xml

Note: I copied the spec file to a Test directory in /tmp and copied the cypress.config.js to /tmp

Once the test completes I returned the content of the results xml.

It might not be what people are looking for but thought I'd share in case it helps anyone

[manv6]

@nhayes84 I'm interested to run cypress in lambda, without any luck yet.
Can you give some more deets

1. Where exactly are you starting xvfb ? from the lambda function itself ?
2. What are the environment.js and chrome.js files that you copy from your repo when building docker image?
3. Is the last line COPY "bin/Release/lambda-publish" . copying the lambda function ?

is this going to work with lambda/node docker image ? i.e. public.ecr.aws/lambda/nodejs:14-x86_64

[nhayes84]

@manv6 Yes Xvfb is started at the beginning of the lambda function however if you don't want to start it yourself just remove ENV DISPLAY=":99" form the dockerfile. You will need to modify the xvfb.js file (found: ./node_modules/cypress/lib/exec/xvfb.js) to include the following additional arguments:
'-nolisten', 'inet6', '-nolisten', 'tcp', '-nolisten', 'unix', '+extension', 'RANDR'

The environment.js and chrome.js files are local copies of the files which are installed by cypress. I have just created copies and added the additional flags as mentioned in my original post. You can find them here:

• resources\app\packages\server\lib\environment.cs
• resources\app\packages\server\lib\browsers\chrome.js

I downloaded the cypress zip file and found them that way. I found it easier to modify them locally then copy them in the dockerfile rather than try to edit them directly in the dockerfile.

Finally yes the last line is copying the lambda function along with the cypress.config.js and spec file. This is default functionality when you create a .Net image container using visual studio.

The key thing for me to get it working was the changes to the environment.js and chrome.js files. Adding the flags allowed me to get past the various gpu errors.

I don't see why you can't get it working with a node docker image, you'd just need to find the locations of the files I've modified and see if changing them works. Hope this helps.

[xavierrobitaille]

@manv6 @nhayes84, here are my two cents. Would love to hear what you think.

I thought I needed to run Cypress on a Lambda, but I am now thinking of using AWS CodeBuild instead. My use case:

• I want to run status checks on my WebApp in cypress, on a scheduler.

I thought it would be easy to run cypress on a lambda, given that I am already successfully running automated cypress tests in AWS CodeBuild (codebuild spawns some kind of lambda / EC2). I didn't anticipate there would be so many issues to get something similar running in a lambda.

After reading through this thread, I think I will be better off setting up my status checks inside of AWS CodeBuild (it's easy to trigger CodeBuild from a scheduler, and the cypress team has paved the way to use cypress in AWS CodeBuild).

Xavier

https://featherfinance.com

[manv6]

@xavierrobitaille
I never gone CodeBuild way cause it is too costy for my needs.
I used to run everything in ECS and in parallel but I have a delay in provisioning the ec2 instances. I'm running up to 90 parallel tasks.

That's why I prefer lambdas(cheaper and faster) BUT I cannot make it work yet. I will try @nhayes84 solution asap

[manv6]

@nhayes84 unfortunately this solution doesn't work on AWS Lambda with lambda nodejs image :( I did everything as described with but the base image.

Where are you running your lambda ? can we take it offline and give you some more details ? evlastos@gmail.com

[stevenlafl]

@manv6 have you tried the Lambda setup in the repository I posted? If that isn't working I'll have to update it.

[manv6]

@stevenlafl just tried it
prctl(PR_SET_NO_NEW_PRIVS) failed [34:1005/090621.623467:FATAL:zygote_communication_linux.cc(254)] Cannot communicate with zygote
all the same as you suggest in your repo but cypress 10.8.0

it seems to me that the ELECTRON_EXTRA_LAUNCH_ARGS from handler never loaded

ignore above lines

just managed to load browser args but now I'm getting another error
Timed out waiting for the browser to connect. Retrying... is this because of cypress version. ?
can you check your suggestion with cypress 10 ?

[magJ]

After a lot of trial and error, I've managed to get cypress to run from a Lambda using a container image and chromium as a browser.

For anyone trying to do the same thing, I've put together a full example project you can refer to.

https://github.com/magJ/cypress-lambda-example

[manv6]

@magJ tried your solution and only works in aws if you patch Cypress to write in /tmp/shm instead of /dev/shm
like below:

Add below block after npm install

# Patch Cypress binary to not use /dev/shm RUN echo $'#!/bin/bash \n\ position=$(strings -t d /opt/cypress/10.10.0/Cypress/Cypress | grep "/dev/shm" | cut -d" " -f1) \n\ for i in $position; do \n\ echo -n "/tmp/shm/" | dd bs=1 of=/opt/cypress/10.10.0/Cypress/Cypress seek="$i" conv=notrunc \n\ done' >> /opt/patch.sh RUN chmod +x /opt/patch.sh RUN /opt/patch.sh

[magJ]

@magJ tried your solution and only works in aws if you patch Cypress to write in /tmp/shm instead of /dev/shm

@manv6 The example as-is works fine for me without patching cypress, I guess since it's using chromium, patching cypress like you demonstrated might makes it work without installing another browser I suppose?

Edit: I've now implemented this electron patching in my repo, electron now works locally when ipc is disabled, but still having problems with it on lambda.

[maqtulio]

Any updates on this?