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
description: When you run tests and create recordings, they are stored locally. You can opt to upload them automatically or define your own uploading strategy. All uploaded recordings become accessible in the Replay App.
3
+
description: When you run tests and create recordings, they are stored locally. You can choose which recordings get uploaded to Replay. All uploaded recordings become accessible in the Replay App.
4
4
---
5
5
6
6
{% callout %}
7
-
While uploading just failed test is good for saving resources, our recommendation is to upload both failed and passed tests so that you can compare them. This can be really useful for debugging purposes.
7
+
While uploading just failed tests is good for saving resources, our recommendation is to upload both failed and passed tests so that you can compare them. This can be really useful for debugging purposes.
8
8
{% /callout %}
9
9
10
-
## Upload failed tests only
10
+
## Upload all tests
11
11
12
-
By default, all test replays are uploaded no matter the result. If you want to upload only the failed recordings, you can use the `filter` property in the plugin configuration:
12
+
To upload all test replays no matter the result, set the `upload` option to true.
To upload recordings only for failed tests use `statusThreshold` option:
74
63
75
-
By default, all test replays are uploaded no matter the result. If you want to upload failed and flaky tests, you can use the `filter` property in the plugin configuration:
// upload runtime crashes and recordings with any tests that failed
87
-
return (
88
-
recording.status==='crashed'||
89
-
recording.metadata.test.tests.some(
90
-
(test) =>test.result==='failed',
91
-
)
92
-
)
74
+
upload: {
75
+
statusThreshold:'failed',
93
76
},
94
77
})
95
78
return config
@@ -98,23 +81,52 @@ export default defineConfig({
98
81
})
99
82
```
100
83
101
-
## Upload only for the primary branch
84
+
{% /tab %}
85
+
{% tab %}
102
86
103
-
The recording metadata includes some details about the source control including the repository and branch name which can also be used to filter your uploads. The example below uploads all recordings from the `main` branch:
If you've adopted one the configurations above but would also like to periodically upload all replays for a test run, you can add a condition to the filter that returns `true` for a given test run id. This is only one possible implementation of this approach and you're welcome to adopt others such as using external environment variables.
170
+
Many CI providers provide an environment variable that references the current branch name.
GitHub [stores this value in a default variable](https://docs.github.com/en/actions/learn-github-actions/variables) named `GITHUB_BASE_REF` that can be passed along as [part of a Workflow](https://docs.github.com/en/actions/learn-github-actions/variables#defining-environment-variables-for-a-single-workflow) and then referenced in the test config like so:
Alternatively, you can upload your replays in a separate step using our [GitHub upload action](https://github.com/replayio/action-upload). To filter which replays to upload, you can use [JSONata filtering functions](https://docs.jsonata.org/higher-order-functions#filter).
Use the advanced upload options to reduce the number of recordings that are uploaded. When this option is enabled, only one recording will be uploaded for any passing or failing test. For flaky tests, two recordings will be uploaded– the passing test and one of the failed attempts.
0 commit comments