OpenClaw Nightly 发布自动化全解Tideclaw Alpha 分支隔离、发布 CI 与主干预合Forward-Port实战【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw本篇指南以 OpenClaw 仓库中的 release-openclaw-nightly 技能文档 为骨架完整拆解 OpenClawTideclaw夜间/alpha 版本发布自动化流水线从隔离分支创建、既有修复复用、发布 CI 触发到 npm 发布证明、前向移植回main与分支保留策略。读者读完可掌握一套可复制的从不干净的main上安全产出可用的 nightly 构建并在验证通过后将可复用修复回传主干的完整工程实践包括版本号推算规则、阻断门与建议门的区分、以及gh只读/写包装器的使用边界。为什么 nightly 必须隔离发布OpenClaw 的发布策略文档明确了四条核心纪律Alpha/nightly 每 12 小时运行一次或由人工触发Beta 由人工从 Discord 触发且只能基于已被证明可用的 alpha/release 分支Stable/latest 永远需要明确的人工确认绝不在脏工作区或直接从main发布。其根本原因在于main可能处于忙碌或故障状态瞬时的 main 故障不应阻塞一个可用的 nightly。因此 alpha 工作必须隔离进行且只有在 release 分支证明全绿后才发布。发布成功后再把 release 分支上的修复提交前向移植回main并证明 main 的 CI 恢复绿色。这条策略与仓库中实际的发布 CI 约束完全一致。查看 openclaw-release-publish.yml 的输入校验可以发现alpha 发布只允许从匹配的tideclaw/alpha/YYYY-MM-DD-HHMMZ分支触发tideclaw_alpha_publishtrue普通发布则必须从受保护的轻量release-publish/tooling-sha12-epoch标签触发从main直接发布会被硬性拒绝。发布前的 Backport 审计Audit Nightly Backports当 alpha、beta 或修复分支需要发现/复用超出其固定基线的 backport 时必须在改动候选分支之前完成一次自包含的审计。直接从当前固定的origin/main开启 alpha 不会自动产生 backport 审计需要注意这一点。审计的核心步骤固定基线钉住确切的 release 基线与源 main SHA从上次已接受的审计游标开始无游标则从 merge base 开始枚举列出每一个非 patch-equivalent 的源提交对账已授权的公开/私有公告记录将边界、数量、过滤器、适用性结果、决策、排除项、依赖与阻塞项写入现有 alpha 状态文件分类而非看标题标题只是信号不是闸门。完整清点清单逐个检查带安全/可靠性信号的产线 diff并单独审阅执行、认证、沙箱、网络、持久化、投递、网关、配置、插件以及主要通道路径上的常规fix、perf、doctor提交机械尝试对每个 diff 在分离的基线 worktree 上做 cherry-pick 尝试记录结果是 clean、conflicted、empty/already-covered 还是 failed。clean patch 只是分诊证据不等于自动 backport快照 maturity:stable 标签的 issue在钉住的源 SHA 处快照携带maturity:stable标签的 OpenClaw issue 并记录标签查询时间。每个标签 issue无论开闭只要其修复 PR/commit 落在扫描区间内都要给出 commit-ledger 决策每个开放的 P0/P1 标签 issue 都要有明确的 fixed / not-affected / maintainer-deferred / blocked 发布处置。标签仅作完整性与优先级信号不能仅凭标签推断修复、backport 批准或发布阻塞逐项深审对每个提议项检查完整变更、基线行为、调用方、被调用方、兄弟代码、测试、依赖契约、安全影响与发布表面把重叠或相互依赖的提交折叠成最小的最终修复排除与批准功能、迁移、新配置或运行时需求、大规模重构除非维护者明确批准否则一律排除。完整分类集必须先提交审批再改动候选审批后把 provenance 保留在状态文件中运行聚焦证明与发布校验并只在规范分支/标签拥有精确的最终版本与 SHA 之后才派发 npm preflight。Tideclaw 机器身份与分支形态提交身份IdentityTideclaw 在 release 分支与前向移植分支上应使用自己的机器身份提交保证可审计性提交明显是机器生成且由 CI 把关git config user.name Tideclaw git config user.email tideclawopenclaw.ai同时避免直接推送受保护的main前向移植走 PR/自动合并除非仓库策略明确允许 bot 在绿灯后推送。只有人工提供了补丁或明确提交文本时才附带Co-authored-by。分支与标签命名Branch Shape要素约定分支前缀tideclaw/alpha/分支名tideclaw/alpha/YYYY-MM-DD-HHMMZ基线触发时的当前origin/mainSHA状态文件从 Tideclaw 主机上的$release-private解析发布标签vYYYY.M.PATCH-alpha.Nnpm dist-tagalpha版本号推算规则关键PATCH是顺序的月度发布列车号release-train number绝不是日历日根据 stable 与 beta 发布确定 alpha 列车忽略仅 alpha 的 patch 号来选择下一个列车取当月最高 stable/beta patch 加一同一列车内多次 nightly 只递增alpha.N若下一个 patch 上已有 beta则 alpha 移到后续列车历史遗留的带虚高 patch 号的 alpha-only 标签不推进beta/stable 编号不要为新一轮运行复用旧 alpha 分支即使重跑同一 base SHA也要新建带时间戳的分支并记录原因。启动一次 nightlyStart标准流程在 Tideclaw 主机 checkout来自$release-private中执行先 fetchgit fetch origin main --tags --prune git switch main git merge --ff-only origin/main BASE_SHA$(git rev-parse origin/main) BRANCHtideclaw/alpha/$(date -u %Y-%m-%d-%H%MZ) git switch -c $BRANCH $BASE_SHA改动前必读仓库发布文档/脚本AGENTS.mddocs/下的发布文档如 docs/ci/release-validation/full-release-validation.mdscripts/下的发布脚本.github/workflows/*release*幂等检查将$BASE_SHA与上次成功的 alpha 状态及当前 git/npm/GitHub alpha 标签对比若已发布则报告 skip 且不发布。人工触发等价于 alpha cronCRON_IDfrom release-private OPENCLAW_ALLOW_ROOT1 openclaw cron run $CRON_ID --expect-final --timeout 21600000Discord 触发Alpha 与 BetaDiscord Alpha Trigger当维护者在#releases或#maintainers提及 Tideclaw 时可立即运行 alpha。接受的指令形态Tideclaw run alpha now Tideclaw alpha release from main now Tideclaw trigger alpha规则要点视同 alpha cron 的人工触发从当前origin/main新建tideclaw/alpha/YYYY-MM-DD-HHMMZ分支走正常 alpha 流程复用既有修复 → 本地检查 → 在 alpha 分支修复 → 运行发布 CI → 绿灯后发布 alpha → 以 fixes-only PR 前向移植若有其他 alpha/beta/stable 发布运行中报告活动分支/运行并停止#maintainers触发必须显式提及 Tideclaw不响应未提及的发布闲聊从$release-private解析 Discord 角色/用户 id 与主机 hotfix 备注。Discord Beta TriggerBeta 只能由维护者显式指令触发视为对 beta 的人工批准不代表对 stable/latest 的批准。接受的指令形态Tideclaw beta release from vYYYY.M.PATCH-alpha.N Tideclaw beta release from tideclaw/alpha/YYYY-MM-DD-HHMMZ Tideclaw beta release from latest proven alpha规则要点必须包含beta release字样和一个源 alpha 标签/分支或latest proven alpha源不明确时在#releases中问一个澄清问题并停止先验证源 alphaGitHub release、npmalpha包、发布 CI、记录的状态文件、分支/标签 SHA从已被证明的 alpha 源新建tideclaw/beta/YYYY-MM-DD-HHMMZ分支绝不从移动的main直接建只复用/压缩已在 alpha 上验证过的稳定化修复不引入无关的 alpha 发布机制Beta 版本计算为vYYYY.M.PATCH-beta.N匹配 npm--tag beta选列车时忽略 alpha-only patch 号在 beta 分支上运行 beta 发布校验/preflight/完整发布 CI 并修复失败Beta 绿灯后才发布使用 GitHub Actions/OIDC绝不在主机上直接 npm publish最终 Discord 总结必须包含源 alpha、beta 标签/版本、分支、修复提交、workflow run IDs、npm/GitHub 证明、任何跳过/阻塞原因beta 发布后按同样的 fixes-only PR 规则前向移植。复用既有修复Reuse Prior Fixes运行检查前先挖掘近期 Tideclaw alpha 分支上已做过的修复从$release-private的 Tideclaw 状态文件读取上次成功 alpha 分支与 fix commit SHAs列出远端分支git for-each-ref refs/remotes/origin/tideclaw/alpha --format%(refname:short) %(committerdate:iso-strict)只考虑最近 3 天的 Tideclaw alpha 分支加上上次成功的 alpha 分支对每个候选分支检查不在当前origin/main中的提交git log --no-merges --reverse --format%H%x09%s origin/main..origin/tideclaw/alpha/YYYY-MM-DD-HHMMZ只 cherry-pick 仍能应用到新 alpha 分支的真实稳定化修复。若这是发现而非复用状态文件中已批准的修复必须先过 nightly backport 审计clean cherry-pick 或无害的标题都不是批准依据。优先采用状态文件中记录的fixCommitShas跳过版本号 bump、changelog release 条目、标签产物、生成的发布说明、纯状态文件提交、一次性调试插桩cherry-pick 冲突时先检查当前 main 是否已含等价修复若没有则最小化解冲突并保持提交信息清晰在 alpha 状态与最终 Discord 总结中分开记录复用的 commit SHAs 与新建的 fix SHAs。用git cherry、git range-diff和定向测试重跑避免与main上已有的修复重复。修复循环Repair Loop把 alpha 分支当作 release-candidate 的修复表面先跑窄范围本地检查变更测试、release preflight、发布文档要求的类型/lint/build 门本地检查失败 → 在 alpha 分支上以最小提交修复每个连贯修复以 Tideclaw 身份提交每次修复后重跑失败的本地检查不要通过编辑基线、预期失败列表、ignore 文件或发布清单来掩盖失败除非发布文档明确要求且 diff 有正当理由失败若为 flaky重跑一次仍红则视为真实失败修复若明显对 main 有用保持小而可移植alpha 稳定化期间避免大范围重构。提交示例git add files git commit -m fix: stabilize alpha release preflight git push -u origin $BRANCH发布 CIRelease CI从 preflight 到 publish wrapper触发 Full Release Validation 与 npm preflight本地证明通过后从既有 git 标签、npm 版本与 GitHub releases 计算下一个vYYYY.M.PATCH-alpha.NPATCH取自 stable/beta 列车而非日期或最高 alpha-only patch复用同一 alpha 列车并递增alpha.N直到该 patch 出现 beta 后用下一 patch让 alpha 分支的包版本与 release 元数据匹配该标签提交并推送分支用 GitHub CLI 而非 browser/fetch 工具运行发布校验。在 Tideclaw 主机上裸gh是只读的 Codex 沙箱包装器写命令workflow run、run cancel、发布 dispatch使用/usr/local/bin/gh-tideclaw-writeGH/usr/local/bin/gh-tideclaw-write SHA$(git rev-parse HEAD) TAGv$(node -p require(./package.json).version) BRANCH$(git branch --show-current) $GH workflow run full-release-validation.yml --repo openclaw/openclaw --ref $BRANCH \ -f ref$BRANCH \ -f expected_sha$SHA \ -f release_profilebeta \ -f rerun_groupall $GH workflow run openclaw-npm-release.yml --repo openclaw/openclaw --ref $BRANCH \ -f tag$SHA \ -f preflight_onlytrue \ -f npm_dist_tagalpha这里release_profilebeta与 full-release-validation.yml 的输入定义一致beta 档案保持最快的 OpenAI/core 发布关键通道run_release_soak默认falsestable/full 强制开启。rerun_groupall是 full-release-validation.yml 提供的验证组之一还有ci、plugin-prerelease、install-smoke、cross-os、live-e2e、package、qa-parity、qa-live、npm-telegram、performance而 openclaw-release-publish.yml 会硬性校验npm 发布前 Full Release Validation 必须跑过rerun_groupall。用gh run list、gh run view、gh api观察确切的 workflow run IDs 与 head SHA。只读gh用于轮询没问题只有变更 GitHub 的命令才用$GH。不要用 Codex browser/fetch 轮询 GitHub API——文档明确记录此前 Tideclaw 运行在 preflight 成功之后在此失败过Alpha 的阻断门是 Tideclaw 能直接修复或能证明包安全性的门正常 CI、plugin prerelease、npm preflight、包准备、install smoke、tag/可达性、发布验证。建议门advisory包括跨 OS、live channel、QA Lab、包验收、长时 Docker E2E、Telegram 包 E2E——这些在 Discord 中报告并继续只要阻断门全绿若rerun_groupall仅在 CI、plugin prerelease、npm preflight、包准备、install smoke 全绿后卡在建议通道上可在同一 head 上派发聚焦的-f rerun_groupinstall-smokeFull Release Validation用这次成功的聚焦运行作为发布证明并把独立的 CI/plugin/full 建议 run IDs 写进 Discord 总结阻断门失败 → 在 alpha 分支修复、推送只重跑失败或必需的发布 CI。若提交变化丢弃旧的 preflight/full-validation run IDs并为新 head 重跑同一分支 head 上 full validation 与 npm preflight 全绿后审阅 npm preflight 的Plugin SDK API diff摘要若报告有变更下载plugin-sdk-api-release-diff-npm-preflight-run-id-run-attempt工件检查变更的声明将PLUGIN_SDK_API_ACKNOWLEDGEMENT设为其digest前 8 个字符否则置为空字符串。然后从该确切提交创建并推送发布标签NPM_PREFLIGHT_RUN_ATTEMPT$(gh api \ repos/openclaw/openclaw/actions/runs/${NPM_PREFLIGHT_RUN_ID} \ --jq .run_attempt) plugin_sdk_diff_dir$(mktemp -d) gh run download $NPM_PREFLIGHT_RUN_ID --repo openclaw/openclaw \ --name plugin-sdk-api-release-diff-${NPM_PREFLIGHT_RUN_ID}-${NPM_PREFLIGHT_RUN_ATTEMPT} \ --dir $plugin_sdk_diff_dir jq {digest, entrypointsAdded, entrypointsRemoved, exports} \ $plugin_sdk_diff_dir/plugin-sdk-api-release-diff.json PLUGIN_SDK_API_ACKNOWLEDGEMENT # 审阅非空 diff 后使用其打印的 digest # PLUGIN_SDK_API_ACKNOWLEDGEMENT$(jq -r .digest[0:8] \ # $plugin_sdk_diff_dir/plugin-sdk-api-release-diff.json) git tag -a $TAG $SHA -m openclaw ${TAG#v} git push origin $TAG rm -rf $plugin_sdk_diff_dirPLUGIN_SDK_API_ACKNOWLEDGEMENT正是 openclaw-release-publish.yml 定义的输入8 字符 Plugin SDK API diff digest发布器会用 scripts/plugin-sdk-api-release-evidence.mjs 等校验器对账 manifest 与不可变工件参见 openclaw-release-publish.yml 的cmp一致性检查。从同一 alpha 分支派发发布 wrapper使用同一 head SHA 上成功的 npm preflight run ID 与 full release validation run ID 及精确 attemptFULL_RELEASE_VALIDATION_RUN_ATTEMPT$(gh api \ repos/openclaw/openclaw/actions/runs/${FULL_RELEASE_VALIDATION_RUN_ID} \ --jq .run_attempt) $GH workflow run openclaw-release-publish.yml --repo openclaw/openclaw --ref $BRANCH \ -f tag$TAG \ -f preflight_run_id$NPM_PREFLIGHT_RUN_ID \ -f full_release_validation_run_id$FULL_RELEASE_VALIDATION_RUN_ID \ -f full_release_validation_run_attempt$FULL_RELEASE_VALIDATION_RUN_ATTEMPT \ -f plugin_sdk_api_acknowledgement$PLUGIN_SDK_API_ACKNOWLEDGEMENT \ -f npm_dist_tagalpha \ -f plugin_publish_scopeall-publishable \ -f publish_openclaw_npmtrue \ -f release_profilebeta \ -f wait_for_clawhubfalse发布器 openclaw-release-publish.yml 会做一系列硬校验tag 格式必须是vYYYY.M.PATCH(-alpha.N|-beta.N|...)alpha 标签必须配 npm dist-tagalphaL176-L179发布子任务要求父任务运行在受保护的release-publish/标签或匹配的 Tideclaw alpha 分支上L289-L295发布 tag 必须可达自main、release/*、extended-stable/*或匹配的 alpha 分支L892-L926。publish_openclaw_npmtrue还要求plugin_publish_scopeall-publishable保证每个可发布的官方插件随 OpenClaw 一起发布L296-L299。观察发布 wrapper 及其子运行。若openclaw-npm-release.yml卡在等待npm-release环境审批而 Tideclaw 无法批准将其报告为唯一阻塞项不得宣布发布完成绝不在主机上直接 npm publish一律走 GitHub Actions/OIDC。关键区分openclaw-npm-release.yml带preflight_onlytrue时只准备工件不会发布。一次成功的 alpha 必须包含后续的openclaw-release-publish.ymlwrapper、推送的 git tag、npmalphadist-tag 证明与 GitHub prerelease。验证已发布的 AlphaVerify Published Alpha直到以下全部为真发布才不算完成GitHub tag 存在GitHub Release 存在且标记为prereleaseRelease 正文链接 npm 版本页、registry tarball、integrity 与 CI/proofnpm view openclawversion显示确切版本、dist-tagalpha、tarball、integrity 与发布时间安装/包 smoke 遵循仓库发布文档$release-private的 Tideclaw 状态文件记录了版本、tag、base SHA、分支、fix commit SHAs、workflow run IDs、npm integrity 与时间戳。最终 Discord 总结发在#releases需包含tag/version、base SHA、branch、fix commits、workflow run IDs、npm/GitHub proof、以及未发布时的 skipped/blocked 原因。使用 Discord 安全的 Markdown 链接尖括号目标绝不打印 secrets。前向移植Forward-Port把修复回传 main成功 alpha 之后向main提一个 fixes-only PR从当前origin/main创建/更新前向移植分支git fetch origin main --prune git switch -c tideclaw/forward-port/$(date -u %Y-%m-%d-%H%MZ) origin/main只 cherry-pick真实修复为了让 nightly/release 检查通过所必需的提交排除alpha 版本 bump、changelog release 条目、发布说明、tag 产物、生成的发布资产、纯状态文件提交、以及唯一目的是发布 alpha 的提交若提交混合了真实修复与发布/版本变更拆分它只把修复 hunks 重放到前向移植分支的新提交中冲突按最小 main 兼容修复解决运行相关变更/本地门推送并开 PR或使用仓库允许的 bot 合并路径等待必需 main CI 全绿失败则在 forward-port 分支修复并重跑报告 PR/合并 SHA 及任何故意未前向移植的提交。若前向移植前origin/main已独立红掉记录无关的失败检查并尽可能让 forward-port PR 在自身 head 上保持绿色。分支保留策略Branch Retention每次运行前后清理旧 alpha 分支列出origin/tideclaw/alpha/*保留时间戳在最近 3 天 UTC内的分支保留被活动 workflow run、开放 PR、release tag 或状态文件引用的分支只删除 Tideclaw 拥有的 alpha 分支git push origin --delete tideclaw/alpha/YYYY-MM-DD-HHMMZ绝不删除人工分支、beta 分支、stable 分支或未知前缀。停止条件Stop Conditions遇到以下情况必须停止并清晰报告发布文档/脚本在版本化或发布路径上不一致必需的 secrets/auth 不可用GitHub Actions 无法派发或观察真实修复尝试后必需发布门仍红发布后 npm/GitHub 状态不一致前向移植在无更大产品决策的情况下无法转绿。关键源码索引技能文档本体.agents/skills/release-openclaw-nightly/SKILL.md发布 umbrellarerun_group / release_profile / fail_fast 参数.github/workflows/full-release-validation.ymlnpm preflight 与发布门preflight_only语义.github/workflows/openclaw-npm-release.yml发布 wrappertag 校验、evidence 校验、alpha 分支约束.github/workflows/openclaw-release-publish.yml发布校验文档Validation SHA Tooling SHA 元组、release-publish/标签机制docs/ci/release-validation/full-release-validation.md发布 CI 技能immutable 计划、Release Decision 校验、pnpm frv恢复.agents/skills/release-openclaw-ci/SKILL.md【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenClaw Nightly 发布自动化全解：Tideclaw Alpha 分支隔离、发布 CI 与主干预合（Forward-Port）实战
OpenClaw Nightly 发布自动化全解Tideclaw Alpha 分支隔离、发布 CI 与主干预合Forward-Port实战【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw本篇指南以 OpenClaw 仓库中的 release-openclaw-nightly 技能文档 为骨架完整拆解 OpenClawTideclaw夜间/alpha 版本发布自动化流水线从隔离分支创建、既有修复复用、发布 CI 触发到 npm 发布证明、前向移植回main与分支保留策略。读者读完可掌握一套可复制的从不干净的main上安全产出可用的 nightly 构建并在验证通过后将可复用修复回传主干的完整工程实践包括版本号推算规则、阻断门与建议门的区分、以及gh只读/写包装器的使用边界。为什么 nightly 必须隔离发布OpenClaw 的发布策略文档明确了四条核心纪律Alpha/nightly 每 12 小时运行一次或由人工触发Beta 由人工从 Discord 触发且只能基于已被证明可用的 alpha/release 分支Stable/latest 永远需要明确的人工确认绝不在脏工作区或直接从main发布。其根本原因在于main可能处于忙碌或故障状态瞬时的 main 故障不应阻塞一个可用的 nightly。因此 alpha 工作必须隔离进行且只有在 release 分支证明全绿后才发布。发布成功后再把 release 分支上的修复提交前向移植回main并证明 main 的 CI 恢复绿色。这条策略与仓库中实际的发布 CI 约束完全一致。查看 openclaw-release-publish.yml 的输入校验可以发现alpha 发布只允许从匹配的tideclaw/alpha/YYYY-MM-DD-HHMMZ分支触发tideclaw_alpha_publishtrue普通发布则必须从受保护的轻量release-publish/tooling-sha12-epoch标签触发从main直接发布会被硬性拒绝。发布前的 Backport 审计Audit Nightly Backports当 alpha、beta 或修复分支需要发现/复用超出其固定基线的 backport 时必须在改动候选分支之前完成一次自包含的审计。直接从当前固定的origin/main开启 alpha 不会自动产生 backport 审计需要注意这一点。审计的核心步骤固定基线钉住确切的 release 基线与源 main SHA从上次已接受的审计游标开始无游标则从 merge base 开始枚举列出每一个非 patch-equivalent 的源提交对账已授权的公开/私有公告记录将边界、数量、过滤器、适用性结果、决策、排除项、依赖与阻塞项写入现有 alpha 状态文件分类而非看标题标题只是信号不是闸门。完整清点清单逐个检查带安全/可靠性信号的产线 diff并单独审阅执行、认证、沙箱、网络、持久化、投递、网关、配置、插件以及主要通道路径上的常规fix、perf、doctor提交机械尝试对每个 diff 在分离的基线 worktree 上做 cherry-pick 尝试记录结果是 clean、conflicted、empty/already-covered 还是 failed。clean patch 只是分诊证据不等于自动 backport快照 maturity:stable 标签的 issue在钉住的源 SHA 处快照携带maturity:stable标签的 OpenClaw issue 并记录标签查询时间。每个标签 issue无论开闭只要其修复 PR/commit 落在扫描区间内都要给出 commit-ledger 决策每个开放的 P0/P1 标签 issue 都要有明确的 fixed / not-affected / maintainer-deferred / blocked 发布处置。标签仅作完整性与优先级信号不能仅凭标签推断修复、backport 批准或发布阻塞逐项深审对每个提议项检查完整变更、基线行为、调用方、被调用方、兄弟代码、测试、依赖契约、安全影响与发布表面把重叠或相互依赖的提交折叠成最小的最终修复排除与批准功能、迁移、新配置或运行时需求、大规模重构除非维护者明确批准否则一律排除。完整分类集必须先提交审批再改动候选审批后把 provenance 保留在状态文件中运行聚焦证明与发布校验并只在规范分支/标签拥有精确的最终版本与 SHA 之后才派发 npm preflight。Tideclaw 机器身份与分支形态提交身份IdentityTideclaw 在 release 分支与前向移植分支上应使用自己的机器身份提交保证可审计性提交明显是机器生成且由 CI 把关git config user.name Tideclaw git config user.email tideclawopenclaw.ai同时避免直接推送受保护的main前向移植走 PR/自动合并除非仓库策略明确允许 bot 在绿灯后推送。只有人工提供了补丁或明确提交文本时才附带Co-authored-by。分支与标签命名Branch Shape要素约定分支前缀tideclaw/alpha/分支名tideclaw/alpha/YYYY-MM-DD-HHMMZ基线触发时的当前origin/mainSHA状态文件从 Tideclaw 主机上的$release-private解析发布标签vYYYY.M.PATCH-alpha.Nnpm dist-tagalpha版本号推算规则关键PATCH是顺序的月度发布列车号release-train number绝不是日历日根据 stable 与 beta 发布确定 alpha 列车忽略仅 alpha 的 patch 号来选择下一个列车取当月最高 stable/beta patch 加一同一列车内多次 nightly 只递增alpha.N若下一个 patch 上已有 beta则 alpha 移到后续列车历史遗留的带虚高 patch 号的 alpha-only 标签不推进beta/stable 编号不要为新一轮运行复用旧 alpha 分支即使重跑同一 base SHA也要新建带时间戳的分支并记录原因。启动一次 nightlyStart标准流程在 Tideclaw 主机 checkout来自$release-private中执行先 fetchgit fetch origin main --tags --prune git switch main git merge --ff-only origin/main BASE_SHA$(git rev-parse origin/main) BRANCHtideclaw/alpha/$(date -u %Y-%m-%d-%H%MZ) git switch -c $BRANCH $BASE_SHA改动前必读仓库发布文档/脚本AGENTS.mddocs/下的发布文档如 docs/ci/release-validation/full-release-validation.mdscripts/下的发布脚本.github/workflows/*release*幂等检查将$BASE_SHA与上次成功的 alpha 状态及当前 git/npm/GitHub alpha 标签对比若已发布则报告 skip 且不发布。人工触发等价于 alpha cronCRON_IDfrom release-private OPENCLAW_ALLOW_ROOT1 openclaw cron run $CRON_ID --expect-final --timeout 21600000Discord 触发Alpha 与 BetaDiscord Alpha Trigger当维护者在#releases或#maintainers提及 Tideclaw 时可立即运行 alpha。接受的指令形态Tideclaw run alpha now Tideclaw alpha release from main now Tideclaw trigger alpha规则要点视同 alpha cron 的人工触发从当前origin/main新建tideclaw/alpha/YYYY-MM-DD-HHMMZ分支走正常 alpha 流程复用既有修复 → 本地检查 → 在 alpha 分支修复 → 运行发布 CI → 绿灯后发布 alpha → 以 fixes-only PR 前向移植若有其他 alpha/beta/stable 发布运行中报告活动分支/运行并停止#maintainers触发必须显式提及 Tideclaw不响应未提及的发布闲聊从$release-private解析 Discord 角色/用户 id 与主机 hotfix 备注。Discord Beta TriggerBeta 只能由维护者显式指令触发视为对 beta 的人工批准不代表对 stable/latest 的批准。接受的指令形态Tideclaw beta release from vYYYY.M.PATCH-alpha.N Tideclaw beta release from tideclaw/alpha/YYYY-MM-DD-HHMMZ Tideclaw beta release from latest proven alpha规则要点必须包含beta release字样和一个源 alpha 标签/分支或latest proven alpha源不明确时在#releases中问一个澄清问题并停止先验证源 alphaGitHub release、npmalpha包、发布 CI、记录的状态文件、分支/标签 SHA从已被证明的 alpha 源新建tideclaw/beta/YYYY-MM-DD-HHMMZ分支绝不从移动的main直接建只复用/压缩已在 alpha 上验证过的稳定化修复不引入无关的 alpha 发布机制Beta 版本计算为vYYYY.M.PATCH-beta.N匹配 npm--tag beta选列车时忽略 alpha-only patch 号在 beta 分支上运行 beta 发布校验/preflight/完整发布 CI 并修复失败Beta 绿灯后才发布使用 GitHub Actions/OIDC绝不在主机上直接 npm publish最终 Discord 总结必须包含源 alpha、beta 标签/版本、分支、修复提交、workflow run IDs、npm/GitHub 证明、任何跳过/阻塞原因beta 发布后按同样的 fixes-only PR 规则前向移植。复用既有修复Reuse Prior Fixes运行检查前先挖掘近期 Tideclaw alpha 分支上已做过的修复从$release-private的 Tideclaw 状态文件读取上次成功 alpha 分支与 fix commit SHAs列出远端分支git for-each-ref refs/remotes/origin/tideclaw/alpha --format%(refname:short) %(committerdate:iso-strict)只考虑最近 3 天的 Tideclaw alpha 分支加上上次成功的 alpha 分支对每个候选分支检查不在当前origin/main中的提交git log --no-merges --reverse --format%H%x09%s origin/main..origin/tideclaw/alpha/YYYY-MM-DD-HHMMZ只 cherry-pick 仍能应用到新 alpha 分支的真实稳定化修复。若这是发现而非复用状态文件中已批准的修复必须先过 nightly backport 审计clean cherry-pick 或无害的标题都不是批准依据。优先采用状态文件中记录的fixCommitShas跳过版本号 bump、changelog release 条目、标签产物、生成的发布说明、纯状态文件提交、一次性调试插桩cherry-pick 冲突时先检查当前 main 是否已含等价修复若没有则最小化解冲突并保持提交信息清晰在 alpha 状态与最终 Discord 总结中分开记录复用的 commit SHAs 与新建的 fix SHAs。用git cherry、git range-diff和定向测试重跑避免与main上已有的修复重复。修复循环Repair Loop把 alpha 分支当作 release-candidate 的修复表面先跑窄范围本地检查变更测试、release preflight、发布文档要求的类型/lint/build 门本地检查失败 → 在 alpha 分支上以最小提交修复每个连贯修复以 Tideclaw 身份提交每次修复后重跑失败的本地检查不要通过编辑基线、预期失败列表、ignore 文件或发布清单来掩盖失败除非发布文档明确要求且 diff 有正当理由失败若为 flaky重跑一次仍红则视为真实失败修复若明显对 main 有用保持小而可移植alpha 稳定化期间避免大范围重构。提交示例git add files git commit -m fix: stabilize alpha release preflight git push -u origin $BRANCH发布 CIRelease CI从 preflight 到 publish wrapper触发 Full Release Validation 与 npm preflight本地证明通过后从既有 git 标签、npm 版本与 GitHub releases 计算下一个vYYYY.M.PATCH-alpha.NPATCH取自 stable/beta 列车而非日期或最高 alpha-only patch复用同一 alpha 列车并递增alpha.N直到该 patch 出现 beta 后用下一 patch让 alpha 分支的包版本与 release 元数据匹配该标签提交并推送分支用 GitHub CLI 而非 browser/fetch 工具运行发布校验。在 Tideclaw 主机上裸gh是只读的 Codex 沙箱包装器写命令workflow run、run cancel、发布 dispatch使用/usr/local/bin/gh-tideclaw-writeGH/usr/local/bin/gh-tideclaw-write SHA$(git rev-parse HEAD) TAGv$(node -p require(./package.json).version) BRANCH$(git branch --show-current) $GH workflow run full-release-validation.yml --repo openclaw/openclaw --ref $BRANCH \ -f ref$BRANCH \ -f expected_sha$SHA \ -f release_profilebeta \ -f rerun_groupall $GH workflow run openclaw-npm-release.yml --repo openclaw/openclaw --ref $BRANCH \ -f tag$SHA \ -f preflight_onlytrue \ -f npm_dist_tagalpha这里release_profilebeta与 full-release-validation.yml 的输入定义一致beta 档案保持最快的 OpenAI/core 发布关键通道run_release_soak默认falsestable/full 强制开启。rerun_groupall是 full-release-validation.yml 提供的验证组之一还有ci、plugin-prerelease、install-smoke、cross-os、live-e2e、package、qa-parity、qa-live、npm-telegram、performance而 openclaw-release-publish.yml 会硬性校验npm 发布前 Full Release Validation 必须跑过rerun_groupall。用gh run list、gh run view、gh api观察确切的 workflow run IDs 与 head SHA。只读gh用于轮询没问题只有变更 GitHub 的命令才用$GH。不要用 Codex browser/fetch 轮询 GitHub API——文档明确记录此前 Tideclaw 运行在 preflight 成功之后在此失败过Alpha 的阻断门是 Tideclaw 能直接修复或能证明包安全性的门正常 CI、plugin prerelease、npm preflight、包准备、install smoke、tag/可达性、发布验证。建议门advisory包括跨 OS、live channel、QA Lab、包验收、长时 Docker E2E、Telegram 包 E2E——这些在 Discord 中报告并继续只要阻断门全绿若rerun_groupall仅在 CI、plugin prerelease、npm preflight、包准备、install smoke 全绿后卡在建议通道上可在同一 head 上派发聚焦的-f rerun_groupinstall-smokeFull Release Validation用这次成功的聚焦运行作为发布证明并把独立的 CI/plugin/full 建议 run IDs 写进 Discord 总结阻断门失败 → 在 alpha 分支修复、推送只重跑失败或必需的发布 CI。若提交变化丢弃旧的 preflight/full-validation run IDs并为新 head 重跑同一分支 head 上 full validation 与 npm preflight 全绿后审阅 npm preflight 的Plugin SDK API diff摘要若报告有变更下载plugin-sdk-api-release-diff-npm-preflight-run-id-run-attempt工件检查变更的声明将PLUGIN_SDK_API_ACKNOWLEDGEMENT设为其digest前 8 个字符否则置为空字符串。然后从该确切提交创建并推送发布标签NPM_PREFLIGHT_RUN_ATTEMPT$(gh api \ repos/openclaw/openclaw/actions/runs/${NPM_PREFLIGHT_RUN_ID} \ --jq .run_attempt) plugin_sdk_diff_dir$(mktemp -d) gh run download $NPM_PREFLIGHT_RUN_ID --repo openclaw/openclaw \ --name plugin-sdk-api-release-diff-${NPM_PREFLIGHT_RUN_ID}-${NPM_PREFLIGHT_RUN_ATTEMPT} \ --dir $plugin_sdk_diff_dir jq {digest, entrypointsAdded, entrypointsRemoved, exports} \ $plugin_sdk_diff_dir/plugin-sdk-api-release-diff.json PLUGIN_SDK_API_ACKNOWLEDGEMENT # 审阅非空 diff 后使用其打印的 digest # PLUGIN_SDK_API_ACKNOWLEDGEMENT$(jq -r .digest[0:8] \ # $plugin_sdk_diff_dir/plugin-sdk-api-release-diff.json) git tag -a $TAG $SHA -m openclaw ${TAG#v} git push origin $TAG rm -rf $plugin_sdk_diff_dirPLUGIN_SDK_API_ACKNOWLEDGEMENT正是 openclaw-release-publish.yml 定义的输入8 字符 Plugin SDK API diff digest发布器会用 scripts/plugin-sdk-api-release-evidence.mjs 等校验器对账 manifest 与不可变工件参见 openclaw-release-publish.yml 的cmp一致性检查。从同一 alpha 分支派发发布 wrapper使用同一 head SHA 上成功的 npm preflight run ID 与 full release validation run ID 及精确 attemptFULL_RELEASE_VALIDATION_RUN_ATTEMPT$(gh api \ repos/openclaw/openclaw/actions/runs/${FULL_RELEASE_VALIDATION_RUN_ID} \ --jq .run_attempt) $GH workflow run openclaw-release-publish.yml --repo openclaw/openclaw --ref $BRANCH \ -f tag$TAG \ -f preflight_run_id$NPM_PREFLIGHT_RUN_ID \ -f full_release_validation_run_id$FULL_RELEASE_VALIDATION_RUN_ID \ -f full_release_validation_run_attempt$FULL_RELEASE_VALIDATION_RUN_ATTEMPT \ -f plugin_sdk_api_acknowledgement$PLUGIN_SDK_API_ACKNOWLEDGEMENT \ -f npm_dist_tagalpha \ -f plugin_publish_scopeall-publishable \ -f publish_openclaw_npmtrue \ -f release_profilebeta \ -f wait_for_clawhubfalse发布器 openclaw-release-publish.yml 会做一系列硬校验tag 格式必须是vYYYY.M.PATCH(-alpha.N|-beta.N|...)alpha 标签必须配 npm dist-tagalphaL176-L179发布子任务要求父任务运行在受保护的release-publish/标签或匹配的 Tideclaw alpha 分支上L289-L295发布 tag 必须可达自main、release/*、extended-stable/*或匹配的 alpha 分支L892-L926。publish_openclaw_npmtrue还要求plugin_publish_scopeall-publishable保证每个可发布的官方插件随 OpenClaw 一起发布L296-L299。观察发布 wrapper 及其子运行。若openclaw-npm-release.yml卡在等待npm-release环境审批而 Tideclaw 无法批准将其报告为唯一阻塞项不得宣布发布完成绝不在主机上直接 npm publish一律走 GitHub Actions/OIDC。关键区分openclaw-npm-release.yml带preflight_onlytrue时只准备工件不会发布。一次成功的 alpha 必须包含后续的openclaw-release-publish.ymlwrapper、推送的 git tag、npmalphadist-tag 证明与 GitHub prerelease。验证已发布的 AlphaVerify Published Alpha直到以下全部为真发布才不算完成GitHub tag 存在GitHub Release 存在且标记为prereleaseRelease 正文链接 npm 版本页、registry tarball、integrity 与 CI/proofnpm view openclawversion显示确切版本、dist-tagalpha、tarball、integrity 与发布时间安装/包 smoke 遵循仓库发布文档$release-private的 Tideclaw 状态文件记录了版本、tag、base SHA、分支、fix commit SHAs、workflow run IDs、npm integrity 与时间戳。最终 Discord 总结发在#releases需包含tag/version、base SHA、branch、fix commits、workflow run IDs、npm/GitHub proof、以及未发布时的 skipped/blocked 原因。使用 Discord 安全的 Markdown 链接尖括号目标绝不打印 secrets。前向移植Forward-Port把修复回传 main成功 alpha 之后向main提一个 fixes-only PR从当前origin/main创建/更新前向移植分支git fetch origin main --prune git switch -c tideclaw/forward-port/$(date -u %Y-%m-%d-%H%MZ) origin/main只 cherry-pick真实修复为了让 nightly/release 检查通过所必需的提交排除alpha 版本 bump、changelog release 条目、发布说明、tag 产物、生成的发布资产、纯状态文件提交、以及唯一目的是发布 alpha 的提交若提交混合了真实修复与发布/版本变更拆分它只把修复 hunks 重放到前向移植分支的新提交中冲突按最小 main 兼容修复解决运行相关变更/本地门推送并开 PR或使用仓库允许的 bot 合并路径等待必需 main CI 全绿失败则在 forward-port 分支修复并重跑报告 PR/合并 SHA 及任何故意未前向移植的提交。若前向移植前origin/main已独立红掉记录无关的失败检查并尽可能让 forward-port PR 在自身 head 上保持绿色。分支保留策略Branch Retention每次运行前后清理旧 alpha 分支列出origin/tideclaw/alpha/*保留时间戳在最近 3 天 UTC内的分支保留被活动 workflow run、开放 PR、release tag 或状态文件引用的分支只删除 Tideclaw 拥有的 alpha 分支git push origin --delete tideclaw/alpha/YYYY-MM-DD-HHMMZ绝不删除人工分支、beta 分支、stable 分支或未知前缀。停止条件Stop Conditions遇到以下情况必须停止并清晰报告发布文档/脚本在版本化或发布路径上不一致必需的 secrets/auth 不可用GitHub Actions 无法派发或观察真实修复尝试后必需发布门仍红发布后 npm/GitHub 状态不一致前向移植在无更大产品决策的情况下无法转绿。关键源码索引技能文档本体.agents/skills/release-openclaw-nightly/SKILL.md发布 umbrellarerun_group / release_profile / fail_fast 参数.github/workflows/full-release-validation.ymlnpm preflight 与发布门preflight_only语义.github/workflows/openclaw-npm-release.yml发布 wrappertag 校验、evidence 校验、alpha 分支约束.github/workflows/openclaw-release-publish.yml发布校验文档Validation SHA Tooling SHA 元组、release-publish/标签机制docs/ci/release-validation/full-release-validation.md发布 CI 技能immutable 计划、Release Decision 校验、pnpm frv恢复.agents/skills/release-openclaw-ci/SKILL.md【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考