3.4 KiB
3.4 KiB
tags, create time
| tags | create time | |||||
|---|---|---|---|---|---|---|
|
2026-05-27 19:30 |
CICD 在 Slidev 中的应用
概述
本文档记录使用 Gitea Actions 实现 Slidev 演示文稿项目的自动化构建与部署流程：代码推送到 main 分支后自动构建所有 deck，并将产物部署到基于 Docker 的 Nginx 容器。
[!TIP] 本文件夹包含以下子文档：
- CICD 在 Slidev 中的应用/workflow-configuration — Workflow YAML 逐块详解（触发条件、运行环境、依赖管理）
- CICD 在 Slidev 中的应用/deployment-strategy — 部署架构深入分析（DooD 模式、Nginx 运作、设计决策）
- CICD 在 Slidev 中的应用/Docker-in-Container 部署模式详解 — DooD vs SID vs DinD vs Kaniko 方案对比
项目背景
本项目是一个基于 Slidev 的多 deck 演示文稿平台，使用 Markdown 编写幻灯片内容。项目中包含多个独立的演示文稿（每个称为一个 deck），统一由 index.html 的 landing page 进行导航分发。
技术栈选型：
| 组件 | 选择 | 理由 |
|---|---|---|
| 演示文稿框架 | Slidev | Markdown + Vue 驱动，适合技术分享场景 |
| 代码托管 | Gitea（自部署） | 团队内部私有实例，支持 Actions 兼容语法 |
| CI/Runner | Gitea Act Runner（阿里云） | 自建 runner，避免公有 cloud runner 的配额限制 |
| 构建工具 | pnpm + Slidev build | 多 deck 批量构建，输出纯静态站点 |
| 部署方式 | Docker DooD + Nginx Alpine | 无状态部署，每次重建保证干净环境 |
为什么需要 CI/CD？
Slidev 的演示文稿本质是静态站点，传统手动部署流程为：本地 build → 拷贝文件到服务器 → 重启 Nginx。这种方式的痛点在于：
- 人工遗漏：新增 deck 后忘记重新构建或遗漏文件复制
- 环境不一致：本地构建产物可能在服务器上因依赖版本差异出现问题
- 协作困难：多人同时修改不同 deck 时无法自动化集成
通过 Gitea Actions + Docker 实现自动化后，开发者只需关注 .md 内容的编写和提交，构建、部署全流程自动完成——push 即上线。
正文
CI/CD 流水线概览
对于一个 Slidev 项目，典型的发布流程可以拆解为以下几个阶段：
flowchart LR
A["📝 push 到 main"] --> B["Gitea Actions 触发"]
B --> C["安装系统依赖"]
C --> D["检出代码"]
D --> E["安装 pnpm + 项目依赖"]
E --> F["构建 slides"]
F --> G["启动 Nginx 容器"]
G --> H["复制产物到容器"]
H --> I["网站上线"]
架构总览
graph TB
subgraph "本地开发"
DEV["开发者\n编辑 .md"] --> PUSH["git push → main"]
end
subgraph "Gitea Runner (阿里云)"
ACTION["Gitea Actions Runner"]
BUILD["node:22-alpine 容器\n构建 slides → dist/"]
end
subgraph "宿主机 Docker"
NGINX["slides-nginx 容器\n8080 → 80"]
HTML["/usr/share/nginx/html/\n← dist/ 内容"]
end
USER["访客浏览器"]
PUSH --> ACTION
ACTION --> BUILD
BUILD --> COPY["docker cp"]
COPY --> NGINX
NGINX --> HTML
NGINX --> USER