How Might One Specify Separate Working Directories for Start Parameter on Github Action

[J0]

I'm trying to integrate Cypress Tests with a Phoenix application on a Github Actions workflow. In order to allow the tests to pass the it seems like the Phoenix backend needs to be up on port 4000. To support this, I'm attempting to use the start parameter to run mix phx.server (This brings up the Phoenix backend). However, due to the way Phoenix applications are structured cypress is located in ./assets while the command to start the server mix phx.server depends on files in .

I would like to check if there's a way to specify separate working directories for start and the cypress github action.

I initially tried setting the working-directory parameter but it would configure both the cypress run and the server to run from that directory(assets). Due to the way Phoenix projects are structured.

For added context, this question emerged from a discussion on the Cypress Gitter and I was directed to post the question here.

Here's what I posted:

Hey all,

Does anyone happen to know how I might link the backend startup step and the cypress start step so that cypress first starts the backend and then?I'm attempting to run a e2e test on Github Actions which depends on the backend being up(e.g. you have a command like cy.visit(localhost:4000) which depends on a backend like Django/Rails to be up before the container can run)

Context:

I’m trying to run a suite of end to end tests written with Cypress 6.8.0 on Github Actions. The suite of tests depends on a Phoenix server running on localhost:4000 and the relevant portion of the Github Action looks like this:

  - name: Install dependencies
    run: npm install --prefix assets
  - name: Start Phoenix server
    run: elixir --erl "-detached" -S mix phx.server
  - name: Cypress run
    uses: cypress-io/github-action@v2
    with:
      working-directory: assets
      wait-on: "https://localhost:4000"

I get the following error message when attempting to run a workflow: waiting on "https://localhost:4000" with timeout of 60 seconds. Am aware that this could be an X-Y and perhaps I should dig further into Github Actions to see how the networking is done and validate whether the backend is indeed running the background. However, I just wanted to check if there are alternative workarounds which I can get with Cypress(e.g perhaps coupling the two steps into one). I am able to run the suite of tests to completion locally so I doubt it is an issue with the test itself

Do let me know if you happen to have any suggestions/workarounds. Any help would be deeply appreciated.

Do let me know if you have any suggestions or if there's any additional information I should provide. Any help would be deeply appreciated. Thanks!

[alvaromartmart]

I'm facing the same issue, any updates on this? Or did you find a workaround @J0 ?

[J0]

Hey @alvaromartmart ,

Thanks for reaching out! I unfortunately did not figure out an effective workaround. Let me know what you come up with or if there’s any way I can help.

Joel

[jdborneman-terminus]

We're also facing this issue I believe. Our cypress tests are in a sub/subdirectory of our monorepo, so the working directory needs to be that. but the package.json script that starts up the server is in the root directory.

I tried creating a shell script called start_app.sh in the subdir for our cypress tests that just does:

cd ../..
yarn start:app

But when I set the start command to be that shell command I get

Error: Unable to locate executable file: start_app.sh. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

This is really putting a block on our ability to run cypress in a GitHub action. If anyone has any bright ideas, I'm all ears!

[jdborneman-terminus]

Alright so turns out we were able to get this to work just as I was typign this up by just running a yarn start:app as define din teh root package.json. I'm honestly surprised that worked. We've got other issues now, but this one seems to be at least starting up the app from what we can see.