From 78464180446857a149bb0e49627a7735673265e4 Mon Sep 17 00:00:00 2001 From: rekbioo~ Date: Wed, 9 Sep 2026 12:30:39 +0800 Subject: [PATCH] fix(ci): deploy production after main promotion (#28) The promotion workflow fast-forwards main with GITHUB_TOKEN, whose pushes do not trigger the Cloudflare push workflow. This left docs.zerodenet.org on the previous deployment even after a successful release. Explicitly dispatch the Cloudflare Pages workflow on main after promotion and grant the required actions: write permission. Update release summaries and deployment guidance to distinguish branch promotion from completed production deployment, including recovery when main already advanced. Validation: pnpm check:build passed for all 69 Markdown files and generated output; workflow YAML parsed and every shell step passed bash -n; git diff --check passed. Co-authored-by: kovawx --- .github/workflows/promote-main.yml | 16 +++++++++++++++- DEPLOYMENT.md | 14 ++++++++++++-- README.md | 2 ++ 3 files changed, 29 insertions(+), 3 deletions(-) diff --git a/.github/workflows/promote-main.yml b/.github/workflows/promote-main.yml index 76c42da..900ae9d 100644 --- a/.github/workflows/promote-main.yml +++ b/.github/workflows/promote-main.yml @@ -8,6 +8,7 @@ on: - main permissions: + actions: write checks: read contents: write pull-requests: write @@ -193,6 +194,18 @@ jobs: git push origin "$EXPECTED_DEVELOP_SHA:refs/heads/main" + - name: Trigger production deployment + env: + GH_TOKEN: ${{ github.token }} + REPOSITORY: ${{ github.repository }} + shell: bash + run: | + set -euo pipefail + + # Pushes made with GITHUB_TOKEN do not trigger other push workflows. + # workflow_dispatch is explicitly supported for this token. + gh workflow run deploy-cloudflare.yml --repo "$REPOSITORY" --ref main + - name: Publish summary env: GH_TOKEN: ${{ github.token }} @@ -203,7 +216,7 @@ jobs: set -euo pipefail gh pr comment "$PR_NUMBER" --repo "$REPOSITORY" --body \ - "Promoted \`develop\` to \`main\` by fast-forward at \`${{ steps.release.outputs.develop_sha }}\` (authorized by @${{ steps.promoter.outputs.login }})." + "Promoted \`develop\` to \`main\` by fast-forward at \`${{ steps.release.outputs.develop_sha }}\` (authorized by @${{ steps.promoter.outputs.login }}). Production deployment requested: https://github.com/$REPOSITORY/actions/workflows/deploy-cloudflare.yml. Check the main deployment result before considering the site published." { echo "## Promotion complete" @@ -213,4 +226,5 @@ jobs: echo "- main: \`${{ steps.release.outputs.main_sha }}\` -> \`${{ steps.release.outputs.develop_sha }}\`" echo "- trigger: \`release:promote\` label" echo "- method: fast-forward" + echo "- production deployment: requested via workflow_dispatch; verify the main run at https://github.com/$REPOSITORY/actions/workflows/deploy-cloudflare.yml" } >> "$GITHUB_STEP_SUMMARY" diff --git a/DEPLOYMENT.md b/DEPLOYMENT.md index 437c104..3f481fe 100644 --- a/DEPLOYMENT.md +++ b/DEPLOYMENT.md @@ -11,6 +11,7 @@ VitePress 文件，不在托管平台上再次安装或构建依赖。 | Pull Request | 检查和构建 | 不部署 | 不部署 | | `main` 推送 | 检查和构建 | 生产部署 | 不部署 | | `develop` 推送 | 检查和构建 | 预览部署 | 公开预览 | +| `release:promote` 晋升 | 验证发布候选 | 晋升后显式触发生产部署 | 不部署 | | 手动触发 | 可选分支 | 仅允许 `main` 或 `develop` | 仅允许 `develop` | Cloudflare Pages 项目的生产分支必须是 `main`。工作流把当前 Git 分支传给 @@ -90,8 +91,15 @@ Actions 的 deployment 输出为准。 1. 功能或文档改动通过 Pull Request 合入 `develop`。 2. `develop` 自动更新 Cloudflare 与 GitHub Pages 两个预览。 -3. 验收预览后，把 `develop` 合入 `main`。 -4. `main` 自动更新 Cloudflare 生产站。 +3. 验收预览后，创建 `develop -> main` 发布 PR，由维护者或管理员添加 + `release:promote` 标签；不要使用 GitHub 的合并按钮。 +4. 晋升工作流验证发布候选并快进 `main`，随后通过 `workflow_dispatch` + 显式触发 `Deploy to Cloudflare Pages` 的 `main` 部署。 +5. 确认该生产部署成功，并检查 `https://docs.zerodenet.org` 的实际内容。 + 分支晋升成功只表示 `main` 已更新，不代表站点部署已完成。 + +晋升使用的 `GITHUB_TOKEN` 推送不会触发其他 `push` 工作流，因此生产 +部署依赖上述显式触发。晋升工作流的 `actions: write` 权限用于发起部署。 需要重新部署现有提交时，可在 Actions 中手动运行工作流并选择对应分支。 手动部署仍会重新安装锁定依赖并执行完整检查，不会上传未经验证的本地产物。 @@ -101,5 +109,7 @@ Actions 的 deployment 输出为准。 - 检查、构建或安装失败时不会执行上传。 - 同一分支的新部署会取消仍在运行的旧部署，避免旧提交后完成并覆盖新提交。 - Cloudflare 部署失败不会影响当前在线版本。 +- 如果 `main` 已晋升但部署触发或上传失败，手动运行 + `Deploy to Cloudflare Pages` 并选择 `main`，然后验证正式域名；无需重复晋升。 - 生产内容有问题时，优先回退 Git 提交并重新推送；紧急情况下可先在 Cloudflare Pages 的 Deployments 页面回滚到之前成功的生产部署。 diff --git a/README.md b/README.md index 41ae6e0..5c68ce5 100644 --- a/README.md +++ b/README.md @@ -107,6 +107,8 @@ Normal changes should go through a Pull Request into `develop`. After the previe The promotion workflow waits for the required `validate` and `release-policy` checks, rebuilds the exact `develop` commit, verifies that `main` is still an ancestor of `develop`, and then fast-forwards `main`. It aborts if the release PR is a draft, the source or target branch is wrong, the label was added by someone without Maintain/Admin access, a required check fails, `develop` changes during validation, or the branch relationship is no longer safe. +After the fast-forward, the workflow explicitly dispatches the Cloudflare Pages deployment on `main`: pushes made with `GITHUB_TOKEN` do not trigger other push workflows. Promotion success means deployment was requested; verify the production deployment and `docs.zerodenet.org` before treating the release as published. If `main` advanced but deployment failed to start or finish, manually run `Deploy to Cloudflare Pages` on `main` instead of retrying the promotion. + If a promotion fails, fix the reported condition, remove the `release:promote` label, and have an authorized maintainer or administrator add it again to retry. ## Local Development