Figure out how to run Firefox better

[bahmutov]

• right now the only way to run Firefox is to use --user 1001 to match the permissions GH sets when creating a home folder for the user

container:
  image: cypress/browsers:node12.16.1-chrome80-ff73
  options: --user 1001

docker.io/cypress/browsers:node12.16.1-chrome80-ff73
/usr/bin/docker create --name 9841aeea80f6424291fc77ef4b420dd6_cypressbrowsersnode12161chrome80ff73_ee5fd3 
--label e87b52 
--workdir /__w/github-action/github-action 
--network github_network_7218f6f710d149c59f24a8cab63bbe10  
-e "HOME=/github/home"

Permissions on the home folder

Run ls -la /github/home
total 8
drwxr-xr-x 2 1001  115 4096 Mar  5 15:33 .
drwxr-xr-x 4 root root 4096 Mar  5 15:33 ..

It would be nice to run with any non-root user, for example our cypress-docker-images have node user with id 1000.

PS: the 1001 user works but has group id of 0

$ id
uid=1001 gid=0(root) groups=0(root)

Preferred

container:
  image: cypress/browsers:node12.16.1-chrome80-ff73
  options: --user node

[kamranayub]

Yeah, attempting to make a sample PWA that has FF under CI but I may throw in the towel for now, it seems to start but then will just hang endlessly. It could be related to previous hanging issues with Shadow DOM (this is an Ionic app). The tests will pass locally in FF, though. Since it's beta, it's not a huge deal to explain away. Tip for anyone who finds this, set timeout-minutes for any e2e jobs unless you want it to hang for 360 minutes (the default) and use up your quota 😱

[jennifer-shehane]

@kamranayub Make sure to update to latest Cypress because we have been fixing the shadow dom hanging as we find them. Today, we're only aware of hanging when using .scrollTo on shadow dom with the experimental feature, so if you do find something isolated to Firefox, open an issue.

[kamranayub]

I'm still investigating but it hangs on my window Notification test suite, though it will work in an isolated way in some of my tests. I am testing a cross-origin domain so that might have something to do with it but like I said, it passes locally in FF 78 🤔 I may be able to grab video from it.

[kamranayub]

Edit: It works! See the end or read the info gathering.

So what I am seeing is a little interesting. It appears that my tests are passing but then mid-way through a test suite, GitHub Actions does not get any more logging/output and there was a 12 minute gap until finally my job hit the wait limit. The video file for the test suite that "failed" (all the tests were passing in the logs at the point of failure) is 3MB and corrupt, I can't open it, but other video files I can.

The output then just cuts off and times out:

Notice at the very end, a gap of 12 minutes. This is why I think it hangs for some reason and it seems to be random it appears to always fail now before the last describe block below in my responsive-design.spec:

describe("on larger screens", () => {
    before(() => {
      cy.visit("/");
    });

    it("should continue displaying marketing imagery", () => {
      cy.viewport("macbook-15");
      cy.get(".hero-image-col").should("be.visible");
    });
  });

The only thing I could possibly think of is that the viewport size is wider than whatever is running in CI natively? But that's a wild guess. 🤷‍♂️

For the 6 hour run, it hung until the 360 minute time limit hit.

It stopped during my Notifications test suite so I thought it was due to a bug in my permissions plugin (which wasn't working in FF) so it was hanging on a native prompt.

2020-07-28T04:58:39.1846394Z   Running:  �[90mnotifications.spec.js�[39m                                                           �[90m(2 of 6)�[39m
2020-07-28T04:58:39.1846501Z 
2020-07-28T04:58:39.1859744Z �[35mYour project has set the configuration option: `chromeWebSecurity: false`�[39m
2020-07-28T04:58:39.1860097Z �[35m�[39m
2020-07-28T04:58:39.1860544Z �[35mThis option will not have an effect in Firefox. Tests that rely on web security being disabled will not run as expected.�[39m
2020-07-28T04:58:39.2107598Z [browserPermissions] permission 'notifications' => 'allow'
2020-07-28T04:58:39.2108092Z [browserPermissions] permission 'geolocation' => 'allow'
2020-07-28T04:58:44.9007831Z 
2020-07-28T04:58:44.9018272Z �[0m�[0m
2020-07-28T04:58:44.9326612Z �[0m  notifications�[0m
2020-07-28T04:58:46.2001069Z   �[32m  ✓�[0m�[90m will prompt user for permission to enable notifications when permission has not been set�[0m�[31m (1296ms)�[0m
2020-07-28T04:58:46.8202247Z �[33m    (retry 1/3)�[39m �[2mwill not prompt user for permission to enable notifications when permission has been granted�[22m
2020-07-28T04:58:48.1993021Z   �[32m  ✓�[0m�[90m will not prompt user for permission to enable notifications when permission has been granted�[0m�[31m (1335ms)�[0m
2020-07-28T04:58:48.8306883Z �[33m    (retry 1/3)�[39m �[2mwill warn user when permissions have been denied for notifications when trying to enable�[22m
2020-07-28T10:51:56.9806709Z ##[error]The operation was canceled.

But since I fixed that, the notifications suite works and now it's failing on the responsive design suite but there's nothing very special about it besides calling cy.viewport in the tests.

One other data point: when running locally, sometimes closing Firefox doesn't register properly to the test runner (it doesn't reset) and I have to click Run All Tests to reset it. Sometimes clicking Stop test doesn't actually close FF either. This maybe could be happening in CI too, though hard to tell.

Attempted fixes

• Switched to headless: true
  • Works fine but not needed!
• Added MOZ_FORCE_DISABLE_E10S=1 env (see Firefox hangs sometimes when running in cypress/included:4.0.1 cypress#6449 (comment)) to disable multiprocess mode
  • I tried this but it seemed to cause FF not to connect to Cypress
• Added --shm-size=2g for increasing shared memory 🎉 🎉 🎉
  • DING DING DING! This was the fix.

Increasing Shared Memory Size

The way to add this is next to the container options:

jobs:
  firefox:
    runs-on: ubuntu-16.04
    container:
      image: cypress/browsers:node12.14.1-chrome83-ff77
      options: --user 1001 --shm-size=2g
#                          ^------------------ Magic!

With this fix, the tests pass now! There are still some blockers on some tests like cross-origin iframe issues but I've disabled those for now. I've gotten past this by ensuring the service worker does not handle HTML page requests during tests (using URL RegExp bypassing in Workbox). I can successfully run all my tests in FF now and they pass. Huzzah!

[emilgoldsmith]

I was running into issues with a custom docker container for the job using --user 1001 because of permissions of the files created in the build stage of the container (in the dockerfile).

I found a solution that I could imagine may very well break some other stuff haha, but it doesn't look like it's breaking any of my things I need to do anyway! For my usecase it seems a lot less intrusive and in case it is for others as well I just wanted to share.

And that was simply to have

jobs:
  job-name:
    env:
      HOME: ""

And it's important not just to do it for the cypress step because then in the install steps it seems like Cypress installs something in the home folders that it needs and it breaks Cypress, if you have it through the whole job like this though, it works perfectly :).

When HOME is set to empty string Firefox allows you to run it as root nicely, and I can keep all the permissions to access my files in the container easily

[KleisKlasKluss]

I was running into issues with a custom docker container for the job using --user 1001 because of permissions of the files created in the build stage of the container (in the dockerfile).

I found a solution that I could imagine may very well break some other stuff haha, but it doesn't look like it's breaking any of my things I need to do anyway! For my usecase it seems a lot less intrusive and in case it is for others as well I just wanted to share.

And that was simply to have

jobs:
  job-name:
    env:
      HOME: ""

And it's important not just to do it for the cypress step because then in the install steps it seems like Cypress installs something in the home folders that it needs and it breaks Cypress, if you have it through the whole job like this though, it works perfectly :).

When HOME is set to empty string Firefox allows you to run it as root nicely, and I can keep all the permissions to access my files in the container easily

Thanks @emilgoldsmith! 🎉 This solved a similar issue that I've been struggling with for quite some time.

[josh803316]

@KleisKlasKluss and @emilgoldsmith I've been running into issues with a custom self-hosted runner (building the image and setting up the environment myself). What does setting "HOME" empty do for the run as user 1001? When I build the AMI image I only have 2 users (ec2-user and ssm-user) -- and the docker container gets layered in after (I think). Anyway I don't have a 1001 user when I'm running the install so I'm curious about how this maps to the environment and PATH.

[MikeMcC399]

The original post for this issue says:

right now the only way to run Firefox is to use --user 1001 to match the permissions GH sets when creating a home folder for the user

however this refers only to running Firefox in a Docker container provided by cypress-io/cypress-docker-images.

When using a GitHub runner directly without a Docker container from cypress-io/cypress-docker-images there is no need to supply a user. Firefox was added to the GitHub runners in March 2020.

The .github/workflows/example-firefox.yml demonstrates testing with Firefox without specifying --user 1001.

• This is related to Firefox README example in container #735.

[Fanch-]

Got into this issue.
Works fine with --user 1001 on ubuntu github runners.

But for a custom self-hosted runner got into this other issue : actions/checkout#956 (comment)

bahmutov Preferred way solved it :
options: --user node

[MikeMcC399]

@Fanch-

Were you using a Docker container from https://github.com/cypress-io/cypress-docker-images when you applied

options: --user node

or did you have Firefox directly installed in your self-hosted runner? What operating system was your self-hosted runner? Ubuntu or something else?

[Fanch-]

Yes using the docker image cypress/browsers:node16.16.0-chrome107-ff107 in a container action.
Runner "Light Ubuntu" with few packages.

Complexity for us is :

• runners are managed by a dedicated team and are very light.
• they don't want to manage custom runners with packages pre-installed for everybody (in our case https://docs.cypress.io/guides/getting-started/installing-cypress#Linux-Prerequisites).
• packages installation takes "forever" which is an issue to resolve but to not be blocked by the support, we bypass it for the time being; using the container action and not the js action directly.
• we could manage a custom image with our other dependencies ourself, as we used to in travis, but we'll try without it with GA (cache)

I hope this gives you some context.

[MikeMcC399]

@Fanch-

Thank you very much for describing your environment and situation!

• I had opened an issue Add Firefox user id 1001 to README common problems cypress-docker-images#871 to request specific Firefox documentation directly in the Docker repo's README.

• I'm unsure whether this discussion is actually specific to github-action itself or whether it should maybe transferred to the cypress-io/cypress-docker-images/issues/ list.

[MikeMcC399]

Closing, as this topic belongs in the cypress-io/cypress-docker-images/issues/ list.

README > Docker image recommends specifying

    container:
      image: cypress/browsers:latest
      options: --user 1001

and refers to cypress-io/cypress-docker-images for further information.