fix(ci): 修复 staging 测试 shell 引号嵌套 bug，测试从未实际运行 #1290

Merged

xiaoxia merged 2 commits from bugfix/1286-staging-ci-shell-quoting into develop 2026-08-07 23:00:57 +08:00

Conversation 3 Commits 2 Files Changed 6

+486 -45

xiaoxia commented 2026-08-07 22:37:30 +08:00

Owner

Copy Link

Copy Source

问题

.gitea/workflows/ci-pipeline.yml 中两个 staging 测试 job 的 docker create 命令存在 shell 引号嵌套 bug，导致测试从未实际运行过。

Bug 1: Staging E2E Tests

• sh -lc "...\$i..." 双引号导致 $i 被外层 bash 展开为 unbound variable

Bug 2: Staging API Integration Tests

• sh -lc '...\"...\"...' 单引号内 \" 是字面反斜杠+引号，dash 报 Syntax error

Bug 3: Production Browser E2E

同样的引号问题

修复方案

提取 docker run 逻辑为独立脚本 scripts/ci/run_staging_tests.sh：

1. 容器内用 bash -c '...'（单引号保护，$i 不会被外层展开）
2. 用 bash 替代 sh（dash），避免引号解析差异
3. echo 内用裸双引号（在单引号保护下是字面字符）
4. YAML 中简化为一行调用：bash scripts/ci/run_staging_tests.sh e2e|api

验收标准

• CI 的 Staging E2E Tests 和 Staging API Integration Tests 两个 job 能实际跑起 Playwright 测试
• 不再出现 unbound variable 或 Syntax error 脚本级错误
• Production Browser E2E 同样修复

## 问题 `.gitea/workflows/ci-pipeline.yml` 中两个 staging 测试 job 的 `docker create` 命令存在 shell 引号嵌套 bug，导致测试从未实际运行过。 ### Bug 1: Staging E2E Tests - `sh -lc "...\$i..."` 双引号导致 `$i` 被外层 bash 展开为 `unbound variable` ### Bug 2: Staging API Integration Tests - `sh -lc '...\"...\"...'` 单引号内 `\"` 是字面反斜杠+引号，dash 报 `Syntax error` ### Bug 3: Production Browser E2E 同样的引号问题 ## 修复方案 提取 docker run 逻辑为独立脚本 `scripts/ci/run_staging_tests.sh`： 1. 容器内用 `bash -c '...'`（单引号保护，`$i` 不会被外层展开） 2. 用 `bash` 替代 `sh`（dash），避免引号解析差异 3. echo 内用裸双引号（在单引号保护下是字面字符） 4. YAML 中简化为一行调用：`bash scripts/ci/run_staging_tests.sh e2e|api` ## 验收标准 - CI 的 Staging E2E Tests 和 Staging API Integration Tests 两个 job 能实际跑起 Playwright 测试 - 不再出现 `unbound variable` 或 `Syntax error` 脚本级错误 - Production Browser E2E 同样修复

xiaoxia added 1 commit 2026-08-07 22:37:30 +08:00

fix(ci): 修复 staging 测试 shell 引号嵌套 bug，测试从未实际运行 ... 38794923d7

根因：
1. E2E Tests: sh -lc "...$i..." 双引号导致 $i 被外层 bash 展开为 unbound variable
2. API Tests: sh -lc '...\"...\"...' 单引号内 \" 是字面反斜杠+引号，dash 报 Syntax error
3. Production E2E 同样存在引号问题

修复：
- 提取 docker run 逻辑为 scripts/ci/run_staging_tests.sh
- 容器内用 bash -c '...'（单引号保护，$i 不会被外层展开）
- 用 bash 替代 sh（dash），避免引号解析差异
- YAML 中简化为 bash scripts/ci/run_staging_tests.sh e2e|api
- Production E2E 同样修复为 bash -c '...'

gitea-actions bot commented 2026-08-07 22:38:55 +08:00

Copy Link

Copy Source

🚀 预览环境已部署

项目	详情
PR号	#1290
预览链接	https://pr-1290.preview.xiaoxiajianji.com
API环境	staging

💡 预览环境使用 staging API 数据，请勿在预览环境中操作重要数据。

🔄 每次提交新代码后预览环境会自动更新。

🗑️ PR 关闭或合并后，预览环境会自动清理。

🚀 **预览环境已部署** | 项目 | 详情 | |------|------| | PR号 | #1290 | | 预览链接 | [https://pr-1290.preview.xiaoxiajianji.com](https://pr-1290.preview.xiaoxiajianji.com) | | API环境 | staging | > 💡 预览环境使用 staging API 数据，请勿在预览环境中操作重要数据。 > > 🔄 每次提交新代码后预览环境会自动更新。 > > 🗑️ PR 关闭或合并后，预览环境会自动清理。

auto-approve-bot commented 2026-08-07 22:40:13 +08:00

Collaborator

Copy Link

Copy Source

代码审查结果 - PR #1290

⚠️ 问题（1个需要修改）

1. scripts/ci/run_staging_tests.sh 第25行、第33行：严重逻辑错误，导致依赖安装失败时CI误判为通过。
   • 在 docker create ... bash -c '...' 的命令字符串中，重试逻辑 for ...; do npm ci ... && break; ...; done && npx ... 缺少 set -e。
   • 当 npm ci 连续3次失败后，循环结束。由于没有 set -e，该命令段的退出状态由最后一条命令 sleep 15 决定（退出码0），导致 && npx ... 被跳过，但容器整体以状态码0退出。
   • 后果：即使依赖安装失败，CI Pipeline 也会显示绿色（成功），且未执行任何测试。
   • 同样的问题也存在于 .gitea/workflows/ci-pipeline.yml 第1473行 的 Production E2E 测试步骤中。
   • 修改建议：在 bash -c 引用的字符串开头添加 set -e;。例如：bash -c 'set -e; for i in 1 2 3; do ...'。

💡 建议（1个可选）

1. .gitea/workflows/ci-pipeline.yml 第1469行：建议恢复 set -eu。
   • 在重构中移除了 set -eu，虽然 docker run 的退出码通常能正确传递，但保留 set -eu 能确保脚本在遇到未定义变量等意外情况时立即报错，提高 CI 脚本的健壮性。

---

✅ 格式检查通过 | ❌ 逻辑审查需修改 | ✅ 性能良好

---

_{🤖 由 AI 代码审查机器人自动生成 | 2026-08-07 14:40:13 | 模型:}

## 代码审查结果 - PR #1290 ### ⚠️ 问题（1个需要修改） 1. **scripts/ci/run_staging_tests.sh 第25行、第33行**：**严重逻辑错误**，导致依赖安装失败时CI误判为通过。 - 在 `docker create ... bash -c '...'` 的命令字符串中，重试逻辑 `for ...; do npm ci ... && break; ...; done && npx ...` 缺少 `set -e`。 - 当 `npm ci` 连续3次失败后，循环结束。由于没有 `set -e`，该命令段的退出状态由最后一条命令 `sleep 15` 决定（退出码0），导致 `&& npx ...` 被跳过，但容器整体以状态码0退出。 - **后果**：即使依赖安装失败，CI Pipeline 也会显示绿色（成功），且未执行任何测试。 - **同样的问题也存在于** `.gitea/workflows/ci-pipeline.yml 第1473行` 的 Production E2E 测试步骤中。 - **修改建议**：在 `bash -c` 引用的字符串开头添加 `set -e;`。例如：`bash -c 'set -e; for i in 1 2 3; do ...'`。 ### 💡 建议（1个可选） 1. **.gitea/workflows/ci-pipeline.yml 第1469行**：建议恢复 `set -eu`。 - 在重构中移除了 `set -eu`，虽然 `docker run` 的退出码通常能正确传递，但保留 `set -eu` 能确保脚本在遇到未定义变量等意外情况时立即报错，提高 CI 脚本的健壮性。 --- ✅ 格式检查通过 | ❌ 逻辑审查需修改 | ✅ 性能良好 --- _{🤖 由 AI 代码审查机器人自动生成 | 2026-08-07 14:40:13 | 模型:} <!-- AI_CODE_REVIEW_AUTO_COMMENT -->

xiaoxia added 1 commit 2026-08-07 22:49:14 +08:00

fix: #1286 can_generate 增加最后防线自动修复，解决「没有可渲染的就绪片段」报错 (#1288) 2014eaf745

xiaoxia merged commit 042f4162b0 into develop 2026-08-07 23:00:57 +08:00

gitea-actions bot commented 2026-08-07 23:01:48 +08:00

Copy Link

Copy Source

🗑️ 预览环境已清理

PR #1290 已关闭或合并，对应的预览环境已被清理。

如有需要，可以重新打开 PR 来重新生成预览环境。

🗑️ **预览环境已清理** PR #1290 已关闭或合并，对应的预览环境已被清理。 > 如有需要，可以重新打开 PR 来重新生成预览环境。

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

P0

阻塞性，必须立即处理

P1

高优先级

P2

中优先级

P3

低优先级/后考虑

architecture

架构设计

backend

后端相关

blocked

阻塞中

bug

Bug修复

ci-bug

CI本身的bug

ci-optimization

CI优化类任务

ci-pipeline

CI流水线/workflow相关

cleanup

代码清理

devops

运维/部署/CI

documentation

文档相关

feature

新功能

frontend

前端相关

question

需要讨论确认

ready

PR CI通过，可合并

refactor

代码重构

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

auto-approve-bot xiaoxia

No Assignees

3 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: xiaoxia/xiaoxia-saas#1290