4b60536a2c
- server-migration-memory.json — EIP 119.29.184.32, 域名根路径, CI/CD流程 - cc-009 — 更新双通道架构(Git Sync + CI/CD), dev/main分支模型 - ops-receipt-20260513-03.md — 本轮操作日志 - README.md — 更新链接(去掉/git/路径) - wake-gate/server.js — 更新git clone URL(去掉/git/)
2.3 KiB
2.3 KiB
cc-009: 自动同步即信任通道
════════════════════════════════════════════════════════════════
因果链编号: cc-009
创建: 2026-05-14
更新: 2026-05-13 (霜砚CI/CD流程更新后)
源自: 冰朔"我点合并就可以自动推送到服务器"的需求
════════════════════════════════════════════════════════════════
起点
冰朔原话: "你给代码合并推送了吗。我点合并就可以自动推送到服务器。不需要我在服务器这里手动复制啊。"
因果推导
- 冰朔不应该操作终端 (cc-007)
- 代码从Gitea到服务器必须自动化
- 尝试让Runner做git pull → 权限问题反复失败
- Runner是act_runner用户, git认证/目录权限/配置都脆弱
- 凡是依赖Runner用户权限的方案都不稳定 → 换root权限的独立服务
- Git Sync = 独立进程 + root权限 + PM2守护 + Webhook触发
- Webhook签名验证失败 → raw body修复方案已写，待部署验证
- 霜砚建立了CI/CD流程(ci-and-deploy.yaml) → Runner做部署也是一条路
- 两条路并行: Git Sync (Webhook触发, root权限) + CI/CD (Runner触发, 需权限)
工程落点
双通道架构 (当前)
-
Git Sync (server/git-sync/) — Webhook → root git pull → PM2 restart
- 优势: root权限，不依赖Runner
- 问题: Webhook签名验证待修复
-
CI/CD (.forgejo/workflows/ci-and-deploy.yaml) — Runner → git pull + npm + pm2 restart
- 优势: 霜砚已建，dev/main分流，CI检查
- 问题: Runner权限可能和selfcheck同样的问题
dev/main 分支模型 (霜砚建立)
dev分支: 铸渊开发线 → push → CI检查 → 自己看结果
main分支: 正式线 → 保护规则 → 只有冰朔能merge
合并流程: dev提PR → CI跑检查 → 冰朔合并 → 自动部署
核心原则
通道必须通。手段可以换。
无论用Webhook、CI/CD还是轮询，冰朔点合并→服务器自动更新这条链路必须成立。 技术选择是铸渊的决策自由，但通道不通是铸渊的失职。