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

Jeg flyttet landee inn i en GitHub-organisasjon slik at committene mine skulle telle i min egen bidragsgraf. Ved neste push sluttet produksjonen å deploye.

Vercel-dashbordet sa bare dette — ved hver push. Den innebygde Git-integrasjonen hadde stille blitt en sperre:

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

Hvorfor Vercel blokkerer deployen

Vercels innebygde Git-integrasjon er en webhook-deploy: GitHub sender en push-hendelse, Vercel leser commit-forfatteren, sjekker om vedkommende er medlem av Vercel-teamet, og blokkerer deployen hvis ikke. Det er en sikkerhetskontroll — den hindrer en tilfeldig bidragsyter, eller en forks pull request, i å automatisk gå ut i produksjon.

Det er fornuftig — helt til den som skriver koden ikke er et betalt medlem. GitHub-kontoen min står som forfatter av committene, men den er ikke medlem av Vercel-teamet. Så for integrasjonen er hver deploy fra en «ikke-medlem», og hver deploy blokkeres.

Deploy med CLI-en, ikke Git-integrasjonen

CLI-en er veien ut. vercel deploy autentiserer med et token, ikke med commit-forfatteren — den kjører aldri medlemskapssjekken. Så koble fra den innebygde Git-integrasjonen og deploy fra GitHub Actions i stedet: push → workflowet kjører → vercel deploy med et token → Vercel bygger og slipper.

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 gjør dette til den eneste deploy-veien, slik at CLI-en og webhooken ikke kappes: vercel.json slår av den innebygde auto-deployen, og du trykker Disconnect på Git-repoet i Vercel-dashbordet.

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

Behold GitHub-bidragsgrafen din

Hele poenget med org-flyttingen var at committene skulle telle i grafen min — så committen på GitHub må forbli forfattet av meg. Det er allerede slik her: CLI-deployen kjører på en fersk checkout inne i runneren, og ingenting derfra pushes noen gang tilbake til GitHub.

Så jeg committer som meg selv, pusher, og de grønne rutene fylles. Tokenet som autoriserer deployen tilhører kontoeieren, ikke meg — som er nettopp poenget med en CI-deploy.

La dashbordet vise hvem som pushet

En vanlig CLI-deploy dukker opp i Vercel-listen som en naken hash — ingen melding, ingen gren, ingen forfatter. For å få en ekte git-lignende rad (melding + gren + avatar) må Vercel gjenkjenne deployen som en git-commit — og nettopp den gjenkjenningen kjører forfattersjekken på nytt.

Trikset: inne i runneren, skriv om forfatteren til HEAD til et teammedlem, og deploy deretter. Amenden pushes aldri tilbake, så på GitHub forblir committen din. Vercel leser teammedlem-forfatteren fra .git — deployen gjenkjennes og blokkeres ikke — og du legger den som faktisk pushet i commit-meldingen, så raden fortsatt sier hvem som slapp 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 alle deployer gjennom

Generaliser: én servicekonto eier Vercel-teamet og holder deploy-tokenet. Alle committer som seg selv; CI-en skriver om forfatteren til servicekontoen og deployer med tokenet dens. Dashboard-raden lyder [du] commit-meldingen din, og GitHub beholder ditt ekte forfatterskap.

Dette er den kjedelige, ærlige versjonen av det mange team strekker seg etter. Du betaler for plassene til dem som trenger dashbord-tilgang — ikke én per bidragsyter. Et CI-token som deployer alles kode er modellen Vercel dokumenterer; du kjøper ingen plass til noen bare fordi koden deres går ut.

Detaljene som biter

Et par ting som kostet meg en kveld, så de ikke koster deg en:

• pnpm på Vercel. Byggbildet kan låse en gammel pnpm uansett packageManager-feltet ditt. Send --build-env ENABLE_EXPERIMENTAL_COREPACK=1 til vercel deploy så corepack bruker versjonen du faktisk låste.
• Verifiserte committer. Signering er en egen sak — sett opp SSH-signering av committer og registrer nøkkelen på GitHub, så får de (ekte) committene dine det grønne Verified-merket. Runnerens engangs-amend trenger ingen signatur.
• Lesbare kjøringer. Del det ene store shell-steget i navngitte steg (re-author → deploy → summary) så Actions-grensesnittet viser fasen med ett blikk.
• Tester. Deployen bygger på Vercel, men kjører aldri testene dine — legg til et eget CI-workflow for det, og slå på Dependabot mens du er i gang.

CLI-deployen autoriseres av et token, ikke av den som skrev committen. Det er hele opplåsningen — og en dokumentert, førsteklasses måte å slippe på.

Hvor grensen går

La oss være ærlige om grensen, for det er lett å snakke seg forbi den. Å deploye bidragsyteres kode via et CI-token er legitimt og ment slik. Å sette opp falske kontoer for å omgå plassbetalingen er det ikke — det er multi-kontoing, og det bryter vilkårene på enhver plattform.

Oppsummering

• Vercels innebygde Git-integrasjon blokkerer deployer der commit-forfatteren ikke er teammedlem — en sikkerhetssperre, ikke en feil.
• vercel deploy med et token sjekker aldri forfatteren; koble fra den innebygde integrasjonen og deploy fra CI.
• Committ som deg selv og push aldri runnerens amend, så forblir GitHub-grafen din intakt.
• Å skrive om forfatteren til HEAD til et teammedlem i runneren gir en ekte dashboard-rad uten blokk — legg den som pushet i meldingen.
• Du betaler for dashbord-plasser, ikke per bidragsyter: et CI-token som deployer alles kode er den tiltenkte modellen.
• Å lage falske kontoer for å omgå betaling er multi-kontoing. Der går grensen.

Ingen av disse bitene er eksotiske — CLI-en, et token, en git amend som aldri forlater runneren. Vendepunktet er å innse at «ikke-medlem»-veggen ikke ber deg kjøpe enda en plass; den ber deg deploye slik CI er ment å gjøre. Koble fra webhooken, gi tokenet til runneren — og la den som skrev koden beholde æren for den.