EdgeOne Makers static-site deploy

EdgeOne Makers static-site deploy 指仓库把静态站点构建结果作为单一 publish artifact 交给 GitHub Actions，再由 workflow 用 npx edgeone makers deploy 持续发布到 EdgeOne Makers 的 direct-upload project。这个 Topic 关注的是“静态产物如何稳定进入 EdgeOne production”，而不是泛指所有 EdgeOne 功能，也不是把 EdgeOne 当成普通 CDN/DNS 名词带过。

这个模式通常伴随两个边界：第一，CI 只负责构建并上传静态产物，不接管控制台首配、证书、备案、域名切流；第二，repo 里往往还会保留一个热备或回滚源，例如 GitHub Pages，但两边必须消费同一份 artifact，避免双构建漂移（projects/isolarail.md）。

当 project snapshot、README 或 checked-in workflow 明确显示仓库会在 GitHub Actions 中执行 edgeone makers deploy、目标项目是 Makers direct upload、且 deploy 输入是已构建好的静态目录时使用。典型信号包括：EDGEONE_API_TOKEN / EDGEONE_PROJECT_NAME 这类最小 CI 合同、owner-side 的默认域名 smoke test 顺序、以及把 EdgeOne 和热备平台共同绑定到同一份 publish artifact 的做法（projects/isolarail.md）。

如果仓库只是手工在控制台上传静态文件、只在 README 里提过 EdgeOne、或者实际发布的是 SSR/动态运行时而不是静态上传目录，就不应命中本 Topic。那种情况应保留在项目级运维文档里，或归入别的 hosting/deploy 模式，而不是强行套进 Makers static-site contract。

• 默认先 build 一次，再把同一份静态目录交给多个下游。isolarail 先构建 web/ 与 docs-site/，再通过 site:assemble 生成 .site-publish，GitHub Pages 与 EdgeOne 都消费这一个目录，避免路径、内容和 base 处理出现双构建漂移（projects/isolarail.md）。
• EdgeOne 目标默认使用 Makers direct-upload project，而不是把 provider-side build 当成发布真相。这样仓库内的 build 命令、base path 逻辑和 artifact 结构始终可审计（projects/isolarail.md）。
• PR 默认只保留 build-only 校验；production deploy 只在 main push 或 workflow_dispatch 发生。这样可以避免 preview/comment 需求把 EDGEONE_API_TOKEN 暴露到不该出现的路径里（projects/isolarail.md）。
• 把 owner prerequisite 和 CI contract 分开写。项目、区域、自定义域名、证书、默认域名 smoke test 顺序属于 owner-side rollout；CI 里只保留 EDGEONE_API_TOKEN、EDGEONE_PROJECT_NAME 和 deploy 命令，不要把 DNS/certificate 流程塞进 workflow（projects/isolarail.md）。
• 如果 EdgeOne CLI 会把 repo 内的目录误判成需要 provider-side builder metadata，默认先把 artifact stage 到仓库外的临时目录再执行 edgeone makers deploy。isolarail 已用这种方式规避过 504 CLOUD_FUNCTION_INVOCATION_TIMEOUT（projects/isolarail.md）。
• 当 docs site 被挂在主站子路径时，要先解出根站点与 docs 子站点的 base，再交给组合发布流程。不要先假设文档站独占根域名，尤其是 web/ 根站点 + /docs/ 子站点的结构（projects/isolarail.md）。

• projects/isolarail.md：当前代表样本。它把 web/ 放到 /、把 docs-site/ 放到 /docs/，通过 site:assemble 生成单一 .site-publish，并在 .github/workflows/docs-pages.yml 中同时驱动 GitHub Pages 热备与 EdgeOne production deploy。这个样本同时覆盖了三个最关键的复用点：单一静态 artifact 合同、EDGEONE_API_TOKEN / EDGEONE_PROJECT_NAME 的最小 CI 输入面、以及“默认域名 smoke test 先于正式 DNS cutover”的 owner-side rollout 边界，因此很适合作为后续同类仓库的对照基线。

• 为 GitHub Pages 和 EdgeOne 各自重建一次站点，通常会导致 base path、静态资源 URL 或 CNAME 处理不一致，回滚时尤其容易踩坑。
• 在 PR 上启用 EdgeOne deploy 或评论流程，会把本应只在 production 路径使用的 secret/variable 合同带到更宽的攻击面里。
• 直接从 repo 内 artifact 目录执行 edgeone makers deploy，若 CLI/平台把它误识别为需要 provider-side build 的项目，可能出现“日志说成功，域名返回 504”的假成功。
• 把自定义域名、证书签发和 DNS cutover 写死进 workflow，会让 CI 合同与 owner-side 运维边界混在一起，回滚也变得不可审计。
• 没有先用 EdgeOne 默认域名做 smoke test 就切正式 DNS，会把静态产物错误、路由错误和证书错误一起带到生产入口。

• projects/isolarail.md
• skills/style-playbook/references/data/projects/isolarail.json