Record to Cypress Cloud in fork#694
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
a414863 to
598c8c9
Compare
598c8c9 to
8383fcf
Compare
63ae7ee to
08ab74a
Compare
|
Reworked to set example-custom-ci-build-id was previously running only on v9. I have changed it to run only on v10. Is that acceptable or does the v9 example need to be retained?
|
08ab74a to
4bc1f5f
Compare
This comment was marked as outdated.
This comment was marked as outdated.
By defining their own EXAMPLE_PROJECT_ID and EXAMPLE_RECORD_KEY as GitHub environment variables, users can successfully run the recording examples
4bc1f5f to
90bfd22
Compare
|
I have successfully tested this for the two scenarios:
so it is now ready for review. |
jennifer-shehane
left a comment
There was a problem hiding this comment.
@MikeMcC399 I think I would prefer the route of skipping recording on external contributors for this. We employ this strategy on the main cypress repo, since we have the same issue there with external contributors. I don't see it being convenient for external contributors to setup their own example project in this case just to submit a fix. https://github.com/cypress-io/cypress/blob/develop/.circleci/workflows.yml#L484:L484
|
@jennifer-shehane Thank you for your feedback! My suggestion was more oriented to users who wanted to use the examples to practice the use of the action rather than just to fix submitters. I would however not want to force anyone, including fix submitters, to have to set up a Cypress Cloud project. An easy way out would be to suppress the action from running in a fork, however that would be at the disadvantage of any user who genuinely wanted to get deeper into using the recording examples with low effort, so I don't want to take this route. A better solution is to add a condition to this proposed PR that recording is only attempted if I will take a look at how to implement this best. In the meantime I have set the PR into Draft status. |
|
This PR resolves the issue #693 "Workflows using Cypress Cloud fail in fork".
It follows the recommendation in the README: Record test results on Cypress Cloud documentation, Tip 4, to pass the project id using an environment variable.
The two examples are modified so that they accept and use a new GitHub Actions variable
EXAMPLE_PROJECT_IDin addition to the existingEXAMPLE_RECORDING_KEYwhich is an Actions secret:This is backward compatible to the current workflows.
In the parent repository cypress-io/github-action the Actions secret
EXAMPLE_RECORDING_KEYis defined for the Project ID3tb7jn. Runs are publicly viewable via the Cypress Cloud on https://cloud.cypress.io/projects/3tb7jn.If fork users define
EXAMPLE_PROJECT_IDas Actions variable andEXAMPLE_RECORDING_KEYas Actions secret in their forked repository then the workflows record into the user's own project. If this step is not taken, then the workflows will simply continue to report failures if they are triggered in a fork, exactly as happens before this PR was introduced.README files have been added as:
to explain how to obtain and add a user's own
EXAMPLE_PROJECT_IDandEXAMPLE_RECORDING_KEY.The README files are reviewable in
Verification
Backwards compatibility
Ensure that the workflows for the parent repository cypress-io/github-action continue to report success:
New functionality
Follow the instructions to create new
EXAMPLE_PROJECT_IDActions variable andEXAMPLE_RECORDING_KEYActions secret and check that the results are published on Cypress Cloud.