feat: 实现环境变量预设功能 & 移除稀疏检出
## 后端改动 - 添加 Project.envPresets 字段（JSON 格式） - 移除 Deployment.env 字段，统一使用 envVars - 更新部署 DTO，支持 envVars (Record<string, string>) - pipeline-runner 支持解析并注入 envVars 到环境 - 移除稀疏检出模板和相关环境变量 - 优化代码格式（Biome lint & format） ## 前端改动 - 新增 EnvPresetsEditor 组件（支持单选/多选/输入框类型） - 项目创建/编辑界面集成环境预设编辑器 - 部署界面基于预设动态生成环境变量表单 - 移除稀疏检出表单项 - 项目详情页添加环境变量预设配置 tab - 优化部署界面布局（基本参数 & 环境变量分区） ## 文档 - 添加完整文档目录结构（docs/） - 创建设计文档 design-0005（部署流程重构） - 添加 API 文档、架构设计文档等 ## 数据库 - 执行 prisma db push 同步 schema 变更
This commit is contained in:
26
docs/architecture/adr-0001-service-design.md
Normal file
26
docs/architecture/adr-0001-service-design.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: ADR 0001 - 服务设计决策
|
||||
date: 2026-01-03
|
||||
authors:
|
||||
- backend-team
|
||||
status: accepted
|
||||
---
|
||||
|
||||
# ADR 0001: 服务设计与部署模型
|
||||
|
||||
## 背景
|
||||
|
||||
需要选择微服务还是单体部署以便平衡开发速度与运维复杂度。
|
||||
|
||||
## 决策
|
||||
|
||||
采用模块化单体（modular monolith）作为初始阶段部署方式，关键模块解耦、接口明确，后续按需拆分服务。
|
||||
|
||||
## 影响
|
||||
|
||||
- 优点：降低初期运维成本，便于本地调试与 CI 集成。
|
||||
- 缺点：需要在代码边界设计中预留拆分点。
|
||||
|
||||
## 备注
|
||||
|
||||
在拆分时优先考虑数据库边界和独立部署能力。
|
||||
175
docs/architecture/design-0001-product-prototype.md
Normal file
175
docs/architecture/design-0001-product-prototype.md
Normal file
@@ -0,0 +1,175 @@
|
||||
---
|
||||
title: 设计文档 0001 - 产品原型
|
||||
summary: 产品的设计原型
|
||||
owners:
|
||||
- team: backend
|
||||
reviewers:
|
||||
- ops-team
|
||||
status: draft
|
||||
date: 2026-01-03
|
||||
version: 0.1.0
|
||||
---
|
||||
|
||||
# 设计文档 0001：产品整体原型
|
||||
|
||||
## 1. 背景（Context）
|
||||
|
||||
企业内部代码发布是非常频繁的事情，无论是测试环境还是生产环境，发布代码常常面临着一些痛点：频繁发布浪费开发时；手动发布代码可能漏掉某些步骤、造成环境报错。所以需要引入 CI/CD 工具让发布流程自动化，市场上已经存在很多解决类似问题的产品，例如 Drone CI、jenkins 等，但是这些工具不够灵活、不能满足全部场景，所以便有了 Foka-CI 这款产品。
|
||||
|
||||
## 2. 拆解需求
|
||||
|
||||
### 登录认证页面
|
||||
|
||||
仅提供 Gitea 的 OAuth 认证登录，方便获取仓库信息，简化密码登录过程
|
||||
|
||||
### 项目列表页面
|
||||
|
||||
查看所有项目，项目的基本信息有：
|
||||
|
||||
- 项目名
|
||||
- 项目描述（可选）
|
||||
- 代码仓库地址
|
||||
- 项目的工作目录，用于将代码克隆到该目录下，发布流水线脚本在该目录下执行
|
||||
|
||||
创建项目，需要填写基本信息
|
||||
|
||||
### 项目详情页
|
||||
|
||||
|
||||
## 2. 目标（Goals）
|
||||
|
||||
- [ ] 明确“部署任务”从创建到执行的状态流转与约束
|
||||
- [ ] 明确重试语义（retry 会创建新 deployment，而不是复用原记录）
|
||||
- [ ] 降低重复入队/重复执行的风险（幂等与并发边界清晰）
|
||||
- [ ] 让运维/排障更容易：关键日志点与可观测性清单
|
||||
|
||||
## 3. 非目标（Non-goals）
|
||||
|
||||
- 不引入外部消息队列（如 Redis/Kafka），仍以当前内存队列 + DB 恢复为基础
|
||||
- 不在本文直接实现大规模调度/分布式 runner（后续 ADR/设计再做）
|
||||
|
||||
## 4. 需求与范围（Requirements & Scope）
|
||||
|
||||
### 功能需求
|
||||
|
||||
- 创建部署：写入一条 Deployment 记录，初始状态为 `pending`，并加入执行队列
|
||||
- 重试部署：通过 `/deployments/:id/retry` 创建一条新的 Deployment 记录（复制必要字段），并加入执行队列
|
||||
- 服务重启恢复：服务启动后能从 DB 找回仍为 `pending` 的任务并继续执行
|
||||
|
||||
### 非功能需求
|
||||
|
||||
- 可靠性：服务重启不会“丢任务”（pending 的任务能恢复）
|
||||
- 幂等性：避免同一个 deployment 被重复执行
|
||||
- 可观测性：能定位某次部署为何失败、何时开始/结束、队列长度
|
||||
|
||||
## 5. 方案概览（High-level Design）
|
||||
|
||||
当前方案核心链路如下：
|
||||
|
||||
1. API 创建 Deployment（status=pending）
|
||||
2. `ExecutionQueue.addTask(deploymentId, pipelineId)` 入队
|
||||
3. `ExecutionQueue.processQueue()` 串行消费 `pendingQueue`
|
||||
4. `executePipeline()` 会读取 Deployment 与关联 Project，获取 `projectDir`，然后创建 `PipelineRunner` 执行
|
||||
5. 定时轮询：每 30 秒扫描 DB 中的 pending 任务，若不在 `runningDeployments` 集合则补入队列
|
||||
|
||||
## 6. 详细设计（Detailed Design）
|
||||
|
||||
### 6.1 接口/API 设计
|
||||
|
||||
#### 创建部署
|
||||
|
||||
- POST `/api/deployments`
|
||||
- 行为：创建 Deployment 后立即入队
|
||||
|
||||
#### 重试部署
|
||||
|
||||
- POST `/api/deployments/:id/retry`
|
||||
- 行为：读取原 deployment -> 创建新 deployment（status=pending）-> 入队
|
||||
- 语义：重试是“创建一个新的任务实例”，便于保留历史执行记录
|
||||
|
||||
### 6.2 数据模型/数据库
|
||||
|
||||
Deployment 当前关键字段（见 schema 注释）：
|
||||
|
||||
- `status`: pending/running/success/failed/cancelled（目前入队依赖 pending）
|
||||
- `buildLog`: 执行日志（当前创建时写空字符串）
|
||||
- `startedAt`/`finishedAt`: 时间标记（目前 created 时 startedAt 默认 now）
|
||||
|
||||
建议补齐/明确（文档层面约束，代码后续落地）：
|
||||
|
||||
- 状态迁移：
|
||||
- `pending` -> `running`（开始执行前）
|
||||
- `running` -> `success|failed|cancelled`（结束后）
|
||||
- 幂等控制：
|
||||
- 以 deploymentId 为“单次执行唯一标识”，同一个 deploymentId 不允许重复开始执行
|
||||
|
||||
### 6.3 队列/轮询/并发
|
||||
|
||||
现状：
|
||||
|
||||
- `runningDeployments` 同时承担“已入队/执行中”的去重集合
|
||||
- `pendingQueue` 为内存 FIFO
|
||||
- 单实例串行消费（`processQueue` while 循环）
|
||||
- 轮询间隔常量 30 秒
|
||||
|
||||
风险点（需要在文档中明确约束/后续逐步修正）：
|
||||
|
||||
- 多实例部署：如果将来启动多个 server 实例，每个实例都可能轮询到同一条 pending 记录并执行（需要 DB 锁/租约/状态原子更新）
|
||||
- 状态更新缺口：当前 `ExecutionQueue` 代码中没有看到明确把 status 从 pending 改成 running/failed/success 的逻辑（可能在 `PipelineRunner` 内处理；若没有，需要补齐）
|
||||
|
||||
建议（不改变整体架构前提）：
|
||||
|
||||
- 将轮询间隔改为可配置 env：`EXECUTION_POLL_INTERVAL_MS`（默认 30000）
|
||||
- 在真正执行前做一次 DB 原子“抢占”：仅当 status=pending 时更新为 running（并记录开始时间）；更新失败则放弃执行
|
||||
|
||||
### 6.4 可观测性
|
||||
|
||||
最低要求（建议后续落地到代码/日志规范）：
|
||||
|
||||
- 日志字段：deploymentId、pipelineId、projectId、projectDir、status
|
||||
- 队列指标：pendingQueue length、runningDeployments size
|
||||
- 失败记录：捕获异常 message/stack（避免泄露敏感信息）
|
||||
|
||||
### 6.5 安全与权限
|
||||
|
||||
当前接口层面需要确认：
|
||||
|
||||
- `/api/deployments` 与 `/api/deployments/:id/retry` 是否需要登录/鉴权（取决于 middleware 配置）
|
||||
- 若需要鉴权：建议限制为有项目权限的用户才能创建/重试部署
|
||||
|
||||
## 7. 影响与权衡（Trade-offs）
|
||||
|
||||
- 继续采用内存队列：实现简单，但天然不支持多实例并发安全
|
||||
- DB 轮询恢复：可靠性提升，但会带来额外 DB 查询压力
|
||||
|
||||
## 8. 兼容性与迁移（Compatibility & Migration）
|
||||
|
||||
- 文档层面不破坏现有 API
|
||||
- 若引入 status 原子抢占，需要确保旧数据/旧状态兼容（例如对历史 pending 记录仍可恢复）
|
||||
|
||||
## 9. 测试计划（Test Plan）
|
||||
|
||||
- 集成链路：创建 deployment -> 入队 -> 触发执行（可用假 runner）
|
||||
- 重启恢复：插入 pending 记录 -> initialize() -> 任务被 addTask
|
||||
- 重试接口：原记录存在/不存在的分支
|
||||
|
||||
## 10. 发布计划（Rollout Plan）
|
||||
|
||||
- 先补齐文档 + 最小日志规范
|
||||
- 再逐步落地：status 原子抢占 + 轮询间隔 env
|
||||
|
||||
## 11. 备选方案（Alternatives Considered）
|
||||
|
||||
- 引入 Redis 队列（BullMQ 等）：更可靠、支持多实例，但复杂度上升
|
||||
- 使用 DB 作为队列（表 + 锁/租约）：更可靠，但需要严格的并发控制
|
||||
|
||||
## 12. 风险与开放问题（Risks & Open Questions）
|
||||
|
||||
- Q1：`PipelineRunner` 是否负责更新 Deployment.status？如果没有，状态机应由谁维护？
|
||||
- Q2：服务是否计划多实例部署？如果是，必须补齐“抢占执行”机制
|
||||
|
||||
## 13. 附录（Appendix）
|
||||
|
||||
- 代码：`apps/server/libs/execution-queue.ts`
|
||||
- 控制器：`apps/server/controllers/deployment/index.ts`
|
||||
- Schema：`apps/server/prisma/schema.prisma`
|
||||
166
docs/architecture/design-0004-execution-queue.md
Normal file
166
docs/architecture/design-0004-execution-queue.md
Normal file
@@ -0,0 +1,166 @@
|
||||
---
|
||||
title: 设计文档 0001 - 部署执行队列与重试（基于当前实现）
|
||||
summary: 记录当前 ExecutionQueue 的行为与下一步改进方向，便于团队对齐。
|
||||
owners:
|
||||
- team: backend
|
||||
reviewers:
|
||||
- ops-team
|
||||
status: draft
|
||||
date: 2026-01-03
|
||||
version: 0.1.0
|
||||
related:
|
||||
- code: apps/server/libs/execution-queue.ts
|
||||
- code: apps/server/controllers/deployment/index.ts
|
||||
- schema: apps/server/prisma/schema.prisma
|
||||
---
|
||||
|
||||
# 设计文档 0001：部署执行队列与重试
|
||||
|
||||
## 1. 背景（Context）
|
||||
|
||||
当前服务端在启动时会初始化执行队列（`ExecutionQueue.initialize()`），用于从数据库恢复 `status=pending` 的部署任务并按顺序执行流水线。
|
||||
|
||||
现有相关事实（来自当前代码）：
|
||||
|
||||
- 服务启动入口：`apps/server/app.ts`
|
||||
- 路由：`/api/deployments`（创建部署后入队）与 `/api/deployments/:id/retry`（复制记录后入队）
|
||||
- 数据库：SQLite + Prisma，Deployment 存在 `status` 字段（注释标明：pending/running/success/failed/cancelled）
|
||||
- 队列实现：内存队列 `pendingQueue` + `runningDeployments` Set，并有轮询机制（默认 30 秒）把 DB 中的 pending 任务补进队列
|
||||
|
||||
## 2. 目标（Goals）
|
||||
|
||||
- [ ] 明确“部署任务”从创建到执行的状态流转与约束
|
||||
- [ ] 明确重试语义（retry 会创建新 deployment，而不是复用原记录）
|
||||
- [ ] 降低重复入队/重复执行的风险（幂等与并发边界清晰）
|
||||
- [ ] 让运维/排障更容易：关键日志点与可观测性清单
|
||||
|
||||
## 3. 非目标（Non-goals）
|
||||
|
||||
- 不引入外部消息队列（如 Redis/Kafka），仍以当前内存队列 + DB 恢复为基础
|
||||
- 不在本文直接实现大规模调度/分布式 runner（后续 ADR/设计再做）
|
||||
|
||||
## 4. 需求与范围（Requirements & Scope）
|
||||
|
||||
### 功能需求
|
||||
|
||||
- 创建部署：写入一条 Deployment 记录，初始状态为 `pending`，并加入执行队列
|
||||
- 重试部署：通过 `/deployments/:id/retry` 创建一条新的 Deployment 记录（复制必要字段），并加入执行队列
|
||||
- 服务重启恢复：服务启动后能从 DB 找回仍为 `pending` 的任务并继续执行
|
||||
|
||||
### 非功能需求
|
||||
|
||||
- 可靠性：服务重启不会“丢任务”（pending 的任务能恢复）
|
||||
- 幂等性：避免同一个 deployment 被重复执行
|
||||
- 可观测性：能定位某次部署为何失败、何时开始/结束、队列长度
|
||||
|
||||
## 5. 方案概览（High-level Design）
|
||||
|
||||
当前方案核心链路如下：
|
||||
|
||||
1) API 创建 Deployment（status=pending）
|
||||
2) `ExecutionQueue.addTask(deploymentId, pipelineId)` 入队
|
||||
3) `ExecutionQueue.processQueue()` 串行消费 `pendingQueue`
|
||||
4) `executePipeline()` 会读取 Deployment 与关联 Project，获取 `projectDir`，然后创建 `PipelineRunner` 执行
|
||||
5) 定时轮询：每 30 秒扫描 DB 中的 pending 任务，若不在 `runningDeployments` 集合则补入队列
|
||||
|
||||
## 6. 详细设计（Detailed Design）
|
||||
|
||||
### 6.1 接口/API 设计
|
||||
|
||||
#### 创建部署
|
||||
|
||||
- POST `/api/deployments`
|
||||
- 行为：创建 Deployment 后立即入队
|
||||
|
||||
#### 重试部署
|
||||
|
||||
- POST `/api/deployments/:id/retry`
|
||||
- 行为：读取原 deployment -> 创建新 deployment（status=pending）-> 入队
|
||||
- 语义：重试是“创建一个新的任务实例”，便于保留历史执行记录
|
||||
|
||||
### 6.2 数据模型/数据库
|
||||
|
||||
Deployment 当前关键字段（见 schema 注释）：
|
||||
|
||||
- `status`: pending/running/success/failed/cancelled（目前入队依赖 pending）
|
||||
- `buildLog`: 执行日志（当前创建时写空字符串）
|
||||
- `startedAt`/`finishedAt`: 时间标记（目前 created 时 startedAt 默认 now）
|
||||
|
||||
建议补齐/明确（文档层面约束，代码后续落地）：
|
||||
|
||||
- 状态迁移：
|
||||
- `pending` -> `running`（开始执行前）
|
||||
- `running` -> `success|failed|cancelled`（结束后）
|
||||
- 幂等控制：
|
||||
- 以 deploymentId 为“单次执行唯一标识”，同一个 deploymentId 不允许重复开始执行
|
||||
|
||||
### 6.3 队列/轮询/并发
|
||||
|
||||
现状：
|
||||
|
||||
- `runningDeployments` 同时承担“已入队/执行中”的去重集合
|
||||
- `pendingQueue` 为内存 FIFO
|
||||
- 单实例串行消费（`processQueue` while 循环）
|
||||
- 轮询间隔常量 30 秒
|
||||
|
||||
风险点（需要在文档中明确约束/后续逐步修正）：
|
||||
|
||||
- 多实例部署：如果将来启动多个 server 实例，每个实例都可能轮询到同一条 pending 记录并执行（需要 DB 锁/租约/状态原子更新）
|
||||
- 状态更新缺口：当前 `ExecutionQueue` 代码中没有看到明确把 status 从 pending 改成 running/failed/success 的逻辑（可能在 `PipelineRunner` 内处理；若没有，需要补齐）
|
||||
|
||||
建议（不改变整体架构前提）：
|
||||
|
||||
- 将轮询间隔改为可配置 env：`EXECUTION_POLL_INTERVAL_MS`（默认 30000）
|
||||
- 在真正执行前做一次 DB 原子“抢占”：仅当 status=pending 时更新为 running（并记录开始时间）；更新失败则放弃执行
|
||||
|
||||
### 6.4 可观测性
|
||||
|
||||
最低要求（建议后续落地到代码/日志规范）：
|
||||
|
||||
- 日志字段：deploymentId、pipelineId、projectId、projectDir、status
|
||||
- 队列指标：pendingQueue length、runningDeployments size
|
||||
- 失败记录：捕获异常 message/stack（避免泄露敏感信息）
|
||||
|
||||
### 6.5 安全与权限
|
||||
|
||||
当前接口层面需要确认：
|
||||
|
||||
- `/api/deployments` 与 `/api/deployments/:id/retry` 是否需要登录/鉴权（取决于 middleware 配置）
|
||||
- 若需要鉴权：建议限制为有项目权限的用户才能创建/重试部署
|
||||
|
||||
## 7. 影响与权衡（Trade-offs）
|
||||
|
||||
- 继续采用内存队列：实现简单，但天然不支持多实例并发安全
|
||||
- DB 轮询恢复：可靠性提升，但会带来额外 DB 查询压力
|
||||
|
||||
## 8. 兼容性与迁移（Compatibility & Migration）
|
||||
|
||||
- 文档层面不破坏现有 API
|
||||
- 若引入 status 原子抢占，需要确保旧数据/旧状态兼容（例如对历史 pending 记录仍可恢复）
|
||||
|
||||
## 9. 测试计划（Test Plan）
|
||||
|
||||
- 集成链路：创建 deployment -> 入队 -> 触发执行（可用假 runner）
|
||||
- 重启恢复：插入 pending 记录 -> initialize() -> 任务被 addTask
|
||||
- 重试接口：原记录存在/不存在的分支
|
||||
|
||||
## 10. 发布计划（Rollout Plan）
|
||||
|
||||
- 先补齐文档 + 最小日志规范
|
||||
- 再逐步落地：status 原子抢占 + 轮询间隔 env
|
||||
|
||||
## 11. 备选方案（Alternatives Considered）
|
||||
|
||||
- 引入 Redis 队列（BullMQ 等）：更可靠、支持多实例，但复杂度上升
|
||||
- 使用 DB 作为队列（表 + 锁/租约）：更可靠，但需要严格的并发控制
|
||||
|
||||
## 12. 风险与开放问题（Risks & Open Questions）
|
||||
|
||||
- Q1：`PipelineRunner` 是否负责更新 Deployment.status？如果没有，状态机应由谁维护？
|
||||
- Q2：服务是否计划多实例部署？如果是，必须补齐“抢占执行”机制
|
||||
|
||||
## 13. 附录（Appendix）
|
||||
|
||||
- 代码：`apps/server/libs/execution-queue.ts`
|
||||
- 控制器：`apps/server/controllers/deployment/index.ts`
|
||||
- Schema：`apps/server/prisma/schema.prisma`
|
||||
127
docs/architecture/design-0005-refactor-deply.md
Normal file
127
docs/architecture/design-0005-refactor-deply.md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
title: 设计文档 0005 - 部署流程重构（移除稀疏检出 & 环境预设）
|
||||
summary: 调整部署相关能力：移除稀疏检出；将部署环境从创建时输入改为在项目设置中预设。
|
||||
owners:
|
||||
- team: backend
|
||||
reviewers:
|
||||
- team: frontend
|
||||
status: draft
|
||||
date: 2026-01-03
|
||||
version: 0.1.0
|
||||
related:
|
||||
- docs: docs/api/endpoints.md
|
||||
- schema: apps/server/prisma/schema.prisma
|
||||
---
|
||||
|
||||
# 设计文档 0005：部署流程重构（移除稀疏检出 & 环境预设）
|
||||
|
||||
## 1. 背景（Context）
|
||||
|
||||
当前部署流程在“项目详情页发起部署”时包含“稀疏检出（sparse checkout）”表单项，并且流水线模板中也包含与稀疏检出相关的逻辑。
|
||||
|
||||
另外，部署时需要指定环境变量（例如 env），但目前是在“创建部署”时临时输入/选择。随着项目数量增加，这种方式容易造成不一致与误操作。
|
||||
|
||||
## 2. 目标（Goals）
|
||||
|
||||
- [ ] 移除项目详情页部署表单中的“稀疏检出”相关输入项
|
||||
- [ ] 移除流水线模板中与稀疏检出相关的代码逻辑（后端模板/生成逻辑）
|
||||
- [ ] 将“部署环境（env）”从创建部署时指定，调整为在“项目设置”中提前预设
|
||||
- [ ] 创建部署时仍需要选择/指定环境，但选项来源于项目设置中的预设项
|
||||
|
||||
## 3. 非目标（Non-goals）
|
||||
|
||||
- 不新增多维度环境变量管理（仅覆盖本次提到的 env 单项预设）
|
||||
- 不在本次引入复杂的环境权限、审批流
|
||||
|
||||
## 4. 需求与范围（Requirements & Scope）
|
||||
|
||||
### 4.1 移除稀疏检出
|
||||
|
||||
#### 用户侧
|
||||
|
||||
- 项目详情页发起部署时：不再展示/提交稀疏检出字段
|
||||
|
||||
#### 系统侧
|
||||
|
||||
- 流水线模板：移除任何基于稀疏检出路径的生成/执行逻辑
|
||||
|
||||
> 说明：当前 DB 中 Deployment 仍存在 `sparseCheckoutPaths` 字段（见 `schema.prisma`），本次需求仅明确“功能不再需要”。字段是否删除/迁移由本设计后续章节确定。
|
||||
|
||||
### 4.2 部署环境 env 改为项目设置预设
|
||||
|
||||
#### 核心约束
|
||||
|
||||
- 环境变量预设需要支持多选、单选、输入框这几种类型
|
||||
- 在项目设置中新增可配置项（预设项）：
|
||||
例如：指定env 环境变量
|
||||
- 类型：单选（single select）
|
||||
- key：`env`，value 及时部署是选中的候选项的值
|
||||
- options：`staging`（测试环境）、`production`（生产环境）
|
||||
|
||||
#### 行为
|
||||
|
||||
- 创建部署时仍需指定环境（env），但：
|
||||
- 不再由用户自由输入
|
||||
- 只允许从该项目预设的 options 中选择
|
||||
|
||||
## 5. 影响面（Impact）
|
||||
|
||||
### 5.1 前端
|
||||
|
||||
- 项目详情页部署表单：移除“稀疏检出”相关 UI 与字段提交
|
||||
- 项目设置页：新增“环境预设（env）”配置入口（单选 + 选项 staging/production）
|
||||
- 创建部署交互：环境选项从项目设置读取（不再硬编码/临时输入）
|
||||
|
||||
### 5.2 后端
|
||||
|
||||
- 部署创建接口：校验 env 必须来自项目预设（避免非法 env）
|
||||
- 流水线模板：移除稀疏检出相关的模板字段/生成逻辑
|
||||
|
||||
### 5.3 数据库
|
||||
|
||||
- 需要新增“项目设置/项目配置”承载 env 预设（落库方案待定）
|
||||
- 既有 Deployment 的 `sparseCheckoutPaths` 字段：后续决定是否保留（兼容历史）或迁移删除
|
||||
|
||||
## 6. 兼容性与迁移（Compatibility & Migration）
|
||||
|
||||
- 对历史部署记录：
|
||||
- 若存在 `sparseCheckoutPaths`，不影响查询展示，但新建部署不再写入该字段
|
||||
- 对创建部署：
|
||||
- 若项目未配置 env 预设：创建部署应失败并提示先到项目设置配置（或提供默认值策略，待确认）
|
||||
|
||||
## 7. 测试要点（Test Plan）
|
||||
|
||||
- 前端：
|
||||
- 项目详情页部署表单不再出现稀疏检出项
|
||||
- 项目设置可保存 env 预设（单选）并在创建部署时正确展示
|
||||
- 后端：
|
||||
- 创建部署：env 不在项目预设 options 内时应拒绝
|
||||
- 流水线模板：移除稀疏检出后仍能正常创建并执行
|
||||
|
||||
## 8. 实施状态（Implementation Status）
|
||||
|
||||
### 已完成（后端）
|
||||
|
||||
- ✅ Prisma Schema：在 Project 表添加 `envPresets` 字段（String? 类型，存储 JSON）
|
||||
- ✅ 移除部署创建/重试接口中的 `sparseCheckoutPaths` 写入
|
||||
- ✅ 在部署创建接口添加环境校验：验证 env 是否在项目 envPresets 的 options 中
|
||||
- ✅ 更新 project DTO 和 controller 支持 envPresets 读写
|
||||
- ✅ 移除 pipeline-runner 中的 `SPARSE_CHECKOUT_PATHS` 环境变量
|
||||
- ✅ 生成 Prisma Client
|
||||
|
||||
### 已完成（前端）
|
||||
|
||||
- ✅ 创建 EnvPresetsEditor 组件（支持单选、多选、输入框类型）
|
||||
- ✅ 在 CreateProjectModal 和 EditProjectModal 中集成环境预设编辑器
|
||||
- ✅ 从 DeployModal 移除稀疏检出表单项
|
||||
- ✅ 在 DeployModal 中从项目 envPresets 读取环境选项并展示
|
||||
- ✅ 移除 DeployModal 中的动态环境变量列表（envVars Form.List）
|
||||
- ✅ 从类型定义中移除 sparseCheckoutPaths 字段
|
||||
- ✅ 在项目详情页项目设置 tab 中添加环境变量预设的查看和编辑功能
|
||||
|
||||
### 待定问题
|
||||
|
||||
- Q1：项目设置存储方式 → **已决定**：使用 Project.envPresets JSON 字段
|
||||
- Q2：未配置 env 预设的默认行为 → **已实现**：若配置了预设则校验，否则允许任意值（向后兼容）
|
||||
- Q3：Deployment.sparseCheckoutPaths 字段 → **已决定**：保留字段（兼容历史），但新建部署不再写入
|
||||
|
||||
Reference in New Issue
Block a user