Saltar al contenido
Development

Agregar Dependabot a Greenhouse (y la trampa del workspace de Rust que salió a la luz)

Por Victor Da Luz
rustdependabotcidev-loggreenhouse

Una revisión de repositorio en Greenhouse (mi app de escritorio en Tauri para gestionar proyectos creativos) señaló algo que había estado postergando: no había ningún escaneo de dependencias. Nada de cargo-audit, nada de npm-audit, nada vigilando crates o paquetes con vulnerabilidades conocidas. En un proyecto nuevo eso es fácil de ignorar, hasta que deja de serlo.

Por qué este enfoque

Dependabot de GitHub cubre esto sin agregar un job de CI. Su base de datos de avisos ya incluye RustSec, así que un archivo de configuración hace lo que de otra forma necesitaría un workflow separado de cargo-audit. También actualiza las versiones fijadas de GitHub Actions en el archivo de CI, algo que nunca recuerdo actualizar a mano.

Agrupé las actualizaciones menores y de parche por ecosistema para recibir más o menos un PR por semana en vez de una docena. Las mayores siguen llegando de forma individual, porque son las que de verdad vale la pena leer antes de fusionar.

Implementación

La configuración en sí es corta:

version: 2
updates:
  - package-ecosystem: cargo
    directory: /
    schedule: { interval: weekly }
    groups: { cargo-minor: { update-types: [minor, patch] } }
  - package-ecosystem: npm
    directory: /
    schedule: { interval: weekly }
    groups: { npm-minor: { update-types: [minor, patch] } }
  - package-ecosystem: github-actions
    directory: /
    schedule: { interval: weekly }

La trampa

El plan original apuntaba la entrada de cargo a /src-tauri, porque ahí vive el Cargo.toml del crate de Tauri. Eso está mal para este repositorio. El Cargo.toml raíz de Greenhouse es un workspace virtual ([workspace] members = ["src-tauri"], sin [package] propio), y en ese esquema el Cargo.lock vive en la raíz del workspace, no dentro del directorio del crate miembro. El actualizador de cargo de Dependabot necesita el directorio que realmente contiene el lockfile contra el que resuelve, así que tiene que ser /. Igual sigue rastreando bien las dependencias de src-tauri, porque Dependabot recorre todos los miembros del workspace desde la raíz.

Fácil de pasar por alto cuando se busca el patrón según dónde vive el código “real” en vez de dónde está el lockfile.

Resultados

Un archivo nuevo, .github/dependabot.yml, sin otros cambios de código ni de CI. Confirmé que parsea con yq y verifiqué que los tres directorios mapean a manifiestos reales antes de fusionar. La validación completa ocurre una vez que GitHub lo corre después del push, ya que no hay forma local de hacer un dry-run de Dependabot.

También escribí la trampa del workspace root como nota de patrón en mi base de conocimiento, porque volverá a morderme la próxima vez que agregue Dependabot a un proyecto con workspace de Rust.

Lecturas relacionadas

También te podría ser útil

Proton

Proton Drive

Almacenamiento en la nube cifrado, del equipo detrás de Proton Mail.

Como socio de Proton, obtengo ingresos por las compras que califican de los servicios de privacidad y seguridad de Proton (Pass, Mail, VPN, Drive).

Más información
NordPass

NordPass

Gestor de contraseñas del equipo detrás de NordVPN, con un plan gratuito.

Como afiliado de NordPass, obtengo ingresos por las compras que califican.

Más información
Proton

Proton VPN

VPN comercial con filtrado NetShield e interruptor de apagado automático.

Como socio de Proton, obtengo ingresos por las compras que califican de los servicios de privacidad y seguridad de Proton (Pass, Mail, VPN, Drive).

Más información