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

Development

Una compuerta que nunca corre no es una compuerta

Una prueba de contrato IPC, una prueba de humo de release, una auditoría de dependencias que encontró 18 advisories que nadie pidió, y un chequeo de contraste que llevaba roto en silencio todo el tiempo que no corría.

Leer
Development

Dos notas que nadie vio jamás

Greenhouse guardaba fielmente una nota de captura y una nota de traspaso, y no mostraba ninguna de las dos: una no tenía campo en el tipo de wire, la otra tenía un comando funcional que nadie llamaba.

Leer