Not possible to run Cypress tests without exposing record key

[jonkoops]

Hi. We're using the Cypress Dashboard for our product and we're having a hard time running the tests without exposing the record key. Currently we have hard-coded it in our workflow, which makes it publicly available (less than ideal for obvious reasons).

We're following the recommendation as outlined in the documentation to use the push event to trigger runs of Cypress. This is problematic for a couple of reasons when opening a PR from a fork:

1. The workflow is now triggered only on the repository of the forked repository.
2. Because the workflow on the forked repository does not have access to this secret all jobs fail.

What is the recommend way to resolve this?

[MikeMcC399]

@jonkoops

• I have a PR proposed in feat: allow recording in fork with secrets #751 to solve the issue that you describe.

Whilst the PR is still open and not merged you can take a look at the workflow in

https://github.com/MikeMcC399/github-action/blob/feat/record-in-fork-rev2/.github/workflows/example-recording.yml

and the example

https://github.com/MikeMcC399/github-action/tree/feat/record-in-fork-rev2/examples/recording

The record key is stored in an Actions secret, therefore not exposed.

[MikeMcC399]

@jonkoops

Was this helpful to you?

[MikeMcC399]

@jonkoops

We didn't hear any more from you, so hopefully you have managed to resolve your issue.

The improved example of recording in a fork has now been merged, so you can refer to the document under examples/recording/README.md for Cypress 10 and later versions. It shows how to record in a fork without exposing the record key. You'll notice that it refers to the Cypress Cloud, which is the new name for the Cypress Dashboard.

[jonkoops]

Hi @MikeMcC399, sorry for the late reply. We're in the processes of moving our repo around, so I will take a look and see if I can get things to work with what was suggested here.

[jonkoops]

After reading the linked documentation I don't understand how this should resolve this issue. From what I can tell it specifies that forks should have their own secrets?

That doesn't seem like a feasible solution, especially when running tests in parallel (in which case Cypress will run the entire test suite in each runner).

[MikeMcC399]

@jonkoops

After reading the linked documentation I don't understand how this should resolve this issue. From what I can tell it specifies that forks should have their own secrets?

That doesn't seem like a feasible solution, especially when running tests in parallel (in which case Cypress will run the entire test suite in each runner).

The suggestion for recording in a fork is intended for forks of public repositories (see About permissions of forks) where a fork has no access to the secret of a parent repository.

• Are your forks public or private?
• Have you attempted to use secrets to store the record key? Your original problem was that you couldn't use the record key without exposing it.

[jonkoops]

1. These are all public forks.
2. My problem is that putting it in a secret makes said secret unavailable to forks (this is just how Github secrets work).

[MikeMcC399]

@jonkoops

1. These are all public forks.
2. My problem is that putting it in a secret makes said secret unavailable to forks (this is just how Github secrets work).

Could you explain a bit more about your organizational background? Do different people or companies own each of the forks or what is the reason for the forks? Are each of the forks supposed to be recording into the same project or into different projects?

If they are public forks then the record key needs to be set as a secret separately for each fork. That was the original problem that I wanted to solve for myself. I am not a member of the cypress-io organization, but I wanted to be able to run the example recording workflow in my fork by using my own secrets.

[jonkoops]

If they are public forks then the record key needs to be set as a secret separately for each fork. That was the original problem that I wanted to solve for myself.

Yeah, this is the exact issue we're running into. It is simply not possible to have external contributors fork our repo and then open up a PR that can access this secret. This effectively means that nobody can create a PR that can pass our CI 🙁

[MikeMcC399]

@jonkoops

Have you considered blocking recording into Cypress Cloud for external contributors working in forks? Would that work for you?

[jonkoops]

I have, but our entire team works from forks so that would essentially make the Cypress Cloud useless for our current workflow.

[MikeMcC399]

@jonkoops

I have, but our entire team works from forks so that would essentially make the Cypress Cloud useless for our current workflow.

Thanks for continuing to explain your use-case! I think I have finally understood! 🙂

This is not something that can be resolved within https://github.com/cypress-io/github-action as the recording is done by Cypress, not by the action. The action just passes on the record parameter to Cypress.

You might like to consider submitting a feature request to the main Cypress issue list as I think this is a general need. The way it currently works also causes some of the workflows in Cypress example repositories to fail if they are started from a fork, for example https://github.com/cypress-io/cypress-realworld-app/blob/develop/.github/workflows/main.yml.

The requirement would be to allow recording from forks of a defined GitHub repository without exposing record key data which could be misused.

I don't know how this could be solved, but perhaps a Cypress Cloud project could be configured so that it only accepts input from a certain repository and forks of that repository, and this would be an alternate method of allowing access to the Cypress Cloud instead of using a record key?

[jonkoops]

I don't know how this could be solved, but perhaps a Cypress Cloud project could be configured so that it only accepts input from a certain repository and forks of that repository, and this would be an alternate method of allowing access to the Cypress Cloud instead of using a record key?

This could be a solution for us. Ideally we'd be able to run Cypress on any PR that is created on our repository, running on forks themselves is not required per-se. Perhaps the GitHub token could be enough to make this identification?

[MikeMcC399]

@jonkoops

I would encourage you to file a new feature request for Cypress so that this need is funnelled in the right direction.

[nagash77]

Hi @jonkoops ,

Unfortuantely, today this is not possible. The concerns you have about anyone running recordings and consuming your bill are a real concern with sharing the recording key publicly. Unless GitHub Action exposed some way to share keys safely for execution on external contributions, it’s not possible for now.

Cypress itself has this problem. We are a public project that records tests and have external contributors writing code to our repo. We have an alternative pathway for external contributors so that the tests that are run skip recording to the Cloud.

Here’s an example of the code we have in our CircleCI setup to do that. You’re welcome to share it with them so they can understand the concept. https://github.com/cypress-io/cypress/blob/develop/.circleci/workflows.yml#L562

I will mark this as a feature request for the time being, although I cannot say when this will be worked on.

[jonkoops]

Thanks for getting back to me on that @nagash77. So it seems we can not really use Cypress Cloud securely with our current workflow, that is unfortunate, but at least I know for certain now.

[MikeMcC399]

Workaround for github-action

See .github/workflows/example-recording.yml check-record-key:

This only covers the case where fork users want to record to their own Cypress Cloud project however, so it is not a workaround to have all contributors record to the same project.

(The link to https://github.com/cypress-io/cypress/blob/develop/.circleci/workflows.yml#L562 covers only CircleCI, not GitHub Actions, so although the basic problem is the same, the workaround details are different.)