You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Not possible to run Cypress tests without exposing record key #796
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:
The workflow is now triggered only on the repository of the forked repository.
Because the workflow on the forked repository does not have access to this secret all jobs fail.
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.
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.
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).
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.
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.
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 🙁
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.
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?
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?
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.
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.
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.
Activity
MikeMcC399 commentedon Feb 16, 2023
@jonkoops
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 commentedon Feb 28, 2023
@jonkoops
Was this helpful to you?
MikeMcC399 commentedon Mar 7, 2023
@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 commentedon Mar 11, 2023
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 commentedon Mar 21, 2023
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 commentedon Mar 21, 2023
@jonkoops
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.
jonkoops commentedon Mar 22, 2023
MikeMcC399 commentedon Mar 22, 2023
@jonkoops
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 commentedon Mar 23, 2023
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 commentedon Mar 23, 2023
@jonkoops
Have you considered blocking recording into Cypress Cloud for external contributors working in forks? Would that work for you?
jonkoops commentedon Mar 27, 2023
I have, but our entire team works from forks so that would essentially make the Cypress Cloud useless for our current workflow.
MikeMcC399 commentedon Mar 27, 2023
@jonkoops
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
recordparameter 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 commentedon May 25, 2023
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 commentedon May 25, 2023
@jonkoops
I would encourage you to file a new feature request for Cypress so that this need is funnelled in the right direction.
nagash77 commentedon May 26, 2023
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 commentedon May 26, 2023
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 commentedon Jun 7, 2023
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.)