Which configuration strategy best manages artifact storage for parallelized CI runs?
0 reputation · 23 Dec 2022, 08:33 UTC
0 reputation · 23 Dec 2022, 08:33 UTC
When executing cypress run across multiple parallelized nodes in a CI/CD pipeline, Cypress automatically generates screenshots and videos for failed tests. These artifacts are stored locally on each individual node within the cypress/screenshots and cypress/videos directories.
The challenge arises when attempting to consolidate these distributed files into a single diagnostic view without utilizing the commercial Cypress Cloud. Since each node operates in an isolated environment, the standard local file output is fragmented across the build cluster.
What is the most efficient method for aggregating these artifacts from parallel nodes into a centralized storage location for post-mortem analysis? Does Cypress provide a native mechanism to stream these files to an external bucket during execution, or must this be handled via CI-level artifact uploading?
35775 reputation · 23 Dec 2022, 15:15 UTC
The most efficient way to collect screenshots and videos from parallel Cypress nodes is to point the screenshotsFolder and videosFolder options to a directory that lives inside the CI runner’s workspace (or a shared volume). After the test run, upload that directory once as a CI artifact and, if desired, copy it to a cloud bucket.
Cypress writes artifacts to the local filesystem of each node. It does not provide a built‑in mechanism to stream those files to external storage while the tests are running. By configuring the folders to a shared workspace, all nodes end up writing into the same location on disk once the job completes. The CI system can then package the folder and upload it as a single artifact, simplifying post‑mortem analysis.
In cypress.config.js (or cypress.env.json), set the folders to a path inside the CI workspace:
module.exports = {
e2e: {
screenshotsFolder: 'ci_artifacts/screenshots',
videosFolder: 'ci_artifacts/videos',
// other e2e options
}
};
Ensure the CI job mounts a writable volume at ci_artifacts (or the chosen path). For example, in GitHub Actions you can use the default workspace ./ and reference ./ci_artifacts.
Run Cypress in parallel as usual, e.g., npx cypress run --parallel --record false.
After the run, add a CI step that uploads the ci_artifacts directory:
# GitHub Actions example
- name: Upload Cypress artifacts
uses: actions/upload-artifact@v4
with:
name: cypress-artifacts
path: ci_artifacts/**
Optionally, copy the uploaded artifact to a cloud bucket (S3, GCS, Azure Blob) using the CI’s cloud CLI or an extra script step.
screenshots and videos directories from each container to the shared workspace before the upload step.Do your parallel runners share a writable volume that can be used as the screenshotsFolder and videosFolder target? Knowing this will confirm whether the shared‑workspace approach can be applied directly or if an intermediate copy step is required.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.