Composio CLI 发布工作流全指南从自动 Beta、稳定版提升到失败恢复的 GitHub Releases 实战【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio导读本文基于 Composio 仓库中的 CLI Release Workflow 手册配属.agents/skills/cli-release/SKILL.md技能完整讲解独立composio命令行二进制与安装器所依托的 GitHub Release 发布体系如何区分自动 Beta、手动 Beta、稳定版提升与失败恢复四条路径如何用ghCLI 预检候选 Beta、核对资产与安装测试以及发布被中断或失败时如何安全恢复。读完本文你将掌握一套可直接执行的发布操作手册并理解 build-cli-binaries.yml、resolve-release-target.sh、verify-assets.sh 等底层脚本的判定逻辑与设计动机。Sources Of Truth谁在真正掌控 CLI 发布CLI 二进制发布不依赖 npm 或 Changesets而是由一组 GitHub Actions 工作流与脚本共同构成唯一事实来源sources of truth事实来源职责build-cli-binaries.yml拥有 Beta 与 Stable 两类 GitHub Release 的构建与发布resolve-release-target.sh决定发布 tag 与源 commit三种模式push 滚动 Beta、build-beta 派发、promote-stable 提升verify-assets.sh定义并要求六个规范资产全部uploadedcli.test-installation.yml发布后跨平台验证安装器与 shell 集成.changeset/config.json将composio/cli与composio/cli-local-tools加入ignore列表使其脱离 Changesets 发布轨道特别要注意ts.release.yml是 TypeScript SDK/npm 的发布列车不是CLI 二进制的常规发布路径。CLI 包在 ts/packages/cli/package.json 中被标记为 private版本号为开发哨兵值0.0.0-development永远不通过 Changesets 发布到 npm二进制资产只挂在 GitHub Release 上install.sh 与composio upgrade从 Releases 下载composio upgrade --beta则解析最新的 CLI 预发布版本。Choose The Path先归类需求再选择发布路径动手前必须先判断本次请求属于哪一类因为不同目标的入口、结果与验证方式完全不同目标路径结果发布一个普通 CLI 变更将已评审的 PR 合并到nextpush 自动构建滚动 Betarolling beta从某分支构建 Beta在该分支派发build-beta从该分支 commit 构建预发布版本发布稳定版 CLI在已有且经过测试的 Beta tag 上派发提升promotionBeta 的源 commit 被重建并以稳定 tag 发布恢复失败的提升检查 draft 后重跑或重新派发同一个 Beta未发布的 draft 可被恢复并替换资产build-cli-binaries.yml的 push 触发条件限定了 CLI 相关路径ts/packages/cli/**、ts/packages/cli-local-tools/**、install.sh、install/**、mise.toml等也就是说只有真正改动 CLI 的合并才会触发自动 Beta。手动派发则通过workflow_dispatch的action输入build-beta或promote-stable与可选version输入来控制。一个关键约束来自 resolve-release-target.sh私有 CLI 的package.json使用开发哨兵版本号永远不会被用来选择二进制版本。如果发布负责人需要一次有意的 minor 或 major 版本正确做法是派发一个显式指定版本号的 Beta → 完整验证 → 再提升那个确切的 Beta。Changeset Rule永远不要为被忽略的 CLI 包创建 Changesetcomposio/cli和composio/cli-local-tools位于 .changeset/config.json 的ignore列表中因此严禁为它们创建.changeset/*.md条目。一旦有人创建了指向被忽略包的 Changeset会触发一个非常隐蔽的连锁故障changesets/action进入 version-PR 模式但changeset version对被忽略的包不会产生任何 commitaction 最终以No commits between next and changeset-release/next失败并阻塞无关的 SDK 发布。这一点在 ts/scripts/validate-changesets.mjs 的实现中有直接印证findIgnoredChangesetReleases会扫描所有待处理的 Changeset凡命中config.ignore中包名的直接抛出异常错误信息明确说明“被忽略包的 Changeset 会让 release job 在打开空 PR 时失败”。正确的替代做法是如果 CLI 变更需要面向用户的说明直接编辑 ts/packages/cli/CHANGELOG.md。交接前必须运行守卫命令pnpm validate:changesets该命令定义在根 package.json 中对应ts/scripts/validate-changesets.mjs同时 test/release-workflow.test.ts 会校验.changeset/config.json的 ignore 列表、工作流与脚本之间的一致性防止这些约束悄然漂移。Inspect Candidates基于实时 GitHub 状态挑选 Beta选择候选 Beta 时必须使用 GitHub 的实时状态绝不从本地 tag 或记忆中的版本挑选因为发布状态随时可能变化。先列出最近 100 个 Release过滤出已发布的composio/cli预发布版本REPOSITORYComposioHQ/composio gh release list \ --repo $REPOSITORY \ --limit 100 \ --json tagName,isPrerelease,isDraft,publishedAt \ --jq .[] | select(.tagName | startswith(composio/cli)) | select(.isPrerelease and (.isDraft | not))对选中的候选要求它必须是已发布的预发布版本而非 draft然后检查其 commit 与资产BETA_TAGcomposio/cli0.0.0-beta.000 gh release view $BETA_TAG \ --repo $REPOSITORY \ --json tagName,isDraft,isPrerelease,publishedAt,targetCommitish,assets \ --jq {tagName,isDraft,isPrerelease,publishedAt,targetCommitish,assets:[.assets[] | {name,state}]}合格的 Beta 必须满足isDraft: false、isPrerelease: true且以下六个规范资产全部处于uploaded状态这六项与 verify-assets.sh 中的expected列表完全一一对应并与构建矩阵的四个平台保持一致composio-linux-x64.zipcomposio-linux-aarch64.zipcomposio-darwin-x64.zipcomposio-darwin-aarch64.zipcomposio-skill.zip随版本打包的 skills 包checksums.txt由 generate-checksums.ts 对dist/binaries下所有 zip 生成的校验和资产状态为何如此重要verify-assets.sh 的注释点明了原因一个资产可以出现在列表里但仍在处理中state ! uploaded这正是发布后出现 404 的典型成因。所以该脚本采用有界重试默认VERIFY_ATTEMPTS10次、每次间隔VERIFY_SLEEP_SECONDS15秒且单次快照同时查询名称与状态避免“检查与使用之间的时间窗口”。找到 Beta 后按其目标 commit 定位工作流运行记录并要求其全绿包括可复用的安装测试作业TARGET_COMMITreplace-with-targetCommitish gh run list \ --repo $REPOSITORY \ --workflow build-cli-binaries.yml \ --commit $TARGET_COMMIT \ --limit 10权限确认点如果用户只要求“发布稳定版”但没有点名具体 Beta tag那么你应该先展示解析出的候选并在派发前停下征得明确确认——稳定版提升是一次生产环境的写入操作。Build A Manual Beta显式版本与非版本化 Beta只有当用户明确要求构建 Beta 时才走这条路。选中的 ref 同时提供工作流定义与源 commit这正是“该 ref 上定义的工作流构建该 ref 的代码”的原因。常规的 next-patch Beta省略versionSOURCE_BRANCHreplace-with-branch gh workflow run build-cli-binaries.yml \ --repo $REPOSITORY \ --ref $SOURCE_BRANCH \ --raw-field actionbuild-beta有意的 minor 或 major 版本必须比最新稳定版更新例如 0.3.0gh workflow run build-cli-binaries.yml \ --repo $REPOSITORY \ --ref $SOURCE_BRANCH \ --raw-field actionbuild-beta \ --raw-field version0.3.0版本校验逻辑在 resolve-release-target.sh 中version必须匹配major.minor.patch且必须大于最新稳定版version_is_greater按数值比较而非字典序——注释明确解释了为何字典序会在 patch 超过 9 时出错。不传版本时next_beta_base_version取最新稳定版并patch 1作为基础版本最终 tag 形如composio/cliversion-beta.RUN_NUMBERRUN_NUMBER 保证唯一性。派发后要持续观察运行直到发布与安装测试结束。请牢记Beta 不是稳定版它不触发/releases/latest重定向也不能被匿名用户通过install.sh无参数安装获取除非显式传 tag。Promote A Beta To Stable从测试过的 Beta 提升稳定版稳定版 tag 通过去除 Beta 后缀推导${BETA_TAG%%-beta.*}例如composio/cli0.3.0-beta.123→composio/cli0.3.0。先确认目标稳定 tag 的现状STABLE_TAG${BETA_TAG%%-beta.*} gh release view $STABLE_TAG --repo $REPOSITORY --json tagName,isDraft,isPrerelease,publishedAt按结果分三种情况稳定 tag 不存在可以继续提升稳定 tag 是 draft可以恢复该 draft见下文失败恢复稳定 tag 已发布立即停止绝不覆盖已发布的 Release。然后在 Beta tag 上派发工作流——选中的 ref 提供不可变的源 commit工作流会先验证它与该 Beta Release 的目标 commit 一致再重新构建gh workflow run build-cli-binaries.yml \ --repo $REPOSITORY \ --ref $BETA_TAG \ --raw-field actionpromote-stable此处--ref传入的是 tag 而非分支。若命令返回了 URL 则直接使用否则通过以下方式定位新派发核对其创建时间与 actor 后再持续观察gh run list \ --repo $REPOSITORY \ --workflow build-cli-binaries.yml \ --event workflow_dispatch \ --commit $TARGET_COMMIT \ --limit 5 gh run watch RUN_ID --repo $REPOSITORY --compact --exit-statuspromote-stable的底层防御在 resolve-release-target.sh 中层层把关必须派发在tag上REF_TYPE tag否则报错退出该 tag 必须匹配composio/cliversion-beta.number格式通过 GitHub API 校验该 tag 的 Release 确实是 prerelease若稳定 tag 已是 draft 则允许恢复gh release view能按名称解析 draft若已发布则拒绝REST 的/releases/tags/{tag}对 draft 返回 404因此用gh release view判断isDraft校验target_commitish与当前COMMIT_SHA完全一致——这保证了“稳定版对应的二进制就是被测试过的那个 Beta 的源码构建产物”。Verify Completion发布完成的五重验证不要在任何一步缺失时宣布发布完成全部满足才算完成Build CLI Binaries工作流成功结束稳定 Release 已发布isDraft: false且isPrerelease: false六个规范资产全部存在且uploaded工作流的安装测试矩阵通过隐含提升来源的 Beta 本身是通过全部验证的。用一条命令核对最终状态gh release view $STABLE_TAG \ --repo $REPOSITORY \ --json tagName,isDraft,isPrerelease,publishedAt,targetCommitish,assets \ --jq {tagName,isDraft,isPrerelease,publishedAt,targetCommitish,assets:[.assets[] | {name,state}]}汇报内容应包含稳定 tag、被提升的 Beta、目标 commit、工作流 URL、资产数量与状态、安装测试结果。值得展开的是发布管线内部的“先 draft 后 publish”设计见 build-cli-binaries.yml 与 create-or-resume-draft.shRelease 先以draft形式创建并附带全部资产——draft 不会触发release: published事件也不会被/releases/latest重定向命中因此任何匿名消费者install.sh、重定向都不可能在任何资产挂载并验证完成之前观察到这个发布随后verify-assets.sh作为“响亮失败门”把关最后一步才用gh release edit --draftfalse --latest...将其翻转为已发布。此外release作业对同一个 tag 使用 job 级并发组cli-release-${{ needs.prepare.outputs.release_tag }}做串行化防止两次快速 push 或重跑交错上传资产。发布后的安装验证由 cli.test-installation.yml 承担它作为可复用工作流被build-cli-binaries.yml以workflow_call方式调用在多平台矩阵Ubuntu x64 / Ubuntu ARM64、macOS Intel / Apple Silicon覆盖 bash 与 zsh上真实执行install.sh验证 bundle 与入口符号链接、composio --version执行、shell 启动文件中的托管 PATH 块要求恰好一个 managed block保证幂等、自定义安装目录、卸载与错误处理等。这也是为什么发布负责人必须等到安装测试矩阵通过才能收工。Failure Recovery发布失败的分场景恢复手册失败场景处理方式构建矩阵失败任何 Release 都不应发布。修复源码产出新的 Beta再提升该候选存在 draft 但发布未完成检查失败原因后重跑或重新派发同一个 Beta。draft 的资产可用--clobber安全替换见 create-or-resume-draft.sh 的幂等恢复逻辑重复运行提示已发布这是有意的安全失败。核实已发布的 Release 后停止重复运行。其机制是按 tag 串行化后先运行的已发布后运行的撞上already published守卫并响亮地报错而不是悄悄覆盖线上 Release发布后安装失败不要改动已发布的 tag。通过新的 Beta 与下一个稳定 patch 向前修复TS 发布提示 release PR 无提交删除指向被忽略 CLI 包的待处理 Changeset将其说明保留在 CLI 的 CHANGELOG 中运行pnpm validate:changesets让下一次 push 重试 SDK 发布列车恢复操作的核心原则与源码守卫完全一致draft 是“可恢复的中间状态”已发布 tag 是“不可变的事实”。resolve-release-target.sh的promote-stable分支允许恢复 draft打印resuming (assets will be re-uploaded)但遇到已发布 tag 直接exit 1create-or-resume-draft.sh同样只有两种情况会安全继续——draft 存在clobber 重传或 Release 完全不存在新建其余一律报错。理解这层设计后遇到“红色 ❌”不应盲目重试而应先确认 tag 的真实状态。小结一次发布的生命周期把整套流程串起来一次规范的 CLI 发布是这样的闭环合并 PR 到next仅 CLI 相关路径→ 自动构建滚动 Beta基于 GitHub 实时状态挑选并验证候选 Beta六个资产uploaded、工作流与安装测试全绿若需要显式版本派发build-beta并携带version输入在通过验证的 Beta tag 上派发promote-stable由脚本守卫完成 commit 一致性校验与“不覆盖已发布 tag”的保护先 draft 建 Release、校验资产、再翻转为发布最后等待安装测试矩阵通过汇报稳定 tag、来源 Beta、目标 commit、工作流 URL、资产状态与安装结果若任何环节失败按失败场景表恢复且永远“向前修复”而不是改动已发布的 tag。需要再次强调的是这套 CLI 二进制发布体系与 TypeScript SDK 的 Changesets 发布是两套并行轨道CLI 包被 .changeset/config.json 显式 ignore其版本号由 GitHub Release tagcomposio/cliversion[-beta.n]唯一权威决定而不是由package.json或 Changeset 决定。理解这条边界是安全操作 Composio CLI 发布的起点。【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Composio CLI 发布工作流全指南：从自动 Beta、稳定版提升到失败恢复的 GitHub Releases 实战
Composio CLI 发布工作流全指南从自动 Beta、稳定版提升到失败恢复的 GitHub Releases 实战【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio导读本文基于 Composio 仓库中的 CLI Release Workflow 手册配属.agents/skills/cli-release/SKILL.md技能完整讲解独立composio命令行二进制与安装器所依托的 GitHub Release 发布体系如何区分自动 Beta、手动 Beta、稳定版提升与失败恢复四条路径如何用ghCLI 预检候选 Beta、核对资产与安装测试以及发布被中断或失败时如何安全恢复。读完本文你将掌握一套可直接执行的发布操作手册并理解 build-cli-binaries.yml、resolve-release-target.sh、verify-assets.sh 等底层脚本的判定逻辑与设计动机。Sources Of Truth谁在真正掌控 CLI 发布CLI 二进制发布不依赖 npm 或 Changesets而是由一组 GitHub Actions 工作流与脚本共同构成唯一事实来源sources of truth事实来源职责build-cli-binaries.yml拥有 Beta 与 Stable 两类 GitHub Release 的构建与发布resolve-release-target.sh决定发布 tag 与源 commit三种模式push 滚动 Beta、build-beta 派发、promote-stable 提升verify-assets.sh定义并要求六个规范资产全部uploadedcli.test-installation.yml发布后跨平台验证安装器与 shell 集成.changeset/config.json将composio/cli与composio/cli-local-tools加入ignore列表使其脱离 Changesets 发布轨道特别要注意ts.release.yml是 TypeScript SDK/npm 的发布列车不是CLI 二进制的常规发布路径。CLI 包在 ts/packages/cli/package.json 中被标记为 private版本号为开发哨兵值0.0.0-development永远不通过 Changesets 发布到 npm二进制资产只挂在 GitHub Release 上install.sh 与composio upgrade从 Releases 下载composio upgrade --beta则解析最新的 CLI 预发布版本。Choose The Path先归类需求再选择发布路径动手前必须先判断本次请求属于哪一类因为不同目标的入口、结果与验证方式完全不同目标路径结果发布一个普通 CLI 变更将已评审的 PR 合并到nextpush 自动构建滚动 Betarolling beta从某分支构建 Beta在该分支派发build-beta从该分支 commit 构建预发布版本发布稳定版 CLI在已有且经过测试的 Beta tag 上派发提升promotionBeta 的源 commit 被重建并以稳定 tag 发布恢复失败的提升检查 draft 后重跑或重新派发同一个 Beta未发布的 draft 可被恢复并替换资产build-cli-binaries.yml的 push 触发条件限定了 CLI 相关路径ts/packages/cli/**、ts/packages/cli-local-tools/**、install.sh、install/**、mise.toml等也就是说只有真正改动 CLI 的合并才会触发自动 Beta。手动派发则通过workflow_dispatch的action输入build-beta或promote-stable与可选version输入来控制。一个关键约束来自 resolve-release-target.sh私有 CLI 的package.json使用开发哨兵版本号永远不会被用来选择二进制版本。如果发布负责人需要一次有意的 minor 或 major 版本正确做法是派发一个显式指定版本号的 Beta → 完整验证 → 再提升那个确切的 Beta。Changeset Rule永远不要为被忽略的 CLI 包创建 Changesetcomposio/cli和composio/cli-local-tools位于 .changeset/config.json 的ignore列表中因此严禁为它们创建.changeset/*.md条目。一旦有人创建了指向被忽略包的 Changeset会触发一个非常隐蔽的连锁故障changesets/action进入 version-PR 模式但changeset version对被忽略的包不会产生任何 commitaction 最终以No commits between next and changeset-release/next失败并阻塞无关的 SDK 发布。这一点在 ts/scripts/validate-changesets.mjs 的实现中有直接印证findIgnoredChangesetReleases会扫描所有待处理的 Changeset凡命中config.ignore中包名的直接抛出异常错误信息明确说明“被忽略包的 Changeset 会让 release job 在打开空 PR 时失败”。正确的替代做法是如果 CLI 变更需要面向用户的说明直接编辑 ts/packages/cli/CHANGELOG.md。交接前必须运行守卫命令pnpm validate:changesets该命令定义在根 package.json 中对应ts/scripts/validate-changesets.mjs同时 test/release-workflow.test.ts 会校验.changeset/config.json的 ignore 列表、工作流与脚本之间的一致性防止这些约束悄然漂移。Inspect Candidates基于实时 GitHub 状态挑选 Beta选择候选 Beta 时必须使用 GitHub 的实时状态绝不从本地 tag 或记忆中的版本挑选因为发布状态随时可能变化。先列出最近 100 个 Release过滤出已发布的composio/cli预发布版本REPOSITORYComposioHQ/composio gh release list \ --repo $REPOSITORY \ --limit 100 \ --json tagName,isPrerelease,isDraft,publishedAt \ --jq .[] | select(.tagName | startswith(composio/cli)) | select(.isPrerelease and (.isDraft | not))对选中的候选要求它必须是已发布的预发布版本而非 draft然后检查其 commit 与资产BETA_TAGcomposio/cli0.0.0-beta.000 gh release view $BETA_TAG \ --repo $REPOSITORY \ --json tagName,isDraft,isPrerelease,publishedAt,targetCommitish,assets \ --jq {tagName,isDraft,isPrerelease,publishedAt,targetCommitish,assets:[.assets[] | {name,state}]}合格的 Beta 必须满足isDraft: false、isPrerelease: true且以下六个规范资产全部处于uploaded状态这六项与 verify-assets.sh 中的expected列表完全一一对应并与构建矩阵的四个平台保持一致composio-linux-x64.zipcomposio-linux-aarch64.zipcomposio-darwin-x64.zipcomposio-darwin-aarch64.zipcomposio-skill.zip随版本打包的 skills 包checksums.txt由 generate-checksums.ts 对dist/binaries下所有 zip 生成的校验和资产状态为何如此重要verify-assets.sh 的注释点明了原因一个资产可以出现在列表里但仍在处理中state ! uploaded这正是发布后出现 404 的典型成因。所以该脚本采用有界重试默认VERIFY_ATTEMPTS10次、每次间隔VERIFY_SLEEP_SECONDS15秒且单次快照同时查询名称与状态避免“检查与使用之间的时间窗口”。找到 Beta 后按其目标 commit 定位工作流运行记录并要求其全绿包括可复用的安装测试作业TARGET_COMMITreplace-with-targetCommitish gh run list \ --repo $REPOSITORY \ --workflow build-cli-binaries.yml \ --commit $TARGET_COMMIT \ --limit 10权限确认点如果用户只要求“发布稳定版”但没有点名具体 Beta tag那么你应该先展示解析出的候选并在派发前停下征得明确确认——稳定版提升是一次生产环境的写入操作。Build A Manual Beta显式版本与非版本化 Beta只有当用户明确要求构建 Beta 时才走这条路。选中的 ref 同时提供工作流定义与源 commit这正是“该 ref 上定义的工作流构建该 ref 的代码”的原因。常规的 next-patch Beta省略versionSOURCE_BRANCHreplace-with-branch gh workflow run build-cli-binaries.yml \ --repo $REPOSITORY \ --ref $SOURCE_BRANCH \ --raw-field actionbuild-beta有意的 minor 或 major 版本必须比最新稳定版更新例如 0.3.0gh workflow run build-cli-binaries.yml \ --repo $REPOSITORY \ --ref $SOURCE_BRANCH \ --raw-field actionbuild-beta \ --raw-field version0.3.0版本校验逻辑在 resolve-release-target.sh 中version必须匹配major.minor.patch且必须大于最新稳定版version_is_greater按数值比较而非字典序——注释明确解释了为何字典序会在 patch 超过 9 时出错。不传版本时next_beta_base_version取最新稳定版并patch 1作为基础版本最终 tag 形如composio/cliversion-beta.RUN_NUMBERRUN_NUMBER 保证唯一性。派发后要持续观察运行直到发布与安装测试结束。请牢记Beta 不是稳定版它不触发/releases/latest重定向也不能被匿名用户通过install.sh无参数安装获取除非显式传 tag。Promote A Beta To Stable从测试过的 Beta 提升稳定版稳定版 tag 通过去除 Beta 后缀推导${BETA_TAG%%-beta.*}例如composio/cli0.3.0-beta.123→composio/cli0.3.0。先确认目标稳定 tag 的现状STABLE_TAG${BETA_TAG%%-beta.*} gh release view $STABLE_TAG --repo $REPOSITORY --json tagName,isDraft,isPrerelease,publishedAt按结果分三种情况稳定 tag 不存在可以继续提升稳定 tag 是 draft可以恢复该 draft见下文失败恢复稳定 tag 已发布立即停止绝不覆盖已发布的 Release。然后在 Beta tag 上派发工作流——选中的 ref 提供不可变的源 commit工作流会先验证它与该 Beta Release 的目标 commit 一致再重新构建gh workflow run build-cli-binaries.yml \ --repo $REPOSITORY \ --ref $BETA_TAG \ --raw-field actionpromote-stable此处--ref传入的是 tag 而非分支。若命令返回了 URL 则直接使用否则通过以下方式定位新派发核对其创建时间与 actor 后再持续观察gh run list \ --repo $REPOSITORY \ --workflow build-cli-binaries.yml \ --event workflow_dispatch \ --commit $TARGET_COMMIT \ --limit 5 gh run watch RUN_ID --repo $REPOSITORY --compact --exit-statuspromote-stable的底层防御在 resolve-release-target.sh 中层层把关必须派发在tag上REF_TYPE tag否则报错退出该 tag 必须匹配composio/cliversion-beta.number格式通过 GitHub API 校验该 tag 的 Release 确实是 prerelease若稳定 tag 已是 draft 则允许恢复gh release view能按名称解析 draft若已发布则拒绝REST 的/releases/tags/{tag}对 draft 返回 404因此用gh release view判断isDraft校验target_commitish与当前COMMIT_SHA完全一致——这保证了“稳定版对应的二进制就是被测试过的那个 Beta 的源码构建产物”。Verify Completion发布完成的五重验证不要在任何一步缺失时宣布发布完成全部满足才算完成Build CLI Binaries工作流成功结束稳定 Release 已发布isDraft: false且isPrerelease: false六个规范资产全部存在且uploaded工作流的安装测试矩阵通过隐含提升来源的 Beta 本身是通过全部验证的。用一条命令核对最终状态gh release view $STABLE_TAG \ --repo $REPOSITORY \ --json tagName,isDraft,isPrerelease,publishedAt,targetCommitish,assets \ --jq {tagName,isDraft,isPrerelease,publishedAt,targetCommitish,assets:[.assets[] | {name,state}]}汇报内容应包含稳定 tag、被提升的 Beta、目标 commit、工作流 URL、资产数量与状态、安装测试结果。值得展开的是发布管线内部的“先 draft 后 publish”设计见 build-cli-binaries.yml 与 create-or-resume-draft.shRelease 先以draft形式创建并附带全部资产——draft 不会触发release: published事件也不会被/releases/latest重定向命中因此任何匿名消费者install.sh、重定向都不可能在任何资产挂载并验证完成之前观察到这个发布随后verify-assets.sh作为“响亮失败门”把关最后一步才用gh release edit --draftfalse --latest...将其翻转为已发布。此外release作业对同一个 tag 使用 job 级并发组cli-release-${{ needs.prepare.outputs.release_tag }}做串行化防止两次快速 push 或重跑交错上传资产。发布后的安装验证由 cli.test-installation.yml 承担它作为可复用工作流被build-cli-binaries.yml以workflow_call方式调用在多平台矩阵Ubuntu x64 / Ubuntu ARM64、macOS Intel / Apple Silicon覆盖 bash 与 zsh上真实执行install.sh验证 bundle 与入口符号链接、composio --version执行、shell 启动文件中的托管 PATH 块要求恰好一个 managed block保证幂等、自定义安装目录、卸载与错误处理等。这也是为什么发布负责人必须等到安装测试矩阵通过才能收工。Failure Recovery发布失败的分场景恢复手册失败场景处理方式构建矩阵失败任何 Release 都不应发布。修复源码产出新的 Beta再提升该候选存在 draft 但发布未完成检查失败原因后重跑或重新派发同一个 Beta。draft 的资产可用--clobber安全替换见 create-or-resume-draft.sh 的幂等恢复逻辑重复运行提示已发布这是有意的安全失败。核实已发布的 Release 后停止重复运行。其机制是按 tag 串行化后先运行的已发布后运行的撞上already published守卫并响亮地报错而不是悄悄覆盖线上 Release发布后安装失败不要改动已发布的 tag。通过新的 Beta 与下一个稳定 patch 向前修复TS 发布提示 release PR 无提交删除指向被忽略 CLI 包的待处理 Changeset将其说明保留在 CLI 的 CHANGELOG 中运行pnpm validate:changesets让下一次 push 重试 SDK 发布列车恢复操作的核心原则与源码守卫完全一致draft 是“可恢复的中间状态”已发布 tag 是“不可变的事实”。resolve-release-target.sh的promote-stable分支允许恢复 draft打印resuming (assets will be re-uploaded)但遇到已发布 tag 直接exit 1create-or-resume-draft.sh同样只有两种情况会安全继续——draft 存在clobber 重传或 Release 完全不存在新建其余一律报错。理解这层设计后遇到“红色 ❌”不应盲目重试而应先确认 tag 的真实状态。小结一次发布的生命周期把整套流程串起来一次规范的 CLI 发布是这样的闭环合并 PR 到next仅 CLI 相关路径→ 自动构建滚动 Beta基于 GitHub 实时状态挑选并验证候选 Beta六个资产uploaded、工作流与安装测试全绿若需要显式版本派发build-beta并携带version输入在通过验证的 Beta tag 上派发promote-stable由脚本守卫完成 commit 一致性校验与“不覆盖已发布 tag”的保护先 draft 建 Release、校验资产、再翻转为发布最后等待安装测试矩阵通过汇报稳定 tag、来源 Beta、目标 commit、工作流 URL、资产状态与安装结果若任何环节失败按失败场景表恢复且永远“向前修复”而不是改动已发布的 tag。需要再次强调的是这套 CLI 二进制发布体系与 TypeScript SDK 的 Changesets 发布是两套并行轨道CLI 包被 .changeset/config.json 显式 ignore其版本号由 GitHub Release tagcomposio/cliversion[-beta.n]唯一权威决定而不是由package.json或 Changeset 决定。理解这条边界是安全操作 Composio CLI 发布的起点。【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考