diff options
| author | BigCoke233 <hi@guhub.cn> | 2026-01-28 12:02:29 +0800 |
|---|---|---|
| committer | BigCoke233 <hi@guhub.cn> | 2026-01-28 12:02:29 +0800 |
| commit | 1eda1142e3a1361aeb482a338120d97b5d6dc0d5 (patch) | |
| tree | adf460e362167b2bdfcb6f4a84f3993998d1e7fb | |
| parent | 67740efe9c32ece864e0bdc6ebe7198e030b2634 (diff) | |
docs: update drafts
Former-commit-id: 7f75353f275a845cbec19c654f222353da095e8e
| -rw-r--r-- | content/essays/如何优雅地部署一个静态网站.md | 10 |
1 files changed, 8 insertions, 2 deletions
diff --git a/content/essays/如何优雅地部署一个静态网站.md b/content/essays/如何优雅地部署一个静态网站.md index 01a76a24..30b09ba7 100644 --- a/content/essays/如何优雅地部署一个静态网站.md +++ b/content/essays/如何优雅地部署一个静态网站.md @@ -64,7 +64,7 @@ on: push: branches: - master - +: jobs: deploy: runs-on: docker @@ -112,11 +112,17 @@ eltr.ac { 1. 你需要管理一对 SSH 密钥，并且你允许了外部程序向你的服务器直接写入文件，这有安全风险。 2. Actions 没法在本地测试，必须推送到远程仓库后，Forgejo/GitHub 才会运行工作流，这使得调试工作流变得**非常**痛苦。 -3. 每次运行工作流都需要下载并安装依赖项，对于 Hugo 这种构建速度非常快，甚至不会超过一秒的静态网站生成器，大部分的构建时间都花费在「准备运行环境」上了；而且，这个运行环境在跑完一次之后就会被恢复。如果你使用自己管理的 Forgejo Runner，可以在 Runner 里预安装自定义的依赖项，但依然很麻烦。 +3. 每次运行工作流都需要下载并安装依赖项，对于 Hugo 这种构建速度非常快，甚至不会超过一秒的静态网站生成器，大部分的构建时间都花费在「准备运行环境」上了；而且，这个运行环境在跑完一次之后就会被恢复。如果你使用自己管理的 Forgejo Runner，可以在 Runner 里预安装自定义的依赖项，但复杂度不亚于维护一个单独的服务器。 4. *用 YAML 写工作流十分反人类。* 既然如此，我能不能直接在已经安装好运行环境的宿主服务器上直接运行构建脚本呢？构建产物直接在宿主服务器上生成。这样就可以省去与服务器通过 SSH 密钥认证并建立连接的过程，也不需要把大量的时间浪费在准备运行环境上了。 ## 使用 Webhook 触发远程服务器部署 +构建和部署静态网站之所以使用自动化工作流，是想要实现持续集成和持续部署，也就是在**确认**代码更改后就立刻更新生产环境的代码。一般来说，将代码合并到主分支就代表代码可以运行在生产环境了，自动化工作流可以以此为触发点，在有代码推送到主分支后就执行构建和部署步骤。在服务器上直接构建代码而不是用 Git 仓库的自动化工作流部署，最大的不足在于无法通过 `git push` 自动触发构建，但这个问题并非没有解决方案。 + +我不清楚 GitHub 的情况，Forgejo 可以在仓库设置里配置 Webhook，即在某些事件发生时向指定的 Webhook 端口发送 HTTP 请求。所谓 Webhook，是相对于常规的 Web 交互方式而言的， + + + ## 本地构建并同步到文件服务器或储存桶 |