SurfSense Playwright E2E 与 GitHub Actions 实战浏览器缓存、分片并行、报告合并与完整 CI 落地解析【免费下载链接】SurfSenseOpen-source NotebookLM alternative. Research the open web with live data(Reddit, YT, IG, TikTok, Indeed, Google Search, Maps etc) through one platform, API or MCP server. Join our Discord: https://discord.gg/ejRNvftDp9项目地址: https://gitcode.com/GitHub_Trending/su/SurfSense本文基于 SurfSense 仓库内的技能文档 .cursor/skills/playwright-testing/infrastructure-ci-cd/github-actions.md系统讲解在 GitHub Actions 上自动化 Playwright 测试的六种工作流模式基础单 Job、分片执行、容器化、环境密钥、定时运行、可复用工作流、场景选型速查、高频错误修正与排障方法并结合 SurfSense 真实运行的 .github/workflows/e2e-tests.yml 与 surfsense_web/playwright.config.ts展示Next.js FastAPI Celery Postgres Redis全栈 E2E 测试在 CI 中的完整落地方式。一、适用场景与核心 CLI 命令原文明确给出的适用场景当需要在 Pull Request、main 分支合并或定时任务中自动化 Playwright 测试时使用 GitHub Actions。围绕 CI 场景有四条最核心的 CLI 命令npx playwright install --with-deps # browsers OS dependencies npx playwright test --shard1/4 # run shard 1 of 4 npx playwright test --reportergithub # PR annotations npx playwright merge-reports ./blob-report # combine shard reports这四条命令分别对应后文要展开的四个主题浏览器与系统依赖安装、分片并行、PR 行内注释annotations、以及分片报告的合并。在 SurfSense 中这些命令被封装成了 surfsense_web/package.json 里的一组 npm scripts方便本地与 CI 复用Script实际命令对应能力test:e2eplaywright test默认跑测试本地 dev servertest:e2e:prodcross-env CI1 playwright test以 CI 模式运行触发 playwright.config.ts 中所有process.env.CI分支retries、reporter、webServer 等与 CI 行为完全一致test:e2e:ui/test:e2e:headed/test:e2e:debug--ui/--headed/--debug交互式调试test:e2e:reportplaywright show-report打开最近一次 HTML 报告test:e2e:installplaywright install --with-deps chromium安装浏览器 系统依赖SurfSense 只装 chromium注意原文示例面向npm ci的项目SurfSense 使用 pnpmCI 中对应pnpm install --frozen-lockfile浏览器缓存的 key 也相应哈希pnpm-lock.yaml而非package-lock.json。二、基础单 Job 工作流Basic Workflow适用新项目起步或测试套件较小。要点一个 Job 完成checkout → 装依赖 → 缓存浏览器 → 跑测试 → 传报告的全流程。# .github/workflows/e2e.yml name: E2E Tests on: push: branches: [main] pull_request: branches: [main] concurrency: group: e2e-${{ github.ref }} cancel-in-progress: true env: CI: true jobs: test: timeout-minutes: 30 runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm ci - name: Cache browsers id: browser-cache uses: actions/cachev4 with: path: ~/.cache/ms-playwright key: pw-${{ runner.os }}-${{ hashFiles(package-lock.json) }} - name: Install browsers if: steps.browser-cache.outputs.cache-hit ! true run: npx playwright install --with-deps - name: Install OS dependencies if: steps.browser-cache.outputs.cache-hit true run: npx playwright install-deps - run: npx playwright test - name: Upload report uses: actions/upload-artifactv4 if: ${{ !cancelled() }} with: name: test-report path: playwright-report/ retention-days: 14 - name: Upload traces uses: actions/upload-artifactv4 if: failure() with: name: traces path: test-results/ retention-days: 7这个模板里有五个值得逐一看懂的设计concurrencycancel-in-progress: true同一 ref 上的旧运行会被新运行取消避免 PR 连续 push 时 CI 排队浪费分钟数。env: CI: truePlaywright 检测到该变量后会切换行为不输出彩色日志、改变重试与 reporter 逻辑也是playwright.config.ts中process.env.CI分支的开关。浏览器缓存双分支缓存未命中时npx playwright install --with-deps一次装齐浏览器二进制和 OS 系统依赖缓存命中时只补npx playwright install-deps系统库不在~/.cache/ms-playwright里属于 CI 常见坑详见第三节。报告与 trace 分级上传HTML 报告用if: ${{ !cancelled() }}只要没被取消就上传测试通过也有报告可看trace 用if: failure()只在失败时上传且保留期缩短14 天 vs 7 天。timeout-minutes: 30防止卡死的 Job 占用 runner 数小时。SurfSense 的 e2e-tests.yml 正是在这个骨架上做了工程化扩展pull_request增加了paths过滤仅当surfsense_web/**、surfsense_backend/**、docker/docker-compose.e2e.yml或工作流自身变更时才触发追加workflow_dispatch支持手动触发并用if: github.event.pull_request.draft false跳过草稿 PR依赖安装换成pnpm install --frozen-lockfileactions 版本也升级到了actions/checkoutv6、actions/cachev5、actions/upload-artifactv7等——照抄原文模板时版本号和包管理器请按实际仓库调整。三、浏览器缓存与 OS 依赖的双分支策略Missing dependencies 是浏览器缓存在 CI 上的第一坑这里把原文的排障结论与缓存模板放在一起讲透故障现象Browser launch fails: Missing dependencies根因浏览器二进制从缓存恢复了但 OS 系统依赖没有被缓存~/.cache/ms-playwright只存浏览器本体不含系统库。修法在缓存命中的分支显式补装系统依赖- name: Install OS dependencies if: steps.browser-cache.outputs.cache-hit true run: npx playwright install-deps对应的错误表两行不缓存浏览器每次运行白白浪费 60–90 秒漏掉--with-deps会导致浏览器启动失败——正确姿势永远是首次install --with-deps命中缓存时install-deps兜底。SurfSense 的真实实现在 e2e-tests.yml 中完整遵循了这个双分支只有两处项目化定制- name: Cache Playwright browsers id: playwright-cache uses: actions/cachev5 with: path: ~/.cache/ms-playwright key: playwright-${{ runner.os }}-${{ hashFiles(surfsense_web/pnpm-lock.yaml) }} - name: Install Playwright browsers if: steps.playwright-cache.outputs.cache-hit ! true working-directory: surfsense_web run: pnpm exec playwright install --with-deps chromium - name: Install Playwright system deps (cache hit) if: steps.playwright-cache.outputs.cache-hit true working-directory: surfsense_web run: pnpm exec playwright install-deps chromium缓存 key 哈希surfsense_web/pnpm-lock.yaml对应原文的package-lock.json保证依赖升级后缓存自动失效只安装chromiumplaywright.config.ts 的projects只有一个 chromium 项目与原文错误表中PR 上跑全浏览器使 CI 成本 x3的建议一致——PR 场景只保 Chromium跨浏览器留给主分支或定时任务。四、分片执行Sharded Execution适用测试套件超过 10 分钟分片能显著压缩 wall-clock 时间。避免套件不到 5 分钟时——分片开销会吃掉收益。# .github/workflows/e2e-sharded.yml name: E2E Tests (Sharded) on: push: branches: [main] pull_request: branches: [main] concurrency: group: e2e-${{ github.ref }} cancel-in-progress: true env: CI: true jobs: test: timeout-minutes: 20 runs-on: ubuntu-latest strategy: fail-fast: false matrix: shard: [1/4, 2/4, 3/4, 4/4] steps: - uses: actions/checkoutv4 - run: npm ci - name: Cache browsers id: browser-cache uses: actions/cachev4 with: path: ~/.cache/ms-playwright key: pw-${{ runner.os }}-${{ hashFiles(package-lock.json) }} - name: Install browsers if: steps.browser-cache.outputs.cache-hit ! true run: npx playwright install --with-deps - name: Install OS dependencies if: steps.browser-cache.outputs.cache-hit true run: npx playwright install-deps - name: Run tests (shard ${{ matrix.shard }}) run: npx playwright test --shard${{ matrix.shard }} - name: Upload blob report uses: actions/upload-artifactv4 if: ${{ !cancelled() }} with: name: blob-${{ strategy.job-index }} path: blob-report/ retention-days: 1 merge: if: ${{ !cancelled() }} needs: test runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm ci - name: Download blob reports uses: actions/download-artifactv4 with: path: all-blobs pattern: blob-* merge-multiple: true - name: Merge reports run: npx playwright merge-reports --reporterhtml ./all-blobs - name: Upload merged report uses: actions/upload-artifactv4 with: name: test-report path: playwright-report/ retention-days: 14分片链路有三个必须配套的环节缺一就会出现报告缺失fail-fast: false默认true时一个分片失败会取消其余分片导致 blob 不完整每个分片上传唯一命名的 blob 工件name: blob-${{ strategy.job-index }}保留期只需 1 天中间产物merge Job 合并download-artifact用pattern: blob-*merge-multiple: true把所有分片的 blob 拉到同一目录再npx playwright merge-reports --reporterhtml ./all-blobs合成统一报告。分片的前提是配置blob reporterHTML reporter 无法跨分片合并// playwright.config.ts import { defineConfig } from playwright/test; export default defineConfig({ reporter: process.env.CI ? [[blob], [github]] : [[html, { open: on-failure }]], });补充说明npx playwright merge-reports还可以指定多种输出格式如--reporterhtml,json,junit或用PLAYWRIGHT_HTML_REPORT环境变量自定义输出目录更完整的分片与 worker 调优策略动态分片数计算、worker 作用域 fixture、测试隔离写法参见同目录的 parallel-sharding.md。SurfSense 的当前选择是单分片串行playwright.config.ts 中workers: 1、fullyParallel: true、retries: process.env.CI ? 1 : 0CI 里不传--shard。从源码结构看这与其 hermetic 测试栈有关每次 CI 运行都要通过 docker compose 拉起一整套 Postgres/Redis/FastAPI/Celery 后端分片 matrix 会把这笔固定的环境启动开销乘以分片数同时旅程级journey测试对状态隔离要求高单分片 失败重试 1 次是更稳妥的组合。当套件规模增长后可参照上面的四分片模板引入 sharding——届时需要额外解决每个分片如何各起一套后端的问题例如用矩阵 job 各拉一套 compose 栈。五、容器化执行Container-Based Execution适用需要可复现、与本地 Docker 环境一致的环境或 runner 上 OS 依赖总是出问题。避免ubuntu-latest--with-deps已经能正常工作时。# .github/workflows/e2e-container.yml name: E2E Tests (Container) on: pull_request: branches: [main] jobs: test: timeout-minutes: 30 runs-on: ubuntu-latest container: image: mcr.microsoft.com/playwright:v1.48.0-noble steps: - uses: actions/checkoutv4 - run: npm ci - name: Run tests run: npx playwright test env: HOME: /root - uses: actions/upload-artifactv4 if: ${{ !cancelled() }} with: name: test-report path: playwright-report/ retention-days: 14两个关键点Playwright 官方镜像mcr.microsoft.com/playwright:vX.Y.Z-noble内置了浏览器和全部系统依赖因此不需要playwright install --with-deps步骤镜像 tag 应与项目 Playwright 版本对齐显式设置HOME: /root因为容器内浏览器安装在 root 用户目录下不设 HOME 时 Playwright 找不到已装的浏览器。容器镜像本身的选型与构建细节可参考同目录的 docker.md。值得注意的是SurfSense 并没有把整个 Job 放进 Playwright 官方镜像而是采用了后端容器化hermetic stack 前端跑在 runner 宿主侧的混合方案——后端放进容器是为了做网络隔离防真实外呼而 Playwright 官方镜像解决的是浏览器依赖问题两者目的不同。完整实现见第十二节。六、环境密钥与 Staging 冒烟测试Environment Secrets适用测试要打到带凭据的 staging/生产环境。避免测试只针对本地 dev server 时。# .github/workflows/e2e-staging.yml name: Staging Tests on: push: branches: [main] workflow_dispatch: jobs: test: timeout-minutes: 30 runs-on: ubuntu-latest environment: staging env: CI: true BASE_URL: ${{ vars.STAGING_URL }} TEST_USER_PASSWORD: ${{ secrets.TEST_USER_PASSWORD }} API_TOKEN: ${{ secrets.API_TOKEN }} steps: - uses: actions/checkoutv4 - run: npm ci - name: Cache browsers id: browser-cache uses: actions/cachev4 with: path: ~/.cache/ms-playwright key: pw-${{ runner.os }}-${{ hashFiles(package-lock.json) }} - name: Install browsers if: steps.browser-cache.outputs.cache-hit ! true run: npx playwright install --with-deps - name: Install OS dependencies if: steps.browser-cache.outputs.cache-hit true run: npx playwright install-deps - name: Run smoke tests run: npx playwright test --grep smoke - uses: actions/upload-artifactv4 if: ${{ !cancelled() }} with: name: staging-report path: playwright-report/ retention-days: 14要点environment: staging不仅是一个标签它把密钥的可见范围绑定到 GitHub Environment 级别可以配保护规则和审批人对应原文错误表中硬编码密钥 → 使用 GitHub Secrets 和 Environments非敏感的 URL 类配置走vars敏感凭据走secrets在env中注入到测试进程npx playwright test --grep smoke通过测试标签只跑冒烟子集——标签tag的打法和过滤机制见 test-tags.md。七、定时运行与失败通知Scheduled Runs适用全量回归太慢、不适合每个 PR 都跑——放到夜间定时执行。避免套件本身不到 15 分钟、完全可以随 PR 跑时。# .github/workflows/nightly.yml name: Nightly Regression on: schedule: - cron: 0 3 * * 1-5 workflow_dispatch: jobs: test: timeout-minutes: 60 runs-on: ubuntu-latest env: CI: true BASE_URL: ${{ vars.STAGING_URL }} steps: - uses: actions/checkoutv4 - run: npm ci - name: Install browsers run: npx playwright install --with-deps - name: Run full regression run: npx playwright test --grep regression - uses: actions/upload-artifactv4 if: ${{ !cancelled() }} with: name: nightly-${{ github.run_number }} path: playwright-report/ retention-days: 30 - name: Notify on failure if: failure() uses: slackapi/slack-github-actionlatest with: payload: | { text: Nightly regression failed: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }} } env: SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}要点cron: 0 3 * * 1-5为工作日凌晨 3 点触发workflow_dispatch允许随时手动补跑工件名带上nightly-${{ github.run_number }}让历史每次运行的报告互不覆盖保留期拉长到 30 天以便趋势回溯定时任务的失败没人盯着看所以必须有主动通知这里是 Slack webhook也可以换成 Teams/邮件等渠道注意schedule触发的运行只在默认分支上生效且延迟不可控关键场景应保留workflow_dispatch兜底。八、可复用工作流Reusable Workflow适用多个仓库共享同一套 Playwright 配置。避免单仓库、单工作流时。# .github/workflows/pw-reusable.yml name: Playwright Reusable on: workflow_call: inputs: node-version: type: string default: lts/* test-command: type: string default: npx playwright test secrets: BASE_URL: required: false TEST_PASSWORD: required: false jobs: test: timeout-minutes: 30 runs-on: ubuntu-latest env: CI: true BASE_URL: ${{ secrets.BASE_URL }} TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }} steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: ${{ inputs.node-version }} cache: npm - run: npm ci - name: Cache browsers id: browser-cache uses: actions/cachev4 with: path: ~/.cache/ms-playwright key: pw-${{ runner.os }}-${{ hashFiles(package-lock.json) }} - name: Install browsers if: steps.browser-cache.outputs.cache-hit ! true run: npx playwright install --with-deps - name: Install OS dependencies if: steps.browser-cache.outputs.cache-hit true run: npx playwright install-deps - name: Run tests run: ${{ inputs.test-command }} - uses: actions/upload-artifactv4 if: ${{ !cancelled() }} with: name: test-report path: playwright-report/ retention-days: 14调用方只需声明 inputs 并把自己仓库的 secrets 映射进去# .github/workflows/ci.yml name: CI on: pull_request: branches: [main] jobs: e2e: uses: ./.github/workflows/pw-reusable.yml with: node-version: lts/* secrets: BASE_URL: ${{ secrets.STAGING_URL }} TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}workflow_call使该工作流成为一个模板 Jobinputs定义可参数化项如test-commandsecrets声明需要调用方注入的凭据且均可选。同仓库内用uses: ./.github/workflows/...引用即可跨仓库共享。九、场景选型速查表原文给出的场景决策表直接作为选型依据场景建议做法小套件 5 min单 Job不分片中等套件5–20 min2–4 个分片的 matrix大套件20 min4–8 个分片 blob 合并PR 上的跨浏览器PR 只跑 Chromiummain 分支上全浏览器Staging/生产冒烟独立工作流 environment:夜间全量回归schedule触发 workflow_dispatch多仓库同一套配置可复用工作流workflow_call需要可复现环境使用 Playwright 镜像的容器 Job十、高频错误与修复原文总结的九个高频错误是审查 CI 配置时的核对清单错误后果修复没有concurrency组重复运行浪费分钟数加concurrency: { group: ..., cancel-in-progress: true }分片时fail-fast: true一个失败取消其余分片设为fail-fast: false不缓存浏览器每次运行浪费 60–90 秒缓存~/.cache/ms-playwright没有timeout-minutes卡死的 Job 跑满 6 小时显式设置 20–30 分钟超时工件只在失败时上传测试通过时看不到报告用if: ${{ !cancelled() }}硬编码密钥安全风险使用 GitHub Secrets 和 Environments每个 PR 都跑全浏览器CI 成本 x3PR 跑 Chromium跨浏览器留给 main不设工件保留期默认 90 天占满存储设retention-days: 7-14漏掉--with-deps浏览器启动失败始终使用npx playwright install --with-deps十一、常见故障排障本地通过、CI 超时原因CI runner 资源少于开发机。修复降低 worker 数、放宽超时// playwright.config.ts import { defineConfig } from playwright/test; export default defineConfig({ workers: process.env.CI ? 50% : undefined, use: { actionTimeout: process.env.CI ? 15_000 : 10_000, navigationTimeout: process.env.CI ? 30_000 : 15_000, }, });对照 SurfSense 的 playwright.config.ts它没有按CI/本地分别放宽动作超时而是直接固定了timeout: 30_000单测试、expect: { timeout: 15_000 }断言并把webServer.timeout在 CI 下放宽到300_000毫秒因为 CI 要执行pnpm build pnpm start编译启动明显慢于本地pnpm exec next dev的 180 秒——思路一致把慢显式配置化而不是让测试去猜。分片报告不完整原因工件命名冲突或download-artifact没开merge-multiple。修复每个分片用唯一名字上传合并 Job 开merge-multiple: true第四节模板已内置此修法。webServer报 port already in use原因上一次运行残留的僵尸进程占着端口。修复启动前清理- name: Kill stale processes run: lsof -ti:3000 | xargs kill -9 2/dev/null || trueSurfSense 的对应做法更声明式webServer.reuseExistingServer: !process.env.CI——CI 中强制不复用既有服务每次都起新实例避免残留状态本地开发时才允许复用已在运行的 dev server配合 CI 的 300 秒启动超时。PR 上看不到行内注释annotations原因没配置githubreporter。修复CI 下启用githubreporter// playwright.config.ts import { defineConfig } from playwright/test; export default defineConfig({ reporter: process.env.CI ? [[html, { open: never }], [github]] : [[html, { open: on-failure }]], });SurfSense 的 playwright.config.ts 正是这个模式的超集reporter: process.env.CI ? [[html, { open: never }], [github], [list]] : [[html, { open: on-failure }], [list]]——CI 中同时产出 HTML 报告上传为工件、githubreporter 的 PR 行内标注以及便于终端阅读的list输出本地则失败时自动打开 HTML。浏览器启动失败 Missing dependencies已在第三节完整展开缓存命中分支补npx playwright install-deps即可。十二、SurfSense 的完整 E2E CI 落地前面各节是通用模式这一节把 SurfSense 真实的 e2e-tests.yml 串起来说明这些模式如何组合成一个可落地的全栈 E2E 流水线。完整设计背景确定性测试桩的三层防护、本地运行步骤、新增连接器清单见 surfsense_web/tests/README.md。12.1 触发与并发控制工作流仅在pull_request目标main/dev事件类型opened/synchronize/reopened/ready_for_review且变更命中pathssurfsense_web/**、surfsense_backend/**、docker/docker-compose.e2e.yml、工作流自身时触发另支持workflow_dispatch。并发组${{ github.workflow }}-${{ github.ref }}cancel-in-progress: true与第二节模板一致Job 级timeout-minutes: 30草稿 PR 直接跳过。12.2 Hermetic 后端栈容器化 网络隔离与第五节容器 Job不同SurfSense 用 docker/docker-compose.e2e.yml 拉起一套与生产同构但完全隔离的后端dbpgvector/pg17 redis backendFastAPI celery_worker工作流中一行命令带健康门控docker compose -f docker/docker-compose.e2e.yml up -d --build --wait --wait-timeout 300这套配置的隔离设计值得逐条看三层出口拒绝L3 egress denydb/redis/celery_worker只挂在internal: true的桥接网络上——该网络没有到宿主机和互联网的路由只有backend额外挂在普通ingress网络上让 runner 宿主能访问:8000哨兵密钥 死代理COMPOSIO_API_KEY/OPENAI_API_KEY等全部置为e2e-deny-real-call-sentinel任何漏网的真实 API 调用会变成 401同时容器内HTTPS_PROXYhttp://127.0.0.1:1任何 Python 出站 HTTP 直接 Connection refusedHF_HUB_OFFLINE1/TRANSFORMERS_OFFLINE1禁止模型下载一次性存储Postgres 数据目录挂tmpfs每次 CI 运行拿到干净数据库无需清卷健康检查门控db 用pg_isreadybackend 用镜像内自带的 Python 请求/openapi.json避免依赖 curl/wgetcelery 用inspect ping配合--waitPlaywright 启动前所有服务必然就绪没有 curl 轮询循环构建缓存backend 镜像带cache_from/cache_to: typegha跨运行复用 Docker 构建层。12.3 测试用户准备与状态清理Playwright 运行前工作流先用curl调POST /auth/register注册测试用户e2e-testsurfsense.net接受 200/201新建或 400已存在跨重跑幂等其他状态码则::error::并退出随后清空 Redis 中surfsense:auth_rate_limit:*计数键让认证限流从干净状态开始。这两个环境变量PLAYWRIGHT_TEST_EMAIL/PLAYWRIGHT_TEST_PASSWORD与 playwright.config.ts 顶部的??默认值一致本地跑不需要额外导出任何变量。12.4 前端、webServer 与认证 setup 项目前端不在容器里Playwright 的webServer配置在 runner 宿主侧拉起 Next.js——CI 下执行pnpm build pnpm start生产构建与 CI 语义一致本地执行pnpm exec next dev并把NEXT_PUBLIC_FASTAPI_BACKEND_URL、AUTH_TYPELOCAL、NEXT_PUBLIC_ZERO_CACHE_URL等注入给 dev server。CI 侧还额外缓存了surfsense_web/.next/cacheNext.js 构建缓存按pnpm-lock.yaml哈希 commit SHA 分级 key进一步压缩构建时间。认证采用独立的setup项目playwright.config.ts 中projects先跑auth.setup.tstestMatch: /.*\.setup\.ts/chromium 项目声明dependencies: [setup]并加载storageState: playwright/.auth/user.json。auth.setup.ts 的逻辑是通过测试专用接口获取 bearer token → 解码 JWT 中的用户 id → 预置localStorage里的公告已读态与 onboarding 标记避免弹窗遮挡旅程中的点击→ 写入会话 cookie →page.context().storageState({ path })持久化登录态使所有测试天生已登录。关键配置参数一览均取自 playwright.config.ts参数取值作用testDir./tests测试目录tests/不进入生产构建timeout/expect.timeout30_000/15_000单测试与断言超时fullyParalleltrue文件内测试并行配workers: 1则实际为单 worker 内顺序消费forbidOnly!!process.env.CICI 中禁止遗留test.onlyretriesCI ? 1 : 0CI 失败重试一次过滤偶发抖动traceon-first-retry只在首次重试时录 trace控制磁盘占用screenshot/videoonly-on-failure/CI 下 off失败截图CI 不录视频extraHTTPHeadersx-playwright-test: true让服务端识别测试流量webServerCI:pnpm build pnpm start300s 超时自动拉起并等待前端就绪12.5 失败诊断、工件与拆卸运行pnpm test:e2e:prod即cross-env CI1 playwright test与本地生产模式脚本完全一致失败取证failure() || cancelled()时把 compose 全量日志和 db/redis/backend/celery_worker 逐服务日志落盘连同ps状态一起作为backend-stack-logs工件上传保留 7 天——排障时不用猜容器内部发生了什么工件分级playwright-reportif: always()14 天、playwright-tracesif: failure()14 天、后端日志失败时7 天正是第二节报告/trace 分级上传模板在多服务场景下的扩展拆卸if: always() docker compose ... down -v --remove-orphans保证无论成败都清理栈与卷runner 不留状态。十三、相关文档test-tags.md — 测试打标签与过滤--grep smoke等parallel-sharding.md — worker 调优与分片策略docker.md — Playwright 容器镜像gitlab.md — GitLab CI 等价方案other-providers.md — CircleCI、Azure DevOps、Jenkinssurfsense_web/tests/README.md — SurfSense E2E 测试栈的完整设计说明【免费下载链接】SurfSenseOpen-source NotebookLM alternative. Research the open web with live data(Reddit, YT, IG, TikTok, Indeed, Google Search, Maps etc) through one platform, API or MCP server. Join our Discord: https://discord.gg/ejRNvftDp9项目地址: https://gitcode.com/GitHub_Trending/su/SurfSense创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考