企业官网建设流程全解析

在 HPC Dashboard 项目中，我使用 Playwright + TypeScript 编写了 E2E 自动化测试。

本地运行时，可以先启动前后端服务，再执行 Playwright 测试。或者直接使用docker。为了减少手动操作，我使用Docker Compose + GitHub Actions将这个过程自动化。

1. Docker Compose 和 GitHub Actions 分别负责什么？

简单来说：

• Docker Compose：负责启动 HPC Dashboard 的应用服务。
• GitHub Actions：负责按照 Workflow 中定义的步骤自动执行任务。
• Playwright：负责运行 E2E 测试，验证 Web 应用功能。

我的被测项目是private的 ，token一直没批准，没法在自动化测试这个项目里面写脚本直接跑e2e测试。但是我有权限修改private库的代码。原项目本来我就写好了GitHub Action以及项目前后端的测试，还有C1CD这块。于是为了这个自动化ui demo。我直接在被测项目workflows下面新建一个脚本，加一个playwright的e2e测试。
所以这个代码和测试代码分别存放在两个仓库中，因此 Workflow 需要获取两份代码。

-name:Checkout HPC Dashboarduses:actions/checkout@v4-name:Checkout Playwright test repositoryuses:actions/checkout@v4with:repository:xxx/HPC-dashboard-test-automationpath:playwright-tests

其中path: playwright-tests表示将测试仓库检出到指定目录。

2. 启动应用并等待服务就绪

首先，通过 Docker Compose 构建并启动应用：

-name:Start HPC Dashboardrun:docker compose up-d--build

这里：

• up：创建并启动服务。
• -d：让容器在后台运行。
• --build：启动前构建所需镜像。

但容器启动不代表 Web 服务已经可以访问。因此，我增加了服务就绪检查：

foriin{1..60};doifcurl--fail--silenthttp://localhost:5001/openapi.json>/dev/null\&&curl--fail--silenthttp://localhost:5173/>/dev/null;thenecho"Backend and frontend are ready"exit0fisleep5done

这段脚本每隔 5 秒检查一次前后端地址，最多检查 60 次。

只有两个地址都能成功响应，才继续执行测试；否则最终报错退出。

这样可以避免应用还没准备好，Playwright 就开始访问页面。

3. 安装依赖并执行 Playwright

服务就绪后，GitHub Actions 安装 Node.js、项目依赖和 Chromium：

-name:Install Playwright dependenciesworking-directory:playwright-testsrun:|npm ci npx playwright install --with-deps chromium

然后执行 E2E 测试：

-name:Run Playwright E2E testsworking-directory:playwright-testsrun:npx playwright test--config=playwright.e2e.config.ts

这里使用了独立的playwright.e2e.config.ts，指定 CI 执行时采用的测试配置。

需要注意，Playwright 测试运行在 GitHub Actions 的 Ubuntu Runner 上，而 HPC Dashboard 应用服务运行在 Docker 容器中。

4. 保存测试报告并清理环境

为了方便查看测试结果，我配置了报告上传：

-name:Upload Playwright reportif:always()uses:actions/upload-artifact@v4with:name:playwright-e2e-reportpath:|playwright-tests/playwright-report/ playwright-tests/test-results/retention-days:30

if: always()表示即使前面的测试失败，也会尝试执行报告上传步骤。

另外，Workflow 还配置了失败时输出 Docker 日志，以及最后清理容器：

-name:Stop HPC Dashboardif:always()run:docker compose down-v

docker compose down -v会停止并移除相关容器、网络和 Compose 管理的卷，因此适合用于一次性的 CI 测试环境。

5. 总结

这次 CI 集成实现了以下自动化流程：

手动触发 GitHub Actions → Docker Compose 启动应用 → 检查服务就绪 → Playwright 执行 E2E 测试 → 上传报告 → 清理环境。

通过这套流程，我不再需要每次手动启动应用并执行测试，也可以在 GitHub Actions 中查看测试结果。

目前 Workflow 使用workflow_dispatch手动触发。如果有权限，理想中应该增加push或pull_request触发条件，让代码每次git push更新时自动执行 E2E 测试。