The Pulse
Dagger porta in beta la sua piattaforma CI 1.0
Dagger ha annunciato la beta della versione 1.0 il 23 ottobre 2026, dopo cinque anni di sviluppo nella serie 0.x. La release introduce moduli ufficiali, report per singolo test, esecuzione remota e controlli GitHub diretti. Dagger chiede ag
AI.info Team · Scritto con l’IA · verificato ·
«Gli agenti di programmazione possono rilasciare codice solo alla velocità consentita dalla loro CI, e la CI sta rimanendo indietro».
Solomon Hykes
Dagger ha annunciato la beta della versione 1.0 il 23 ottobre, presentandola come una nuova generazione di integrazione continua pensata per i team di sviluppo che usano agenti di programmazione. Secondo l’azienda, la piattaforma può eseguire le stesse pipeline di build e test in locale, prima di un push del codice, o dopo: un agente può così ricevere feedback senza dipendere da un ambiente CI separato e configurato in modo diverso.
Il lancio arriva dopo cinque anni di sviluppo nella serie 0.x. Dagger chiede agli utenti di provare la beta sui propri repository prima di dichiarare stabile la release. L’azienda afferma di non poter effettuare test sulle codebase private dei clienti e invita chi prova la beta a segnalare i problemi tramite la sua comunità Discord.
Dagger sposta la CI dai job ai singoli test
La principale novità tecnica della release riguarda il modo in cui rappresenta le attività. Dagger descrive le pipeline come funzioni eseguite in sandbox che producono artefatti tipizzati, tra cui codice sorgente, container, file binari e test. Il motore calcola questi artefatti quando necessario, in un grafo incrementale delle dipendenze, in locale o su un motore remoto condiviso. Secondo Dagger, sandbox, scheduler, runtime dei container, cache e tracciamento usano tutti lo stesso modello di esecuzione e dei dati.
Questa struttura supporta diverse funzionalità pensate per ridurre il tempo tra una modifica al codice e un feedback utile. I moduli ufficiali collegano Dagger a strumenti come Go, pytest, ESLint e Playwright e possono individuare ed eseguire test selezionati. Anziché riportare soltanto lo stato di un job CI più ampio, secondo Dagger la beta riporta separatamente ogni test, consentendo a uno sviluppatore o a un agente di rieseguire da solo un test non superato.
Gli spazi di lavoro offrono un luogo in cui configurare Dagger, di solito all’interno di un repository Git. Un file dagger.toml specifica i moduli e altre impostazioni, mentre i moduli possono esaminare i file del progetto e la configurazione nativa. Dagger aggiunge anche test di integrazione che si orchestrano autonomamente: un test può usare i moduli per avviare dipendenze come un database o un server API, invece di affidarsi a una configurazione separata che potrebbe differire tra il computer di uno sviluppatore e la CI.
Le dichiarazioni sulla velocità si basano su confronti specifici
Nel suo annuncio, Dagger riporta due confronti sulle prestazioni. Afferma che il tempo per eseguire 1.000 container in parallelo è sceso da 35–61 secondi a 16–17 secondi. Il tempo per raccogliere 300 file è sceso da 11,8 secondi a 1,1 secondi. L’articolo non presenta queste cifre come un benchmark indipendente: sono risultati ottenuti da Dagger, proposti come prova del lavoro svolto sulle prestazioni in vista della versione 1.0.
L’azienda aggiunge anche shell interattive per lo sviluppo. dagger shell apre una shell in un container fornito da uno spazio di lavoro, mentre dagger check -i ne apre una nello stato in cui un comando non è riuscito. L’obiettivo è consentire a sviluppatori, CI e agenti di programmazione di esaminare lo stesso ambiente, anziché ricostruirlo a partire dal lungo log di un job.
Controlli GitHub e un nuovo modello di fatturazione
Dagger Cloud può ora ricevere eventi GitHub, eseguire controlli sui push e restituirne lo stato senza un file di workflow di GitHub Actions né un altro servizio di terze parti. Gli utenti possono attivare l’integrazione con dagger cloud checks on. Per l’esecuzione remota, Dagger afferma di poter eseguire le pipeline sull’infrastruttura di un’azienda o in Dagger Cloud, trasmettendo file, segreti, tunnel di rete e accesso al terminale secondo necessità.
Secondo l’azienda, il nuovo modello tariffario di Dagger Cloud addebita il consumo di risorse di ciascuna pipeline. La capacità inutilizzata è gratuita e le operazioni che potrebbero essere soddisfatte dalla cache costano cinque volte meno, indipendentemente dal fatto che la cache le soddisfi effettivamente. L’annuncio non fornisce esempi di fatture né un prezzo per unità di consumo: i team che valutano il cambiamento dovranno quindi confrontare le modalità di utilizzo delle proprie pipeline con i dettagli tariffari del servizio.
La beta richiede ancora lavoro per la migrazione
Dagger afferma che la versione 1.0 mantiene il motore di base e l’API, ma modifica molti comandi della CLI. La precedente configurazione dagger.json viene sostituita da dagger.toml per lo spazio di lavoro e da dagger-module.toml per il manifest del modulo. Secondo l’azienda, la compatibilità con le versioni precedenti o la migrazione automatizzata gestiscono la maggior parte dei casi, anche se parte del codice degli SDK potrebbe richiedere piccoli adattamenti e restano alcune eccezioni.
La beta chiede quindi agli utenti di verificare più dei miglioramenti delle prestazioni messi in evidenza: dovranno controllare il comportamento dei moduli, i risultati della migrazione, i report dei test e l’esecuzione remota nei propri progetti. Il traguardo dichiarato da Dagger è un’architettura stabile per la versione 1.0. La release è ancora una beta e, come indica lo stesso annuncio, resta da provarla su repository reali prima che sia stabile.