当提交者不是团队成员时，如何从 CI 部署到 Vercel

我把 landee 迁进了一个 GitHub 组织，好让提交计入我自己的贡献图。结果紧接着的一次 push，生产环境就不再部署了。

Vercel 仪表盘就只显示这个——每次 push 都是。原本的原生 Git 集成，悄悄变成了一道闸门：

Deployment Blocked
The deployment was blocked because the commit could not be
matched to a team member.

Vercel 为什么拦截部署

Vercel 的原生 Git 集成是一种 webhook 部署：GitHub 发来 push 事件，Vercel 读取提交作者，检查其是否为 Vercel 团队成员，若不是就拦截部署。这是一道安全控制——它防止任意一个贡献者（或某个 fork 的 pull request）自动上线到生产环境。

这很合理——直到写代码的人并不是付费席位持有者。我的 GitHub 账号是提交的作者，但它不是 Vercel 团队成员。于是在集成看来，每次部署都来自“非成员”，每次都被拦截。

用 CLI 部署，而不是 Git 集成

出路是 CLI。vercel deploy 用令牌鉴权，而不是靠提交作者——它根本不跑成员检查。所以：断开原生 Git 集成，改从 GitHub Actions 部署——push → 工作流运行 → 带令牌的 vercel deploy → Vercel 构建并发布。

name: Deploy Production (Vercel CLI)

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
      VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
    steps:
      - uses: actions/checkout@v7
      - run: npm install -g vercel@latest
      - run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel deploy --prod --token=${{ secrets.VERCEL_TOKEN }}

两件事让它成为唯一的部署路径，避免 CLI 和 webhook 抢跑：vercel.json 关掉原生自动部署，你再在 Vercel 仪表盘里对 Git 仓库点 Disconnect。

{
  "git": { "deploymentEnabled": false },
  "installCommand": "pnpm install --frozen-lockfile"
}

保住你的 GitHub 贡献图

迁进组织的全部意义，就是让提交计入我的贡献图——所以 GitHub 上的提交必须仍以我为作者。这里本就如此：CLI 部署运行在 runner 里一份全新的 checkout 上，那里的任何东西都不会 push 回 GitHub。

于是我以自己的身份提交、push，绿色方块就填满了。授权部署的令牌属于账号所有者，而不是我——这正是 CI 部署的意义所在。

让仪表盘显示是谁 push 的

一次纯粹的 CLI 部署在 Vercel 列表里只是一个光秃秃的哈希——没有信息、没有分支、没有作者。要拿到一行真正的 git 风格记录（信息 + 分支 + 头像），Vercel 就得把这次部署识别为一个 git 提交——而正是这份识别会再次触发作者检查。

诀窍：在 runner 里把 HEAD 的作者改写成某个团队成员，然后再部署。这个 amend 永远不会被 push 回去，所以在 GitHub 上提交仍是你的。Vercel 从 .git 读到团队成员作者——部署既被识别又不被拦截——你再把真正的推送者写进提交信息，让那行记录仍显示是谁发布的。

# In the runner only — this amend is NEVER pushed back, so on GitHub the
# commit stays authored by the real pusher (your contribution graph is intact).
MSG="$(git log -1 --pretty=%s)"
git -c user.name="CI Bot" -c user.email="ci@your-org.dev" \
  commit --amend --author="CI Bot <ci@your-org.dev>" \
  -m "[$GITHUB_ACTOR] $MSG"

# Vercel now reads a team-member author from .git → recognized AND not blocked.
vercel deploy --prod --token="$VERCEL_TOKEN"

一个服务账号，大家都通过它部署

把它推广开来：一个服务账号拥有 Vercel 团队并持有部署令牌。所有人都以自己的身份提交；CI 把作者改写为服务账号，并用它的令牌部署。仪表盘那一行显示 [你] 你的提交信息，而 GitHub 保留你真实的作者身份。

这就是很多团队所追求之事的那个无趣而诚实的版本。你为需要访问仪表盘的人买席位——而不是每个贡献者一个。用一个 CI 令牌部署所有人的代码，正是 Vercel 所记载的模型；你不会仅仅因为某人的代码上线，就为他买一个席位。

会咬人的细节

几件让我搭进去一个晚上的事，好让你不必如此：

• Vercel 上的 pnpm。构建镜像可能无视你的 packageManager 字段，锁定一个旧版 pnpm。给 vercel deploy 传 --build-env ENABLE_EXPERIMENTAL_COREPACK=1，让 corepack 使用你真正锁定的版本。
• 已验证的提交。签名是另一回事——配置 SSH 提交签名并把密钥注册到 GitHub，你（真正的）提交就会获得绿色的 Verified 徽章。runner 里那次一次性的 amend 不需要签名。
• 可读的运行。把那一个巨大的 shell 步骤拆成命名步骤（re-author → deploy → summary），让 Actions 界面一眼就能看出处于哪个阶段。
• 测试。部署在 Vercel 上构建，却从不跑你的测试——为此加一个单独的 CI 工作流，顺手把 Dependabot 也打开。

CLI 部署由令牌授权，而不是由谁写了提交。这就是全部的解锁之道——而且这是一种有文档、正统的发布方式。

界线在哪里

咱们对这条界线诚实一点，因为很容易自我说服着越过它。通过 CI 令牌部署贡献者的代码是正当的、也是设计初衷。为了绕过按席位计费而注册假账号则不然——那是多账号操作，违反每一个平台的条款。

要点

• Vercel 的原生 Git 集成会拦截提交作者非团队成员的部署——这是安全闸门，不是 bug。
• 带令牌的 vercel deploy 从不检查作者；断开原生集成，改从 CI 部署。
• 以自己的身份提交、绝不 push runner 里的 amend，你的 GitHub 贡献图就完好无损。
• 在 runner 里把 HEAD 的作者改写为团队成员，能拿到真正的仪表盘记录且不被拦截——把真正的推送者写进信息。
• 你为仪表盘席位付费，而不是按贡献者付费：用一个 CI 令牌部署所有人的代码正是设计初衷。
• 为绕过计费而注册假账号就是多账号操作。界线就在这里。

这些零件没有一个是稀奇的——CLI、一个令牌、一次永不离开 runner 的 git amend。真正的转变，是意识到那面“非成员”的墙并不是叫你再买一个席位；它是在叫你按 CI 本该有的方式去部署。断开 webhook，把令牌交给 runner——让写代码的人，继续得到属于他的那份署名。