Gobernanza en pull requests: hooks locales baratos y CI como red de seguridad
Una guía repasa cómo repartir los controles de un pipeline de CI/CD entre la máquina del desarrollador y GitHub Actions, y por qué los hooks locales nunca bastan por sí solos.
Un artículo técnico repasa cómo repartir la gobernanza de un pipeline de CI/CD a lo largo de todo el ciclo, en lugar de dejarla para un control final antes de producción. La idea de fondo: cada validación corre en la capa más barata capaz de detectar su fallo.
Qué se puede cerrar en local
El primer filtro vive en la máquina del desarrollador. Al ejecutar git commit -S pasan dos cosas a la vez: el commit se firma con una clave SSH ed25519 —la misma infraestructura que usa git push— y commitlint valida que el mensaje siga Conventional Commits (feat(scope): descripción). Ese control se cuelga del hook commit-msg con Husky. En el pre-commit se pueden añadir lint-staged con Prettier y ESLint sobre los archivos del área de staging, análisis estático SAST con reglas OWASP y Gitleaks para que ningún secreto acabe en el historial de Git.
El argumento para hacerlo ahí es económico: un hook local resuelve en milisegundos y no consume runners. Un fallo trivial de formato detectado solo en CI cuesta varios minutos de feedback y bloquea al resto del equipo. Es la aplicación clásica de Shift Left, mover la validación lo más cerca posible del momento en que se introduce el defecto.
Con el matiz de siempre: --no-verify salta los hooks sin despeinarse. De ahí que el CI revalide todo. Los hooks son el filtro rápido, el CI es la garantía.
El gate del pull request
Cuando llega el push y se abre el PR, GitHub Actions dispara el workflow. Ahí la gobernanza aparece como un conjunto de checks coordinados.
El job de commitlint vuelve a comprobar todos los commits del PR. El motivo no es ritualista: los mensajes alimentan el changelog y las herramientas de release como Changesets y semantic-release, que derivan major, minor o patch del tipo de commit. Sin esa convención, el bump de versión es manual y propenso a error. También ayudan al git bisect y al blame, donde un "update stuff" no filtra nada. El autor señala que es el check más barato de cumplir y el que más se viola.
El otro job verifica las firmas. GitHub expone el resultado de verificación de cada commit en su API REST, bajo commit.verification.verified. La firma se hace en local con una clave ed25519 dedicada por ser el algoritmo recomendado en curva elíptica de 256 bits, sin los problemas de tamaño de las claves RSA.
Para quien mantiene pipelines, lo aprovechable es el reparto: colocar cada control donde sale más barato y asumir que la capa local es evitable por diseño. El texto original se corta justo al describir el job de verificación de firmas en CI, así que queda por ver cómo resuelve ahí la comparación contra las claves publicadas.
