Ontology Playground 工程实践拆解零后端纯静态站点如何维护 8 条 CI/CD 流水线【免费下载链接】Ontology-PlaygroundFree, open-source web app for learning about ontologies and Microsoft Fabric IQ. Explore a catalogue of pre-built ontologies, design your own visually, export as RDF/XML, and share interactive diagrams. Zero backend, fully static.项目地址: https://gitcode.com/GitHub_Trending/on/Ontology-PlaygroundOntology Playground 是一个开源的本体Ontology学习与可视化 Web 应用——可以浏览现成本体目录、在画布上设计自己的本体并导出为 RDF全程零后端、纯静态。纯静态项目通常几乎不需要 CI而这个项目的 .github/workflows/ 目录里摆了 8 条 GitHub Actions 流水线覆盖构建门禁、密钥扫描、双平台部署、PR 自动截图甚至内容审核自动化。本文按它解决了什么问题来拆解每个机制的触发时机、具体做法以及背后值得借鉴的工程思路。全景总览每条机制看住什么这套流水线可以按守门 → 部署 → 增强三层来理解先给一张对照表机制触发时机职责ci.ymlpush / PR → main构建门禁编译目录与课程、校验 RDF、类型检查、a11y、测试、大图谱性能预算secret-scan.ymlpush / PR → mainGitleaks 扫描完整提交历史的密钥泄露Azure 主部署工作流push main / PR 开启与关闭Azure 静态站点部署PR 开一次性预览关闭时自动销毁azure-static-web-apps-review.ymlpush 到review/**分支人工评审用的临时预览环境deploy-ghpages.ymlpush main仅官方仓库官方站点 GitHub Pages 发布ontology-preview-render.ymlPR 改动catalogue/下的 RDF 或 metadata把变更的本体渲染成 PNGontology-preview-comment.yml渲染工作流完成后托管预览图并在 PR 上评论或原地更新ontology-school-review-approval.ymlIssue 关闭 /#approved评论课程审核通过自动开 PR 移除审核中标记dependabot.yml隐形每周一GitHub Actions 依赖更新7 天冷却期防刷屏往下看这些机制各自回答四个问题构建怎么保证可复现、密钥与部署边界怎么防住、贡献者如何零成本看到预览、变更内容与审核结果如何变得可见。构建门禁如何保证构建可复现ci.yml 在每次指向 main 的 push 和 PR 上运行每一步都是独立 step。依赖安装用npm ci --ignore-scripts严格按 package-lock.json 锁定的版本安装并跳过安装脚本保证任何环境装出同一棵依赖树。setup-node 开启了 npm 缓存缓存键覆盖根目录与 api/ 两份 lockfile排队时间被压得很短。之后的门禁依次是catalogue:build把 catalogue/ 下的 RDF 与 metadata 编译成前端可读的清单learn:build把 content/learn/ 的课程 Markdown 编译为经过净化的 JSONnpm run validate校验所有.rdf文件可被合法解析npx tsc -b全量类型检查npm run test:a11y检查 WCAG 2.1 AA 颜色对比度vitest跑全部单元测试含 RDF 解析器的往返测试vite build验证生产构建可成功。这里藏了个小细节CI 还会装 Playwright Chromium跑 tests/performance/large-graph.spec.ts 加载一个含 1500 多个节点的 Brick 本体断言交互耗时、长任务与堆内存预算每次运行都把报告上传为 Artifact。也就是说构建通过不是门禁的终点打开还能流畅用也是门禁的一部分。 每一步都拆成独立 step 收益很大门禁红了一眼看出是目录编译还是类型检查挂的不用在日志里翻。密钥扫描为何要扫全历史secret-scan.yml 有三个讲究。第一checkout 用fetch-depth: 0拉取完整提交历史专防提交密钥、下个提交再删掉的套路——只扫工作区快照是抓不住这种泄露的。第二下载 Gitleaks 8.24.2 二进制时先校验官方 SHA-256 校验和通过才解压执行供应链这一环也锁住了。第三用仓库内的 .gitleaks.toml 配置扫描并开启--redact把日志输出里的敏感值自动打码避免扫描日志自己再泄露一次。本地也有对应入口npm run secrets:scan跑同样的扫描scripts/security-setup.sh 会把core.hooksPath指到.githooks让提交在本地 pre-commit 就被拦下CI 兜底。另一个容易忽略的细节CI 在构建前先跑npm run deployment:validate。scripts/validate-deployment-boundaries.ts 会用正则扫描所有 workflow 文件一旦发现api_location、Azure Functions 发布命令这类配置就直接判失败。纯静态、零后端不是写在 README 里的口号而是被 CI 机械执行的硬约束。 把架构承诺写成机器可执行的规则是防架构腐化很巧的一招。Pages 与 Azure 双轨部署如何分工很巧的一点两条部署工作流靠仓库身份互斥——deploy-ghpages.yml 只在官方仓库运行Azure 工作流恰好相反官方仓库跳过。于是官方站点走 GitHub Pages任何 fork 自动获得自己的 Azure Static Web Apps 实例部署上也是一等公民。Pages 工作流里有几个值得抄的配置配置作用permissions: pages: write, id-token: write最小权限 OIDC 身份令牌部署不依赖长期密钥concurrency: pages, cancel-in-progress: true新推送自动取消旧构建避免发布互相覆盖VITE_BASE_PATH: /仓库名/静态资源路径适配 Pages 子目录部署fork 也能直接用cp build/index.html build/404.htmlSPA 路由回退深链刷新不 404VITE_DEPLOYED_COMMIT_SHA: github.sha页面直接显示当前部署对应的提交排障省心Azure 工作流则负责 PR 生命周期opened/synchronize/reopened自动创建一次性预览站点closed触发close动作销毁预览——评审者不用本地起npm run dev关 PR 后也不留垃圾站点。azure-static-web-apps-review.yml 还留了一条人肉灰度通道向review/xxx分支推送同样会构建并上传预览适合内容评审慢慢看。另外Pages 构建里有个不易察觉的巧思大体量的 RDF 数据不放进仓库构建前用actions/cache/restore加npm run catalogue:restore从线上站点回捞已发布数据构建后再actions/cache/save存回去——仓库不膨胀构建也不缺料。PR 里的本体图如何自动截图这是整套流水线里最值得拆的一对二者用workflow_run解耦先渲染渲染成功才评论互不阻塞。渲染侧ontology-preview-render.yml用paths按路径过滤只在 PR 改动catalogue/**/*.rdf、metadata.json或图渲染组件时触发省资源直接检出 PR 的 head 提交外部贡献者也能跑并取回 base 提交scripts/list-changed-catalogue-entries.ts 对比 base 与 head找出本次 PR 新增或修改了哪些本体本地起vite preview由 scripts/render-ontology-previews.ts 用 Playwright Chromium 把每个变更本体截成 PNG上传为 Artifact。评论侧ontology-preview-comment.yml的防御做得比想象中严先验证 Artifact——按 head 仓库、分支与 sha 反查 PR必须恰好匹配一条才继续防止伪造工作流去评论任意 PR然后把资产推进专用分支ontology-preview-assets托管最后在 PR 评论里找带!-- ontology-preview-render --标记的机器人评论找到就原地更新。重复推送只更新同一条不会刷屏。评审者打开任何一个改动目录的 PR看到的就是一张类似这样的图—— 不用打开页面就能看到你的改动长什么样是贡献者体验的核心全程零配置。内容审核如何变成一条流水线最后一条 ontology-school-review-approval.yml 把人工审核接回了 CI。触发条件收得很严审核 Issue 带ontology-school-approved标签被关闭或者有 push 权限的人通过 API 校验评论#approved其余评论一律不触发。触发之后从 Issue 正文解析### Lesson Path校验路径必须位于content/learn/且以.md结尾用sed精确删掉 frontmatter 中那一行标记——sed -i /^reviewStatus: under-human-review$/d $LESSON_PATH——只动这一行幂等可重跑再跑compile-learn.ts重新编译课程最后由create-pull-request开一个带ontology-school-review标签的 PR 等人合并。完整流程见 docs/ontology-school-review-workflow.md。对内容型项目来说这意味着审核通过不再依赖谁记得手动删标记Issue 是入口剩下交给流水线。完整链路串起来是push/PR 触发 CI 门禁编译、RDF 校验、a11y、测试、大图谱性能预算与 Gitleaks 全历史密钥扫描 → 官方仓库发布 GitHub Pagesfork 与 PR 拿 Azure 一次性预览、关闭即销毁 → 变更的本体自动截图并评论到 PR → 课程靠#approved审核通过后自动开 PR → Dependabot 每周一保持 Actions 依赖新鲜。【免费下载链接】Ontology-PlaygroundFree, open-source web app for learning about ontologies and Microsoft Fabric IQ. Explore a catalogue of pre-built ontologies, design your own visually, export as RDF/XML, and share interactive diagrams. Zero backend, fully static.项目地址: https://gitcode.com/GitHub_Trending/on/Ontology-Playground创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考