codex-bot
7f88ebba71
Unified application CI and deployment / static-checks (push) Successful in 1m9s
python CI and deployment / static-checks (push) Successful in 1m7s
Unified application CI and deployment / static-checks (pull_request) Successful in 1m7s
python CI and deployment / static-checks (pull_request) Successful in 1m6s
Unified application CI and deployment / verify-and-release (push) Has been skipped
python CI and deployment / verify-and-deploy (push) Has been skipped
Unified application CI and deployment / verify-and-release (pull_request) Has been skipped
python CI and deployment / verify-and-deploy (pull_request) Has been skipped
36 lines
4.5 KiB
Markdown
36 lines
4.5 KiB
Markdown
# 统一应用的 CI/CD
|
|
|
|
## 范围
|
|
|
|
Wiki 与 Studio 合并为 `apps/waterfall-wiki` 内一个 Next.js Pages Router 应用。编辑器组件与内容在 `src/studio`；原生页面为 `/graphic`、`/infinite_canvas`，历史 `/studio/layouts/*`、`/studio/template-layout` 等继续存在。旧 `/studio/api/*` 通过同应用 rewrite 进入 `pages/api/studio-ui`，保留既有 API 地址与权限边界。没有第二个 Next.js 服务或 18134 新部署。
|
|
|
|
品牌包只作为 workspace 源码依赖，不独立构建、测试或部署。Python workflow 保留。`codex/unified-web` 包含未合并 PR #46 的缓存改动作为依赖，评审时必须包含完整差异；不得先合并已失效的旧品牌检查配置。
|
|
|
|
## main 更新后
|
|
|
|
1. `.gitea/workflows/app.yml` 按应用、品牌、脚本、Docker/Compose 配置路径筛选 main push（含 PR 合并）。文档修改不会部署。
|
|
2. runner checkout 本次提交，逐文件检查 Shell 语法与内容约定。
|
|
3. 按锁文件缓存 pnpm 下载，复制清单后离线安装；随后构建 integration 与 runtime 两个目标。Next.js 的类型检查、单元测试、生产编译、冒烟测试只在共享 build 阶段执行；runtime 复用这一层，不再次编译。运行镜像同供 Web 与 worker 使用。
|
|
4. 在锁保护下使用 `prompt-ci-shared` 测试槽位。首次创建专用 PostgreSQL/S3，此后 `--no-recreate` 复用。停止上一轮测试应用，确认数据库容器属于该测试项目后重置测试数据库。本轮使用 `ci-<run_id>` 对象 bucket。
|
|
5. 启动候选 Web/worker，迁移测试数据库，执行接口、账户、画布、编辑器及浏览器集成验证。失败则停止发布。退出时停止测试应用并删除本轮 bucket，保留基础容器和卷。
|
|
6. 生产部署先验证 `/etc/prompt.env` 和既有 `prompt` 基础服务，绝不自动生成新凭据或重建 PostgreSQL/S3。检查是否被更新的 main 取代并获取部署锁。
|
|
7. 停止应用写入，备份数据库，执行迁移及已有内容初始化，使用 `--no-deps` 更新 Web/worker。
|
|
8. 检查健康、账户、已有内容和完整线上验收。验收处于部署脚本回滚边界内；失败尝试恢复数据库备份和上一版应用。
|
|
9. 验收通过后更新 current 和成功记录，停止有明确 Compose 所属标签的旧 Studio 容器（保留旧镜像）。上传验收证据；上传成功后删除 runner 临时报告。镜像盘点清理不在发布关键路径执行。
|
|
|
|
工作分支 push 和面向 main 的 PR 只执行 static-checks，不安装依赖、不编译、不构建镜像、不启动测试环境、不运行单测或浏览器检查。只有 main push 通过静态检查后才执行完整构建、测试与部署；Python 使用相同边界。代价是类型、编译和集成错误到合并后才发现，但失败会阻止后续部署。旧配置已经创建的运行不会因本次 YAML 修改自动变成静态检查。发布不自动取消进行中的任务，以免中断数据库迁移；过期版本由部署脚本检查跳过。
|
|
|
|
## 基础设施初始化与维护
|
|
|
|
生产首次安装或明确升级基础镜像时，管理员单独配置 `/etc/prompt.env`，执行 `bash scripts/init-infra.sh`。日常发布只检查基础服务；既有 `prompt_postgres_data`、`prompt_objects`、`prompt_auth_data` 卷名与凭据不变，不执行生产 `down -v`。
|
|
|
|
持久测试凭据仅保存在 `/var/lib/prompt-ci/credentials.env`，创建时权限受 umask 077 限制；不打印或提交。测试基础设施只使用 `prompt-ci-shared` Compose 项目、随机绑定端口和自己的卷，绝不复用生产数据。runner 必须能写入 `/var/lib/prompt-ci` 和 `/var/lock`；当前确认的 runner 为 root host executor，变更运行身份时需重新配置目录权限。
|
|
|
|
镜像维护继续提供 `wiki-image-lifecycle.py preview/apply`，需在确认无协作构建的维护窗口执行。数据库备份及既有内容导入暂保留在部署流程；这部分尚未按 schema 或内容变更跳过。
|
|
|
|
## 回滚与验收
|
|
|
|
首次迁移前保留旧 Studio 容器、镜像及 `/opt/prompt-studio` 元数据。新版本验收失败发生在旧 Studio 停止之前，可恢复旧 Web/worker。若首次迁移成功后人工回滚到双应用版本，还必须重新启动保留的旧 Studio 容器；不能只回滚 Web 镜像。
|
|
|
|
构建及浏览器验证只在 ces-control 执行。本地只能做语法、引用及差异检查；实际通过状态以 PR 对应提交的远程 CI 为准。PR 等待用户手动合并，不自动部署或合并。
|