Skip to main content
Tillbaka till bloggen
VercelGitHub ActionsCI/CDDeploymentMonorepo

Deploya till Vercel från CI när den som committar inte är teammedlem

Flytta ett repo till en GitHub-organisation och Vercel börjar tyst blockera dina deployer: committen ”kunde inte matchas mot en teammedlem”. Så här deployar jag i stället från GitHub Actions med Vercels CLI — mina committar räknas fortfarande i min egen GitHub-graf, dashboarden visar fortfarande vem som pushade, och jag köper inte en plats per bidragsgivare.

Publicerad 10 augusti 20268 min läsning

Jag flyttade landee till en GitHub-organisation så att mina committar skulle räknas i min egen bidragsgraf. Vid nästa push slutade produktionen deploya.

Vercels dashboard sa bara det här — vid varje push. Den inbyggda Git-integrationen hade tyst blivit en spärr:

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

Varför Vercel blockerar deployen

Vercels inbyggda Git-integration är en webhook-deploy: GitHub skickar en push-händelse, Vercel läser commit-författaren, kollar om den är medlem i Vercel-teamet och blockerar deployen om inte. Det är en säkerhetskontroll — den hindrar en godtycklig bidragsgivare, eller en forks pull request, från att automatiskt gå ut i produktion.

Det är rimligt — ända tills den som skriver koden inte är en betald platsinnehavare. Mitt GitHub-konto står som författare till committarna, men det är inte medlem i Vercel-teamet. Så för integrationen är varje deploy från en ”icke-medlem”, och varje deploy blockeras.

Deploya med CLI:t, inte Git-integrationen

CLI:t är utvägen. vercel deploy autentiserar med ett token, inte med commit-författaren — det kör aldrig medlemskapskontrollen. Så koppla bort den inbyggda Git-integrationen och deploya från GitHub Actions i stället: push → workflowet körs → vercel deploy med ett token → Vercel bygger och släpper.

.github/workflows/deploy-production.yml
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 }}

Två saker gör detta till den enda deploy-vägen, så att CLI:t och webhooken inte tävlar: vercel.json stänger av den inbyggda auto-deployen, och du trycker Disconnect på Git-repot i Vercels dashboard.

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

Behåll din GitHub-bidragsgraf

Hela poängen med org-flytten var att committar skulle räknas i min graf — så committen på GitHub måste förbli författad av mig. Det är redan så här: CLI-deployen körs på en färsk checkout inne i runnern, och inget därifrån pushas någonsin tillbaka till GitHub.

Så jag committar som mig själv, pushar, och de gröna rutorna fylls i. Tokenet som auktoriserar deployen tillhör kontoägaren, inte mig — vilket är just poängen med en CI-deploy.

Låt dashboarden visa vem som pushade

En vanlig CLI-deploy dyker upp i Vercels lista som en naken hash — inget meddelande, ingen gren, ingen författare. För att få en riktig git-liknande rad (meddelande + gren + avatar) måste Vercel känna igen deployen som en git-commit — och just den igenkänningen är det som kör om författarkontrollen.

Tricket: inne i runnern, skriv om författaren till HEAD till en teammedlem, och deploya sedan. Amenden pushas aldrig tillbaka, så på GitHub förblir committen din. Vercel läser teammedlem-författaren från .git — deployen känns igen och blockeras inte — och du lägger den som faktiskt pushade i commit-meddelandet så att raden fortfarande säger vem som släppte 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"

Ett servicekonto som alla deployar genom

Generalisera: ett servicekonto äger Vercel-teamet och håller deploy-tokenet. Alla committar som sig själva; CI:t skriver om författaren till servicekontot och deployar med dess token. Dashboard-raden lyder [du] ditt commit-meddelande, och GitHub behåller ditt riktiga författarskap.

Det här är den tråkiga, ärliga versionen av det många team sträcker sig efter. Du betalar för platserna åt dem som behöver dashboard-åtkomst — inte en per bidragsgivare. Ett CI-token som deployar allas kod är modellen Vercel dokumenterar; du köper ingen plats åt någon bara för att deras kod går ut.

Detaljerna som biter

Ett par saker som kostade mig en kväll, så att de inte kostar dig en:

  • pnpm på Vercel. Byggavbilden kan låsa en gammal pnpm oavsett ditt packageManager-fält. Skicka --build-env ENABLE_EXPERIMENTAL_COREPACK=1 till vercel deploy så att corepack använder versionen du faktiskt låste.
  • Verifierade committar. Signering är fristående — sätt upp SSH-signering av committar och registrera nyckeln på GitHub, så får dina (riktiga) committar den gröna Verified-märkningen. Runnerns slit-och-släng-amend behöver ingen signatur.
  • Läsbara körningar. Dela upp det enda stora shell-steget i namngivna steg (re-author → deploy → summary) så att Actions-gränssnittet visar stadiet i ett ögonkast.
  • Tester. Deployen bygger på Vercel men kör aldrig dina tester — lägg till ett separat CI-workflow för det, och slå på Dependabot medan du ändå är där.

CLI-deployen auktoriseras av ett token, inte av den som skrev committen. Det är hela upplåsningen — och det är ett dokumenterat, förstklassigt sätt att släppa på.

Var gränsen går

Låt oss vara ärliga om gränsen, för det är lätt att prata sig förbi den. Att deploya bidragsgivares kod via ett CI-token är legitimt och tänkt så. Att sätta upp fejkkonton för att kringgå platsdebiteringen är det inte — det är multi-kontoande, och det bryter mot villkoren på varje plattform.

Det du görLegitimtÖver gränsen
Deploya bidragsgivares kod via ett CI-token✓ dokumenterat
Betala en plats åt den som sköter dashboarden
Committa som dig själv; serviceidentiteten bara i CI✓ ärlig statistik
Skapa fejk-/servicekonton för att slippa betala platser✗ multi-kontoande
Dela en inloggning så att många sköter utan platser✗ delade inloggningar

Slutsatser

  • Vercels inbyggda Git-integration blockerar deployer vars commit-författare inte är teammedlem — en säkerhetsspärr, inte en bugg.
  • vercel deploy med ett token kollar aldrig författaren; koppla bort den inbyggda integrationen och deploya från CI.
  • Committa som dig själv och pusha aldrig runnerns amend, så förblir din GitHub-graf intakt.
  • Att skriva om författaren till HEAD till en teammedlem i runnern ger en riktig dashboard-rad utan block — lägg den som pushade i meddelandet.
  • Du betalar för dashboard-platser, inte per bidragsgivare: ett CI-token som deployar allas kod är den tänkta modellen.
  • Att skapa fejkkonton för att kringgå debitering är multi-kontoande. Där går gränsen.

Inget av det här är exotiskt — CLI:t, ett token, en git amend som aldrig lämnar runnern. Skiftet är att inse att ”icke-medlem”-väggen inte ber dig köpa ännu en plats; den ber dig deploya så som CI är tänkt att göra. Koppla bort webhooken, ge tokenet till runnern — och låt den som skrev koden få äran för den.

Hittade du ett fel?

Ett felaktigt faktum, en skev översättning, något som känns falskt i den här artikeln? Skriv till mig — på ditt eget språk.