De script manual a pipeline CI/CD con GitHub Actions

Esto continúa la guía de deploy a Vercel por CLI. Ese script resuelve el problema para una persona; en cuanto el repo tiene más de un colaborador, se queda corto.

01 · El problema

El plan Hobby de Vercel solo hace deploy automático de commits cuyo autor de Git coincida con la cuenta dueña del proyecto. En un repo privado con más de un colaborador, cualquier commit de otra persona queda bloqueado.

02 · Por qué el script manual no escala

La primera solución fue un script que reescribe el autor del último commit en una rama local temporal (nunca se pushea) y deploya desde ahí:

#!/usr/bin/env bash
set -e

git checkout main
git fetch origin && git pull origin main
git branch -D deploy-temp 2>/dev/null || true
git checkout -b deploy-temp origin/main
git commit --amend --author="Nombre <email>" --no-edit
vercel --prod
git checkout main

03 · Moverlo a una GitHub Action

La idea: mover la reescritura de autor y el deploy a un proceso que corre en CI, no en la compu de una persona. Así cualquiera con permiso de push puede disparar un deploy sin necesitar cuenta de Vercel propia.

name: Deploy to production

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@v4
        with:
          fetch-depth: 0

      - run: |
          git config user.email "tu@email.com"
          git config user.name "Tu Nombre"
          git commit --amend --reset-author --no-edit

      - run: npm install --global pnpm@latest
      - run: npm install --global vercel@latest
      - run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

04 · Problemas encontrados en la implementación

spawn pnpm ENOENT

El runner de GitHub no trae pnpm preinstalado. Se resuelve agregando npm install --global pnpm@latest antes de usar el CLI de Vercel.

ERR_PNPM_IGNORED_BUILDS

pnpm 10+ bloquea scripts de instalación de dependencias con binarios nativos salvo aprobación explícita. La sintaxis de aprobación (onlyBuiltDependencies) cambia de ubicación entre versiones (package.json → pnpm-workspace.yaml). Más robusto bajar el bloqueo a warning:

onlyBuiltDependencies: [core-js, sharp]
strictDepBuilds: false

Variables de entorno del sistema no disponibles

Un build corrido fuera de la infraestructura nativa de Vercel no recibe las variables que Vercel inyecta automáticamente en un deploy normal (ej. la URL del deploy). Cualquier librería que dependa de eso de forma implícita — next-auth necesitando su propia URL base, por ejemplo — falla si esa variable no está seteada explícitamente en el dashboard.

Variables marcadas «Sensitive»

Vercel permite marcar una variable como no legible después de guardada — ni por dashboard, ni por CLI, ni por ningún proceso. Si un proceso externo necesita leer el valor real (vercel pull), la variable tiene que ser normal, no sensible. El síntoma es silencioso: la variable «existe» y el proceso no tira error de configuración, pero devuelve un valor de relleno en vez del real.

Conclusión

Una automatización atada a una identidad personal es un cuello de botella estructural, no una limitación de la herramienta específica. Moverla a un proceso con credenciales propias, corrido en un entorno compartido, es lo que elimina la dependencia de una persona — el resto (versiones de tooling, variables de entorno) son detalles de implementación puntuales.