Dependabot por repositorio con runners propios

El problema no era Dependabot, era la red

En un proyecto Laravel con paquetes privados, Dependabot puede necesitar llegar a un registry Composer que no está expuesto a Internet. Lo mismo ocurre con un registry npm interno, un servidor de Git o cualquier servicio que solo responde dentro de la red del homelab o de la empresa. Un runner alojado por GitHub no tiene por qué poder resolver ese DNS privado ni abrir conexión con esa infraestructura.

Hasta ahora, la elección del runner para Dependabot se planteaba a nivel de organización. Eso funciona si todos los repositorios comparten las mismas necesidades de red, pero deja de ser cómodo cuando solo algunos proyectos necesitan entrar en una VLAN, usar un proxy concreto o consultar un registry privado. Acabas aplicando una decisión global a repositorios que no necesariamente la necesitan.

GitHub ha añadido la selección de runner para Dependabot a nivel de repositorio. En los repositorios privados puedes elegir un runner etiquetado, indicar opcionalmente un grupo de runners y dejar que las actualizaciones de versión y de seguridad de Dependabot se ejecuten ahí. Si no se define una etiqueta personalizada, Dependabot busca la etiqueta dependabot. (github.blog)

Un caso bastante normal en Laravel

Imagina un Laravel que depende de paquetes Composer privados publicados en un registry accesible solo desde tu homelab. El runner autoalojado puede estar en la misma red que ese registry, resolver sus nombres internos y autenticarse con las credenciales que hayas configurado para Dependabot. Así no hace falta publicar el registry hacia fuera solo para que GitHub pueda revisar actualizaciones.

La configuración del runner no se guarda en .github/dependabot.yml. Se selecciona desde el repositorio, en Settings, después en Advanced Security, dentro de Dependency scanning, en la sección de Dependabot version updates y en el selector Runner type. Ahí hay que elegir Labeled runner, indicar el grupo si procede, añadir una etiqueta propia si la usas y guardar la selección. (docs.github.com)

Para el registry, en cambio, sí sigue siendo útil dependabot.yml. Este ejemplo configura un repositorio Composer privado y hace que el bloque de actualizaciones lo pueda utilizar:

version: 2
 
registries:
  composer-interno:
    type: composer-repository
    url: https://packages.intra.example
    username: dependabot
    password: ${{secrets.COMPOSER_REPOSITORY_PASSWORD}}
 
updates:
  - package-ecosystem: "composer"
    directory: "/"
    registries: "*"
    schedule:
      interval: "weekly"

La contraseña no debe vivir en el repositorio. GitHub permite guardar credenciales como secretos de Dependabot, tanto a nivel de repositorio como de organización, y referenciarlas desde el fichero de configuración. Para un registry Composer, el tipo documentado es composer-repository y admite username y password. (docs.github.com)

Separar redes sin convertirlo en una excepción global

Lo interesante de esta opción no es simplemente usar un runner autoalojado. Es poder reservarlo para los repositorios que realmente lo necesitan. Un proyecto público o uno que solo consume Packagist puede mantener el entorno estándar de GitHub, mientras que el Laravel que depende de infraestructura interna usa una etiqueta como dependabot-homelab.

También ayuda a delimitar responsabilidades. Puedes crear un grupo de runners dedicado a repositorios con acceso a servicios internos, en lugar de dar esa conectividad a todos los runners de la organización. La etiqueta sirve para dirigir el trabajo y el grupo limita qué repositorios pueden utilizar esos runners, siempre que el repositorio tenga acceso al grupo elegido. (docs.github.com)

En mi caso, lo trataría como una pieza más de la segmentación de red. El runner de Dependabot necesita alcanzar el registry y poco más; no necesita acceso general a todo el homelab. Si ese runner tiene más privilegios de los necesarios, una actualización de dependencias deja de ser una tarea rutinaria y pasa a ser una puerta de entrada con demasiado alcance.

La letra pequeña

Esto no convierte a Dependabot en un workflow configurable a medida. Elegir un runner define dónde se ejecuta el trabajo de actualización, pero no sustituye la configuración de registries, secretos ni las reglas de actualización de dependabot.yml. Si falta autenticación, el certificado interno no es válido o el runner no puede resolver el nombre del registry, mover el trabajo al homelab no arreglará el fallo por sí solo.

Antes de seleccionar un runner etiquetado, ese runner debe existir y tener exactamente la etiqueta prevista. Si indicas un grupo de runners, el grupo debe existir y el repositorio debe tener acceso a él. Además, cambiar la selección del runner no provoca una ejecución inmediata de Dependabot; habrá que esperar al siguiente trabajo programado o al siguiente evento que lo active. (docs.github.com)

Tampoco es una opción para cualquier repositorio. GitHub indica que estos controles se muestran para repositorios privados e internos en github.com, no para repositorios públicos ni para GitHub Enterprise Server. Las configuraciones de seguridad tampoco aplican actualmente esta selección de runner de Dependabot, así que conviene revisar cada repositorio que dependa de ella. (github.blog)

Por último, un runner autoalojado exige mantenimiento. Hay que actualizarlo, vigilar su conectividad, restringir quién puede usarlo y no reutilizarlo alegremente para tareas con niveles de confianza distintos. Tener acceso a la red privada resuelve el problema del registry, pero también obliga a ser más estricto con el aislamiento.

Fuente: GitHub Changelog Documentación oficial: Configuring Dependabot on self-hosted runners