CI/CD 流程
GitHub Actions 自动化流程和依赖更新
概述
项目适合用 GitHub Actions 实现两部分自动化：CI（持续集成，即每次提交代码时自动检查质量）和依赖更新（定期更新第三方包并打开 PR）。部署相关内容见部署指南。
当前模板不强制绑定某个 CI 平台。下面是推荐流程，落地时按你的仓库实际 .github/workflows 配置为准。
PR 验证流程
如果你为仓库接入 GitHub Actions，建议在创建或更新 Pull Request 到 main 分支时运行以下检查，任何一项失败都不合并：
Lint 检查 -- 用 Vite Plus 检查代码格式和质量
vp check --fix测试 -- 运行 01MVP 产品内已定义的 Vitest 测试
vpr @01mvp/product#test构建验证 -- 执行生产构建，确保代码能正常编译
vpr @01mvp/product#build本地提交前建议至少跑和你改动相关的检查。比如只改了 UI 就跑 vp check 和相关 build，改了包代码就跑 vpr @01mvp/product#type-check 和 vpr @01mvp/product#test。命令体系见 Vite Plus 工具链，具体测试内容见测试指南。
导出的用户站点快照提供 .github/workflows/validate.yml 作为验证入口。这个 workflow 会安装锁文件依赖，并执行当前产品的 type-check、test 和 build。产品改名后，需要同步调整其中的 workspace 包名。
Docker 镜像构建
需要 Docker 镜像发布时，可以在推送到 main 分支或创建版本标签（如 v1.0.0）时，构建 Docker 镜像并推送到 GitHub Container Registry (ghcr.io)。也可以在 Actions 页面手动触发。
构建过程使用 vp install --frozen-lockfile 安装 workspace 依赖，再执行目标应用的 Vite Plus build。镜像会生成多个标签：latest、分支名、版本号、commit SHA。构建时从 .env.build 加载环境变量（网站 URL、S3 配置等），文件不存在则使用默认值。
推荐配置文件：.github/workflows/docker-image.yml。如果当前仓库还没有 Dockerfile 或镜像发布需求，可以先不添加。
依赖更新
用户站点快照默认不创建自动依赖更新 workflow，避免在你确定维护节奏之前自动产生 PR。需要自动更新时，可以添加 Dependabot 或 Renovate，并让它在创建 PR 后复用 .github/workflows/validate.yml 的 type-check、test 和 build。
处理依赖更新 PR 时，先看自动验证是否通过；需要本地复现时，跑 vp install && vpr @01mvp/product#type-check && vpr @01mvp/product#test && vpr @01mvp/product#build。安全更新建议优先处理，不要等到例行合并窗口。
自动更新工具应只改依赖与锁文件，验证仍以 .github/workflows/validate.yml 为准。
相关文档
这篇文档有问题？