Dagger anunció su versión 1.0 beta el 23 de octubre de 2026, después de cinco años de versiones 0.x. Su propuesta es que una persona y un agente de programación puedan ejecutar las mismas comprobaciones antes de enviar código y en la integración continua (CI), el proceso que compila y prueba los cambios. Sigue siendo una beta, no una versión estable.
La novedad puede interesar a equipos que pierden tiempo enviando cambios para descubrir después un fallo de pruebas. Pero instalar la nueva CLI, la herramienta de terminal, exige revisar comandos y configuración: mantener compatibilidad con dagger.json no asegura que todos los scripts antiguos funcionen igual.
Comprobaciones más cerca del proyecto
El anuncio de Dagger presenta módulos oficiales para herramientas como Go, pytest, ESLint y Playwright. Leen la configuración que ya usa el proyecto y exponen sus elementos —incluidas pruebas individuales— para seleccionarlos y ejecutarlos.
Los nuevos workspaces reúnen los módulos y sus ajustes en dagger.toml. El motor calcula los resultados cuando hacen falta, reutiliza trabajo mediante caché y puede ejecutar en un motor local o remoto. El anuncio también describe acceso a una terminal en el entorno donde falló una comprobación.
Un ejemplo hipotético: un agente modifica una función de una aplicación Python y falla una prueba de pytest. En lugar de reconstruir el problema únicamente desde un registro remoto, el equipo puede seleccionar esa prueba e inspeccionar su entorno antes del siguiente envío. Puntoes no ha ejecutado este ejemplo ni medido ahorro de tiempo o tokens; las mejoras de rendimiento del anuncio son afirmaciones del fabricante.
La guía de inicio permite listar las comprobaciones con dagger check -l. Conviene examinar qué encontró cada módulo: una comprobación sin elementos puede indicar que no localizó su archivo de configuración. Que una ejecución termine correctamente no demuestra que incluya todas las pruebas relevantes del repositorio.
Migrar archivos también cambia el flujo de trabajo
La guía de migración a 1.0 separa dos funciones que antes compartía dagger.json:
dagger.tomlconfigura el workspace.dagger-module.tomldescribe un módulo.
Dagger puede seguir leyendo el formato anterior, pero varios comandos cambian. dagger sin argumentos muestra ayuda; dagger shell abre una terminal para un contenedor o directorio; dagger init crea un workspace. dagger develop desaparece y la generación de código pasa por dagger generate.
La documentación recomienda empezar con Git limpio y previsualizar la conversión mediante dagger workspace migrate --no-apply. Después de revisar y aplicar los cambios, hay que generar el código y guardar también los archivos generados y dagger.lock. Son indicaciones documentales, no una migración ejecutada por Puntoes.
Hay excepciones que merecen leer la guía completa: un módulo cuyo código está en la raíz puede necesitar carga explícita con -m .; un blueprint en un subdirectorio no se migra automáticamente. También existen cambios de API para determinados módulos. La compatibilidad debe verificarse en los scripts locales y en CI.
Código abierto y servicio Cloud tienen condiciones distintas
El código de Dagger usa Apache 2.0. Dagger Cloud es un servicio con facturación propia. Puede recibir eventos de GitHub y devolver estados de comprobación sin un workflow de Actions para esas comprobaciones; eso no migra por sí solo las demás automatizaciones del repositorio.
La tarifa de Cloud consultada incluye CPU, memoria y tráfico de entrada y salida. Se paga el mayor importe entre consumo y plan: Starter parte de 20 dólares mensuales para un usuario; Scale, de 200 con usuarios ilimitados. Que la capacidad ociosa no se facture no elimina el mínimo del plan.
La página de instalación consultada el 25 de octubre apunta a 1.0.0-beta.21. Es la versión documental al preparar esta noticia, no una afirmación sobre la compilación exacta del anuncio. Antes de adoptar la beta, fija la versión que vas a evaluar, revisa el cambio completo y comprueba tus pruebas representativas.