无需Cypress Dashboard在GitHub Actions并行执行Cypress测试

方案1：修复Sorry Cypress的CI配置问题 #

GitHub Actions环境下跑不通Sorry Cypress基本都是配置疏漏导致的，对照以下几点排查即可：

• 所有并行Job必须配置统一的环境变量CYPRESS_API_URL，指向你自托管的Sorry Cypress服务地址，注意补全http/https前缀，不要漏配
• 启动Cypress时必须携带--record --parallel参数，使用Sorry Cypress生成的项目ID，注意不要混用Cypress官方Dashboard Key和自托管Sorry Cypress生成的项目Key，否则会上报失败
• 所有并行Job必须传入相同的--ci-build-id值，直接取GitHub Actions内置的${{ github.run_id }}即可，不要用随机生成值，否则调度服务无法识别同一次测试的分片任务
• 如果你用的是GitHub托管的公共Runner，确保自托管的Sorry Cypress服务有公网访问权限，且跨域规则放开了GitHub Actions的出口IP段

方案2：零依赖原生GitHub Actions分片实现 #

不想额外部署调度服务的话，直接用GitHub Actions矩阵策略+手动Spec分片就能实现并行，完全不需要任何第三方服务：

• 核心逻辑是将所有测试用例文件按并行Job总数均分，每个Job只执行分配到的子集
• 具体配置步骤：
  1. 在Workflow中定义矩阵策略，比如开4个并行分片，配置矩阵参数shard: [1,2,3,4]，同时声明总分片数为4
  2. 在测试启动步骤前加简单的分片逻辑，自动筛选当前分片需要执行的用例文件，参考分片脚本：

// cypress-shard.js
const glob = require('glob')
// 读取所有e2e测试文件
const allSpecs = glob.sync('./cypress/e2e/**/*.cy.{js,ts,jsx,tsx}')
const currentShard = Number(process.env.CURRENT_SHARD)
const totalShards = Number(process.env.TOTAL_SHARDS)
// 按取模规则分配文件到对应分片
const targetSpecs = allSpecs.filter((_, idx) => idx % totalShards === currentShard - 1)
console.log(targetSpecs.join(','))

3. 启动Cypress时直接指定当前分片的用例列表，执行命令参考：cypress run --spec $(node cypress-shard.js)

• 这个方案没有额外运维成本，只需要在每个Job结束后把生成的测试报告、截图、录像上传到GitHub Actions Artifact，最后做简单汇总即可。如果要优化分片效率，可以按用例历史执行时长分配，替代简单的取模均分，减少整体执行时间。

方案3：轻量开源工具替代 #

如果不想自己写分片逻辑，也不想维护完整的类Dashboard服务，可以选择更轻量的开源工具：

• cypress-split：专门面向CI场景的Cypress分片工具，支持自动拉取用例历史耗时做智能分片，不需要部署后端，直接在GitHub Actions中引入配置即可，分片效率比手动均分高30%左右
• cypress-parallel：无依赖的开源并行运行工具，支持自动发现用例、均衡分配任务、聚合测试报告，配置门槛极低，不需要对接任何外部服务
• 自托管版轻量测试平台：如果需要测试历史回溯、失败用例归类、团队共享报告这类Dashboard能力，可以选择部署更轻量的开源测试编排平台，原生适配GitHub Actions，配置复杂度比Sorry Cypress低很多

注意：所有并行方案都要求同一批次的并行Job使用完全一致的Cypress版本、测试代码提交版本，否则会出现分片校验失败、用例执行重复/遗漏的问题。

内容的提问来源于stack exchange，提问作者ThimiraR