用 Composio CLI 编排 Stripe → Supabase → Vercel 端到端发布流水线：awesome-codex-skills 的 deploy-pipeline 实战指南-二趣网

用 Composio CLI 编排 Stripe → Supabase → Vercel 端到端发布流水线：awesome-codex-skills 的 deploy-pipeline 实战指南

【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills

导读

本指南基于 deploy-pipeline/SKILL.md 展开，讲解如何用一行脚本在 Shell 中串联 Stripe、Supabase、Vercel 三个服务的"发布全流程"：账单价格变更、数据库迁移、前端部署、健康检查与发布通告，并内置回滚预案。读完本文，你将掌握 Composio CLI 从连接、工具发现到composio execute/composio run的完整调用链，能把一套每周重复的发布动作固化成一个可复用的流水线脚本。

适用场景：什么时候该用这条流水线

deploy-pipeline 定位为"一次脚本启动整个 ship it 序列"，核心适用场景有三类：

全栈产品发布：一次发布同时触碰计费（Stripe）、数据库（Supabase）和前端（Vercel）三层；
预览版转生产：把 Vercel 预览构建提升为生产部署，同时翻转 Stripe 价格并执行 Supabase 迁移；
每周发布火车：同一套动作反复执行、需要稳定可靠，适合固化成脚本。

它解决的痛点是：发布动作分散在多个管理后台和 CLI 之间，容易漏步骤、顺序错乱、回滚无依据。流水线把这些动作收敛到一组可审计、可复现的命令中。

前置条件：安装、登录与连接四个 toolkit

在仓库的 connect/SKILL.md 中给出了 Composio CLI 的通用接入流程，deploy-pipeline 在其之上要求连接 4 个 toolkit：

curl -fsSL https://composio.dev/install | bash composio login composio link stripe composio link supabase composio link vercel composio link slack # for release announcements

几点实操补充：

composio login会打开浏览器完成认证，并可选择默认 org 与 project；在自动化流程中可用composio login -y跳过交互提示，并用composio whoami确认当前身份；
composio link <toolkit>每个 toolkit 只需走一次 OAuth，之后连接持久化；若某个命令报Connection required for <toolkit>，补跑对应composio link即可；
非交互式环境（如 CI）优先通过环境变量注入凭据：COMPOSIO_API_KEY认证、COMPOSIO_BASE_URL指向自定义 API 端点、COMPOSIO_SESSION_DIR覆盖产物存储目录、COMPOSIO_DISABLE_TELEMETRY=true关闭遥测；
全局日志级别可用--log-level <all|trace|debug|info|warning|error|fatal|none>控制，排查发布失败时建议先开到debug。

工具发现：别硬编码 slug，先搜索

Composio 的工具 schema 会随上游 API 演进而变化，deploy-pipeline 反复强调"以--get-schema校验为准"。这与仓库中 composio-skills/composio-automation/SKILL.md 的核心理念一致——永远先发现工具、拿到当前 schema，再执行。CLI 侧的发现命令如下：

composio search "create price" --toolkits stripe composio search "apply migration" --toolkits supabase composio search "create deployment" --toolkits vercel composio tools list stripe composio tools list supabase composio tools list vercel

composio search "<自然语言>" --toolkits <name>：按用途反查工具 slug；
composio tools list <toolkit>：列出某个 toolkit 下的全部工具；
不确定入参时，用composio execute <SLUG> --get-schema查看 JSON Schema，再用--dry-run做一次不落地的试跑，确认载荷合法后再正式执行。

常用 slug 清单（以`--get-schema`校验为准）

Stripe

STRIPE_CREATE_PRODUCT：创建产品；
STRIPE_CREATE_PRICE：为产品创建价格条目；
STRIPE_UPDATE_PRODUCT：更新产品属性（回滚时用于隐藏价格）；
STRIPE_LIST_PRICES：列出价格，核对lookup_key。

Supabase

SUPABASE_LIST_PROJECTS：列出项目，确认project_id；
SUPABASE_RUN_SQL_QUERY：执行任意 SQL（迁移后校验 schema 用）；
SUPABASE_LIST_MIGRATIONS：查看迁移历史；
SUPABASE_APPLY_MIGRATION：应用一条迁移。

Vercel

VERCEL_CREATE_A_NEW_DEPLOYMENT：从 git ref 触发新部署；
VERCEL_GET_A_DEPLOYMENT_BY_ID_OR_URL：查询部署状态（轮询就绪与否）；
VERCEL_LIST_DEPLOYMENTS：列出部署，找到上一个可回滚的版本；
VERCEL_PROMOTE_DEPLOYMENT：把指定部署提升为生产（回滚主手段）。

流水线总览：顺序就是正确性

deploy-pipeline 规定了一条不允许打乱的顺序：Stripe → Supabase → Vercel → Verify → Announce。

其工程理由是层层依赖：计费变更要在数据库结构就绪之前落地（避免新价格写入不存在的列），数据库迁移要在前端代码引用新列之前完成（否则线上读旧代码、写新 schema 会造成不一致），而发布通告必须等健康检查通过之后才发出。任何一步提前，都会把不完整状态暴露给用户或下游。

第 1 步：Stripe —— 创建或更新价格

composio execute STRIPE_CREATE_PRICE -d '{ "product":"prod_abc123", "unit_amount":2900, "currency":"usd", "recurring":{"interval":"month"}, "lookup_key":"team-plan-v2" }'

参数要点：

product：目标产品的 ID（可用STRIPE_LIST_PRICES/STRIPE_CREATE_PRODUCT配合确认）；
unit_amount：以最小货币单位（美分）计，2900即 $29.00/月——这是最常见的踩坑点，务必换算；
currency：ISO 4217 货币代码；
recurring.interval：订阅周期，常见取month/year；
lookup_key：应用侧 checkout 依赖的稳定标识，务必与前端实际 fetch 的 key 一致（见后文故障排查第一条）。

第 2 步：Supabase —— 应用迁移并校验 schema

composio execute SUPABASE_APPLY_MIGRATION -d '{ "project_id":"abcxyz", "name":"add_team_tier_column", "query":"alter table teams add column tier text default '\''free'\'';" }'

迁移落库后，立即做一次 schema 自检，确认列真的存在：

composio execute SUPABASE_RUN_SQL_QUERY -d '{ "project_id":"abcxyz", "query":"select column_name from information_schema.columns where table_name='\''teams'\'' and column_name='\''tier'\'';" }'

注意 shell 中对 SQL 字符串内单引号的转义：外层用双引号包裹 JSON，内部 SQL 的单引号用'\''转义。若想避免转义混乱，可把载荷写成独立文件再传入（配合 workflow 脚本更干净）。

第 3 步：Vercel —— 触发部署并轮询就绪

从 git ref 触发生产部署：

# Trigger a production deployment from a git ref composio execute VERCEL_CREATE_A_NEW_DEPLOYMENT -d '{ "name":"web", "target":"production", "gitSource":{"type":"github","ref":"main","repoId":123456} }'

target：production表示直接发生产；预览构建对应 preview 环境；
gitSource.ref：本次要发布的 git 分支或 tag，应来源于流水线入参（见下文ship.ts）；
repoId：Vercel 侧的 GitHub 仓库 ID。

随后轮询部署状态，直到READY或ERROR：

composio execute VERCEL_GET_A_DEPLOYMENT_BY_ID_OR_URL -d '{"idOrUrl":"dpl_xxx"}' \ | jq '.readyState'

第 4 步：验证 —— 健康检查与数据完整性

发布不等于成功，验证环节包含两层检查：

curl -fsS https://app.acme.com/api/health composio execute SUPABASE_RUN_SQL_QUERY -d '{ "project_id":"abcxyz","query":"select count(*) from teams where tier is null;" }'

第一层：前端/API 的健康端点必须返回 200（curl -fsS失败即非零退出码）；
第二层：数据完整性抽查——例如"仍为 NULL 的tier列数量"，预期为 0，这是对迁移正确性的业务级验证。

第 5 步：通告 —— 把结果同步到 Slack

composio execute SLACK_SEND_MESSAGE -d '{ "channel":"releases", "text":"✅ Team Plan v2 shipped. Stripe price `team-plan-v2` live, Supabase migration applied, Vercel production promoted." }'

通告文案建议包含三要素：发了什么（ref / 版本）、动了哪些层（价格、迁移、部署）、证据（部署 URL、价格 ID），便于后续审计。

把流水线固化成 Workflow 文件：ship.ts

上述 5 步可以写成可复用的工作流脚本，composio run --file执行，入参通过--后的参数传入。deploy-pipeline 提供的完整脚本如下：

const ref = process.argv[process.argv.indexOf("--ref") + 1] ?? "main"; // 1. Stripe const price = await execute("STRIPE_CREATE_PRICE", { product: "prod_abc123", unit_amount: 2900, currency: "usd", recurring: { interval: "month" }, lookup_key: "team-plan-v2" }); // 2. Supabase await execute("SUPABASE_APPLY_MIGRATION", { project_id: "abcxyz", name: "add_team_tier_column", query: "alter table teams add column tier text default 'free';" }); // 3. Vercel const dep = await execute("VERCEL_CREATE_A_NEW_DEPLOYMENT", { name: "web", target: "production", gitSource: { type: "github", ref, repoId: 123456 } }); // 4. Wait for ready let state = "QUEUED"; while (state !== "READY" && state !== "ERROR") { await new Promise(r => setTimeout(r, 4000)); const d = await execute("VERCEL_GET_A_DEPLOYMENT_BY_ID_OR_URL", { idOrUrl: dep.id }); state = d.readyState; } if (state !== "READY") throw new Error("Vercel deploy failed"); // 5. Announce await execute("SLACK_SEND_MESSAGE", { channel: "releases", text: `✅ Shipped ${ref}. Stripe price ${price.id}, Vercel ${dep.url}.` });

运行方式（假设脚本存放在scripts/ship.ts）：

composio run --file scripts/ship.ts -- --ref main

脚本的几个工程细节值得留意：

入参传递：--ref main通过process.argv解析，缺省回落到main，让脚本在未显式传参时也安全；
串行与轮询：Vercel 部署用 4 秒间隔轮询readyState，QUEUED/BUILDING会持续等待，直到READY或ERROR，并在非READY时立刻throw——把"部署失败"变成流水线的硬失败信号，阻断后续通告；
状态穿透：Stripe 返回的price.id、Vercel 返回的dep.url直接拼进 Slack 通告，做到"通告即证据"；
可组合性：与composio run的通用能力一致（见 connect/SKILL.md 中的composio run --file ./workflow.ts -- --repo ...用法），任何重复性发布序列都可以照此固化为文件。

回滚计划：按相反顺序拆

验证失败时，按Vercel → Supabase → Stripe → Slack的逆序回滚——先止血线上，再清理数据，最后处理计费：

Vercel：用VERCEL_PROMOTE_DEPLOYMENT把之前的部署 ID 提升回生产，恢复旧前端；
Supabase：应用 down migration 撤销结构变更。硬性要求：发布前必须为每条迁移写好配对的down.sql，否则回滚时无脚本可用；
Stripe：用STRIPE_UPDATE_PRODUCT把新价格设为active:false隐藏起来。切勿 delete——Stripe 对象在实践中不可变，删除会破坏历史发票的引用完整性；
Slack：通告回滚结果，让团队与用户同步知情。

故障排查：四个高频问题与根因

deploy-pipeline 整理了四个典型的发布期故障及对策：

Stripe 新价格可见，但 checkout 仍显示旧价→ 应用侧缓存所致。先确认 checkout 实际 fetch 的lookup_key是否指向新价格，再看缓存策略；
Supabase 迁移挂起→ 有别的连接持有锁。执行select pid, state, query from pg_stat_activity where state <> 'idle';找出阻塞事务；
Vercel 部署卡在QUEUED→ 查看构建日志定位问题：VERCEL_GET_A_DEPLOYMENT_BY_ID_OR_URL配合?logs=1拉取日志；
顺序错误（前端引用了迁移前不存在的列）→ 根因是把步骤并行化了。流水线必须串行执行，永远不要对 Stripe/Supabase/Vercel 跨服务使用--parallel——composio execute --parallel只适合彼此无依赖的调用（例如同时拉取多条只读数据）。

企业官网建设流程全解析