提供 PR 预览部署

[burningtnt]

使用 GitHub Action 和 GitHub Page 为每个 PR 构建网页并部署，以助力审查人员预览变更的效果

[burningtnt]

或许我们可以使用 CloudFlare Page。他们支持将页面部署到 ${commit_sha1}.example.com

[burningtnt]

为尽快推进预览功能上线，我先合并了 #308 ，但该功能仍有以下改进空间：

• 统一预览构建指示形式；
• 在预览构建的明显处显示“当前页面为 https://github.com/HMCL-dev/HMCL-docs/pull/XXXX 的预览构建，不是 HMCL 官方帮助文档。如要反馈问题，请前往上述 PR 留言。”
• 使用 /assets/..../xxx.png 显示的图片均由于路径错误而无法正确显示。

我希望能够逐步解决上述问题。

[burningtnt]

• 在预览构建的明显处显示“当前页面为 https://github.com/HMCL-dev/HMCL-docs/pull/XXXX 的预览构建，不是 HMCL 官方帮助文档。如要反馈问题，请前往上述 PR 留言。”

这样如何

我希望副标题能够显示为“PR #XXXX 的预览构建”。其中，“#XXXX” 应当为超链接形式，能够在点击后直接跳转到对应 PR 网页。

此外，我希望能够在“本页面由 XXX 用户创建”提示上方添加警告框，显示：“这不是 HMCL 官方帮助文档。如要反馈问题，请前往 #XXXX 留言。”

[neveler]

• 仅在 一个 PR 被 Close 而非 Merge 且 曾创建过预览信息 时显示预览已被移除的提示消息；

我部分认同这一需求：对于未创建过预览的 PR，在关闭时确实无需发送评论通知但其它情况下应保留。

此外还存在一种情况：PR 未创建预览（或预览缓存已过期等）时，用户仍执行了移除缓存操作。在这种情况下，是否需要发送评论通知，以及通知内容是否应修改为“预览不存在”，需要明确规定。

[Glavo]

我希望将预览页面移出本仓库，在其他位置维护这个预览功能，避免为这些预览页面使用 hmcl-dev.github.io 域名。

[burningtnt]

我希望将预览页面移出本仓库，在其他位置维护这个预览功能，避免为这些预览页面使用 hmcl-dev.github.io 域名。

预览网站界面有常驻的警告文本，继续使用 hmcl-dev.github.io 域名并无风险。

[Glavo]

预览网站界面有常驻的警告文本，继续使用 hmcl-dev.github.io 域名并无风险。

无论如何我都反对将未被合并的内容部署到本仓库内。

[burningtnt]

我注意到通过 'preview/watch' 标签创造的构建能创建以下的事件：

并在 PR 信息栏提示

这比 [Preview] https://hmcl-dev.github.io/HMCL-docs/XXXX 提示要刻度太多了。我希望能够全面迁移到该显示方式。

[neveler]

这比 [Preview] https://hmcl-dev.github.io/HMCL-docs/XXXX 提示要刻度太多了。我希望能够全面迁移到该显示方式。

我记得我已经做过适配了，所有基于 pull request target 事件触发的工作流均不会发送评论，基于 issue comment 触发的无法使用这种提示方式所以依旧使用评论的方式进行通知。

[neveler]

我希望将预览页面移出本仓库，在其他位置维护这个预览功能，避免为这些预览页面使用 hmcl-dev.github.io 域名。

有两种方案，一种是使用自定义域名绑定到当前仓库就不会使用这个域名了。亦或者是新建一个组织用于部署预览页面。不过一个 PR 是否预览的决定权在于组织成员，其它用户无权创建预览。个人认为存在一定风险，但风险完全处于可控范围内。

[burningtnt]

未能为 #310 创建预览，报错如下：https://github.com/HMCL-dev/HMCL-docs/actions/runs/19231730770/job/54971629022

[neveler]

我希望能够逐步解决上述问题。

这些问题似乎均已解决，感觉可以关闭此 issue 了。

[burningtnt]

预览网站界面有常驻的警告文本，继续使用 hmcl-dev.github.io 域名并无风险。

无论如何我都反对将未被合并的内容部署到本仓库内。

解释：Glavo 过去误认为我们正在使用基于分支构建的 GitHub Pages 工作流，但实际上 PR 部署构建是直接由 GitHub Action 上传产物至 GitHub Pages，不存在一个“把内容推送到分支里”的中间步骤。

在误会解除后，Glavo 认为当前的部署流程并无问题、