Dependabot

Dependabot es el sistema de GitHub que mantiene tus dependencias al día abriendo pull requests automáticamente. Tiene dos modos que conviene no confundir: version updates (proactivo: te sube versiones aunque no haya ningún problema) y security updates (reactivo: responde a vulnerabilidades conocidas). El primero se configura con un archivo; el segundo viene activo por defecto en repos públicos.

El archivo dependabot.yml

Para los version updates creás dependabot.yml (o .yaml) dentro de .github/, en la rama por defecto del repositorio. La clave version: 2 es obligatoria y define el formato del archivo.

Dentro va la sección updates:, una lista donde cada entrada describe un ecosistema en una ruta. Los tres campos obligatorios de cada entrada son:

Campo	Obligatorio	Qué define
package-ecosystem	Sí	El gestor de paquetes: npm, docker, bundler, pip, cargo, composer, maven, gradle, github-actions, entre otros
directory	Sí	Ruta del manifest (ej. / para la raíz). Usá directories para varias rutas
schedule.interval	Sí	daily, weekly o monthly

Campos opcionales útiles:

Campo	Para qué
open-pull-requests-limit	Máximo de PRs abiertos simultáneamente por ecosistema
groups	Agrupar varias actualizaciones en un solo PR (menos ruido)
ignore	Excluir dependencias o rangos de versión
versioning-strategy	Cómo actualizar los rangos del manifest
labels / reviewers	Etiquetas y revisores automáticos en cada PR
target-branch	Abrir los PRs contra otra rama distinta a la default

Un detalle que suele pasarse por alto: el ecosistema github-actions mantiene actualizadas las versiones de las Actions que usás en tus propios workflows. Es la forma recomendada de no quedarte con un actions/checkout@v3 viejo para siempre.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
    groups:
      dependencias-dev:
        dependency-type: "development"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Este ejemplo revisa semanalmente las dependencias npm (agrupando las de desarrollo en un solo PR) y las versiones de las Actions usadas en los workflows.

Security updates

Los security updates son otra cosa. Se disparan a partir de las alertas de Dependabot: cuando GitHub detecta que una de tus dependencias tiene una vulnerabilidad conocida, abre automáticamente un PR que la sube a la versión parcheada.

Puntos clave a tener presentes:

• Se activan solo para dependencias declaradas en un manifest o lock file del repo, no para cualquier paquete arbitrario.
• En repositorios públicos están siempre habilitadas: el interruptor de configuración aparece deshabilitado, no se puede apagar desde la UI.
• No requieren dependabot.yml. Funcionan aunque no tengas ningún archivo de configuración.
• Abren un PR por cada alerta abierta. Existe la opción de grouped security updates para juntar varias en un solo PR.

Version updates vs security updates

flowchart LR
    subgraph VU["Version updates"]
        A["dependabot.yml<br/>(vos lo configurás)"] --> B["PRs periódicos<br/>según schedule"]
    end
    subgraph SU["Security updates"]
        C["Alerta de Dependabot<br/>(vulnerabilidad conocida)"] --> D["PR automático<br/>a versión parcheada"]
    end

	Version updates	Security updates
Objetivo	Mantenerse al día en general	Responder a vulnerabilidades
Naturaleza	Proactivo	Reactivo
Requiere dependabot.yml	Sí	No
Estado por defecto (repo público)	Apagado hasta configurarlo	Siempre activo (no se puede apagar)
Disparador	schedule (daily/weekly/monthly)	Una alerta de Dependabot abierta

Nota: los dos modos conviven. Lo habitual es tener dependabot.yml con version updates para tu stack y dejar que las security updates hagan su trabajo en paralelo. Un PR de seguridad puede aparecer en cualquier momento, sin esperar al schedule.

Recomendación práctica

Definí dependabot.yml cubriendo todos los ecosistemas de tu proyecto, incluyendo github-actions. Usá groups para no ahogarte en PRs y open-pull-requests-limit para acotar el ruido. Las security updates ya trabajan solas: tu parte es revisarlas y mergearlas rápido, porque cada una tapa un agujero real.

---

Anterior → Capítulo 11: PR templates y Discussions · Siguiente → Capítulo 13: Automatización de repo