fix(ci): 修复2个P0级bug - acr-cleanup完全不可用 + production-e2e DooD必然失败 #1112

Merged

xiaoxia merged 1 commits from fix/ci-p0-bugs-0728 into main 2026-07-28 15:58:05 +08:00

Conversation 2 Commits 1 Files Changed 2

+31 -12

xiaoxia commented 2026-07-28 15:56:14 +08:00

Owner

Copy Link

Copy Source

P0 修复（2个）

1. acr-cleanup.yml 完全不可用

• Bug: $GITEA_OUTPUT 写错（应为 $GITHUB_OUTPUT），白名单outputs完全失效
• Bug: SSH密钥用的是 PREVIEW_SSH_KEY（应为 STAGING_SSH_KEY），可能不匹配
• Bug: STAGING_SSH_HOST/PORT/USER 没从secret读，默认值可能不准
• 影响: 独立ACR清理完全失效，白名单不工作可能误删在用镜像

2. production-e2e DooD模式下必然失败

• Bug: 用 -v "$PWD:/workspace" 挂载，DooD模式下挂载的是宿主机路径，代码根本进不去
• 修复: 改用 docker create + docker cp 模式（与staging-e2e一致）
• 影响: 生产E2E永远是假的，测了个寂寞

两个都是P0级，建议快速合入。

## P0 修复（2个） ### 1. acr-cleanup.yml 完全不可用 - **Bug**: `$GITEA_OUTPUT` 写错（应为 `$GITHUB_OUTPUT`），白名单outputs完全失效 - **Bug**: SSH密钥用的是 `PREVIEW_SSH_KEY`（应为 `STAGING_SSH_KEY`），可能不匹配 - **Bug**: `STAGING_SSH_HOST/PORT/USER` 没从secret读，默认值可能不准 - **影响**: 独立ACR清理完全失效，白名单不工作可能误删在用镜像 ### 2. production-e2e DooD模式下必然失败 - **Bug**: 用 `-v "$PWD:/workspace"` 挂载，DooD模式下挂载的是宿主机路径，代码根本进不去 - **修复**: 改用 `docker create + docker cp` 模式（与staging-e2e一致） - **影响**: 生产E2E永远是假的，测了个寂寞 两个都是P0级，建议快速合入。

xiaoxia added 1 commit 2026-07-28 15:56:14 +08:00

fix(ci): 修复2个P0级bug ... 3353865f5b

P0-1: acr-cleanup.yml 完全不可用
- $GITEA_OUTPUT → $GITHUB_OUTPUT（outputs写入完全失效）
- PREVIEW_SSH_KEY → STAGING_SSH_KEY（用错了密钥）
- 增加 STAGING_SSH_HOST/PORT/USER 从secret读取
- SSH连接用户从写死root改为变量

P0-2: production-e2e DooD模式下必然失败
- -v "$PWD:/workspace" 改为 docker create + docker cp 模式
- 与 staging-e2e 保持一致

xiaoxia merged commit 4749071c16 into main 2026-07-28 15:58:05 +08:00

gitea-actions bot commented 2026-07-28 16:17:14 +08:00

Copy Link

Copy Source

🗑️ 预览环境已清理

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

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

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

auto-approve-bot commented 2026-07-28 16:19:54 +08:00

Collaborator

Copy Link

Copy Source

【阻塞级判定】

• 是否存在阻塞级问题：是
• 阻塞级问题数量：2 个

📊 审查概览

• 整体评价：需修改
• 建议级问题数量：0 个

🔴 阻塞级问题（必须修复）

1. [.gitea/workflows/ci-pipeline.yml: 1496-1497] Docker 拷贝遗漏 package.json

   • 问题类型：逻辑bug
   • 问题描述：代码中使用 docker cp 将 apps 目录和 package-lock.json 拷贝到容器中，但遗漏了根目录的 package.json。npm ci 命令通常需要 package.json 和 package-lock.json 配对使用来验证依赖树的一致性。缺少 package.json 将导致 npm ci 执行失败或无法正确还原依赖。
   • 修改建议：在 docker cp package-lock.json ... 之前或之后，添加 docker cp package.json "$CONTAINER_NAME:/workspace/"。

2. [.gitea/workflows/ci-pipeline.yml: 1489-1504] 容器资源泄漏风险

   • 问题类型：数据损坏风险
   • 问题描述：将原本的 docker run --rm（自动清理）改为手动管理容器生命周期（create -> cp -> start -> rm），但未添加 trap 捕获异常退出信号。如果在 docker cp 或 docker start 阶段脚本因错误退出（如 set -eu 触发），docker rm 将不会被执行，导致僵尸容器在 CI 节点上累积，消耗系统资源。
   • 修改建议：在脚本开头添加 trap 'docker rm -f "$CONTAINER_NAME" 2>/dev/null' EXIT，确保无论脚本是否成功退出都会清理容器。

💡 改进建议（不阻塞合并）

无

✅ 良好实践

1. [acr-cleanup.yml] 使用 printf '%s\n' 代替 echo 写入 SSH 私钥，有效避免了 echo 对转义字符的潜在解析问题，提升了安全性。
2. [acr-cleanup.yml] 增加了对 STAGING_SSH_KEY 是否存在的显式检查，并在缺失时优雅跳过，避免了后续 SSH 连接失败报错，增强了健壮性。
3. [ci-pipeline.yml] 针对无法使用 -v 挂载的场景，采用 docker create + docker cp 的变通方案是合理的工程实践。

---

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

### 【阻塞级判定】 - 是否存在阻塞级问题：是 - 阻塞级问题数量：2 个 ### 📊 审查概览 - 整体评价：需修改 - 建议级问题数量：0 个 ### 🔴 阻塞级问题（必须修复） 1. **[.gitea/workflows/ci-pipeline.yml: 1496-1497] Docker 拷贝遗漏 package.json** - 问题类型：逻辑bug - 问题描述：代码中使用 `docker cp` 将 `apps` 目录和 `package-lock.json` 拷贝到容器中，但遗漏了根目录的 `package.json`。`npm ci` 命令通常需要 `package.json` 和 `package-lock.json` 配对使用来验证依赖树的一致性。缺少 `package.json` 将导致 `npm ci` 执行失败或无法正确还原依赖。 - 修改建议：在 `docker cp package-lock.json ...` 之前或之后，添加 `docker cp package.json "$CONTAINER_NAME:/workspace/"`。 2. **[.gitea/workflows/ci-pipeline.yml: 1489-1504] 容器资源泄漏风险** - 问题类型：数据损坏风险 - 问题描述：将原本的 `docker run --rm`（自动清理）改为手动管理容器生命周期（create -> cp -> start -> rm），但未添加 `trap` 捕获异常退出信号。如果在 `docker cp` 或 `docker start` 阶段脚本因错误退出（如 `set -eu` 触发），`docker rm` 将不会被执行，导致僵尸容器在 CI 节点上累积，消耗系统资源。 - 修改建议：在脚本开头添加 `trap 'docker rm -f "$CONTAINER_NAME" 2>/dev/null' EXIT`，确保无论脚本是否成功退出都会清理容器。 ### 💡 改进建议（不阻塞合并） 无 ### ✅ 良好实践 1. **[acr-cleanup.yml]** 使用 `printf '%s\n'` 代替 `echo` 写入 SSH 私钥，有效避免了 `echo` 对转义字符的潜在解析问题，提升了安全性。 2. **[acr-cleanup.yml]** 增加了对 `STAGING_SSH_KEY` 是否存在的显式检查，并在缺失时优雅跳过，避免了后续 SSH 连接失败报错，增强了健壮性。 3. **[ci-pipeline.yml]** 针对无法使用 `-v` 挂载的场景，采用 `docker create` + `docker cp` 的变通方案是合理的工程实践。 --- _{🤖 由 AI 代码审查机器人自动生成 | 2026-07-28 08:19:54 | 模型:} <!-- AI_CODE_REVIEW_AUTO_COMMENT -->

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#1112