Deploy til Vercel fra CI, når den der committer, ikke er teammedlem

Jeg flyttede landee ind i en GitHub-organisation, så mine commits ville tælle i min egen bidragsgraf. Ved næste push holdt produktionen op med at deploye.

Vercel-dashboardet sagde bare dette — ved hver push. Den indbyggede Git-integration var stille blevet en bom:

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

Hvorfor Vercel blokerer deployet

Vercels indbyggede Git-integration er et webhook-deploy: GitHub sender en push-hændelse, Vercel læser commit-forfatteren, tjekker, om vedkommende er medlem af Vercel-teamet, og blokerer deployet, hvis ikke. Det er en sikkerhedskontrol — den forhindrer en tilfældig bidragyder, eller en forks pull request, i automatisk at gå i produktion.

Det giver mening — indtil den, der skriver koden, ikke er et betalt medlem. Min GitHub-konto står som forfatter til committene, men den er ikke medlem af Vercel-teamet. Så for integrationen er hvert deploy fra en «ikke-medlem», og hvert deploy blokeres.

Deploy med CLI'en, ikke Git-integrationen

CLI'en er vejen ud. vercel deploy autentificerer med et token, ikke med commit-forfatteren — den kører aldrig medlemskabstjekket. Så afbryd den indbyggede Git-integration og deploy fra GitHub Actions i stedet: push → workflowet kører → vercel deploy med et token → Vercel bygger og udgiver.

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 }}

To ting gør dette til den eneste deploy-vej, så CLI'en og webhooken ikke konkurrerer: vercel.json slår det indbyggede auto-deploy fra, og du trykker Disconnect på Git-repoet i Vercel-dashboardet.

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

Behold din GitHub-bidragsgraf

Hele pointen med org-flytningen var, at commits skulle tælle i min graf — så committen på GitHub skal forblive forfattet af mig. Det er allerede sådan her: CLI-deployet kører på et frisk checkout inde i runneren, og intet derfra pushes nogensinde tilbage til GitHub.

Så jeg committer som mig selv, pusher, og de grønne felter fyldes. Tokenet, der autoriserer deployet, tilhører kontoejeren, ikke mig — hvilket netop er pointen med et CI-deploy.

Lad dashboardet vise, hvem der pushede

Et almindeligt CLI-deploy dukker op i Vercel-listen som en nøgen hash — ingen besked, ingen gren, ingen forfatter. For at få en rigtig git-agtig række (besked + gren + avatar) skal Vercel genkende deployet som en git-commit — og netop den genkendelse kører forfattertjekket igen.

Tricket: inde i runneren, omskriv forfatteren til HEAD til et teammedlem, og deploy derefter. Amenden pushes aldrig tilbage, så på GitHub forbliver committen din. Vercel læser teammedlem-forfatteren fra .git — deployet genkendes og blokeres ikke — og du sætter den, der faktisk pushede, i commit-beskeden, så rækken stadig siger, hvem der udgav den.

# 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"

Én servicekonto, som alle deployer igennem

Generalisér: én servicekonto ejer Vercel-teamet og holder deploy-tokenet. Alle committer som sig selv; CI'en omskriver forfatteren til servicekontoen og deployer med dens token. Dashboard-rækken lyder [dig] din commit-besked, og GitHub beholder dit rigtige forfatterskab.

Det er den kedelige, ærlige version af det, mange teams rækker efter. Du betaler for pladserne til dem, der har brug for dashboard-adgang — ikke én pr. bidragyder. Et CI-token, der deployer alles kode, er den model, Vercel dokumenterer; du køber ikke en plads til nogen, bare fordi deres kode udgives.

Detaljerne, der bider

Et par ting, der kostede mig en aften, så de ikke koster dig en:

• pnpm på Vercel. Build-imaget kan låse en gammel pnpm uanset dit packageManager-felt. Send --build-env ENABLE_EXPERIMENTAL_COREPACK=1 til vercel deploy, så corepack bruger den version, du faktisk låste.
• Verificerede commits. Signering er en separat sag — opsæt SSH-signering af commits og registrér nøglen på GitHub, så får dine (rigtige) commits det grønne Verified-mærke. Runnerens engangs-amend behøver ingen signatur.
• Læsbare kørsler. Del det ene store shell-trin op i navngivne trin (re-author → deploy → summary), så Actions-grænsefladen viser fasen med ét blik.
• Tests. Deployet bygger på Vercel, men kører aldrig dine tests — tilføj et separat CI-workflow til det, og slå Dependabot til, mens du er i gang.

CLI-deployet autoriseres af et token, ikke af den, der skrev committen. Det er hele oplåsningen — og en dokumenteret, førsteklasses måde at udgive på.

Hvor grænsen går

Lad os være ærlige om grænsen, for det er let at tale sig forbi den. At deploye bidragyderes kode via et CI-token er legitimt og tænkt sådan. At oprette falske konti for at omgå plads-betalingen er det ikke — det er multi-kontoing, og det bryder vilkårene på enhver platform.

Pointer

• Vercels indbyggede Git-integration blokerer deploys, hvis commit-forfatter ikke er teammedlem — en sikkerhedsbom, ikke en fejl.
• vercel deploy med et token tjekker aldrig forfatteren; afbryd den indbyggede integration og deploy fra CI.
• Committ som dig selv, og push aldrig runnerens amend, så forbliver din GitHub-graf intakt.
• At omskrive forfatteren til HEAD til et teammedlem i runneren giver en rigtig dashboard-række uden blok — sæt den, der pushede, i beskeden.
• Du betaler for dashboard-pladser, ikke pr. bidragyder: et CI-token, der deployer alles kode, er den tiltænkte model.
• At oprette falske konti for at omgå betaling er multi-kontoing. Der går grænsen.

Ingen af disse dele er eksotiske — CLI'en, et token, et git amend, der aldrig forlader runneren. Vendepunktet er at indse, at «ikke-medlem»-væggen ikke beder dig købe endnu en plads; den beder dig deploye, som CI er tænkt til. Afbryd webhooken, giv tokenet til runneren — og lad den, der skrev koden, beholde æren for den.