Crea e valida le pipeline di GitLab CI senza uscire dal tuo editor.
Crea e valida le pipeline di GitLab CI senza uscire dal tuo editor.
Una skill di IA gratuita che crea e valida il tuo .gitlab-ci.yml nel tuo editor locale. Funziona con Cursor, VS Code, Claude Code e qualsiasi agente che usi già.
Novità! Stiamo rilasciando miglioramenti di continuo, condividi il tuo feedback con noi.
Da commit-per-validare, a validare-per-fare-commit
Le pipeline sono l''unica parte del moderno stack di sviluppo che ancora non si può validare in locale. La skill crea il YAML nel tuo editor. glci (un progetto GitLab sperimentale) lo esegue sul runner reale prima del push. Smetti di usare la pipeline remota come debugger e la cronologia git come log dei refusi.
Commit. Push. Aspettare. Fallire. Ripetere.
- Scrivere il YAML a mano, a memoria o dalla documentazione
- Fare commit e push su un branch per vedere se funziona
- Aspettare 8–12 minuti un runner remoto
- Fallire per un refuso, una variabile mancante o un job con nome sbagliato
- Modificare, fare push, ripetere 3–4 volte
- Lasciare una scia di commit "fix CI" nella cronologia
Crea. Valida. Fai push quando è verde.
- Chiedere all'agente di creare una pipeline dal tuo repo
- Esegui
glci showper ispezionare il grafo dei job - Esegui
glci runper eseguire ogni job in Docker reale - Risolvere ciò che fallisce — in secondi, non in minuti
- Fare push una volta sola, con una pipeline che hai già visto passare
- Mantieni la tua cronologia git incentrata sul codice, non sul YAML
Il cambio non è una pipeline più veloce. È un rapporto diverso con la pipeline. Lo stesso che hai già con il codice della tua applicazione.
Due passaggi. Circa cinque minuti
Per validare in locale non serve un account GitLab. Non viene fatto alcun push finché non lo decidi tu.
Aggiungi la skill al tuo editor
Inserisci la skill in Claude Code, Cursor, VS Code, OpenCode o Codex. L'agente conosce ora GitLab CI/CD: sintassi, buone pratiche, il vostro stack.
Chiedi, esegui, fai push
"Write a CI pipeline for this project." Esamina il YAML generato dall'agente. Esegui glci run. Fai push quando è verde.
Cosa serve
- Un editor o un agente compatibileClaude Code, Cursor, VS Code, OpenCode, Codex o qualsiasi strumento che carichi skill in markdown.
- Un progettoQualsiasi codice, ospitato ovunque. L'agente legge dalla cartella di lavoro locale e crea automaticamente una pipeline suggerita.
- Docker in esecuzione in localeCosì glci può validare ed eseguire i job in container reali.
- Un progetto GitLab(quando si è pronti a eseguire la CI a ogni push)La skill e glci validano in locale anche senza; serve quando si vuole che le pipeline vengano eseguite nel cloud.
Funziona con gli agenti di IA che usate già
Una CLI per eseguire le pipeline in locale e una skill per crearle nel tuo editor. Installale nell'ordine che preferisci.
Scegli il tuo agente
Scarica la skill e scopri dove posizionare i file riconosciuti da Cursor.
Ricarica Cursor. L'agente usa la skill in modo automatico quando richiesto: "Write a CI pipeline for this project."
Più di un runner. Più di questa skill
Nessuno desidera accedere alla UI per scrivere una pipeline. Questa skill ti tiene nel tuo editor il più a lungo possibile. Ma a volte è necessario tornare indietro: una pipeline rotta, una revisione di MR, un deploy andato storto. Quando succede, la piattaforma è già collegata. Codice, pipeline, registry, segreti e deploy vivono in un unico posto. Qualsiasi editor o agente che si utilizzi si integra. Gli stessi controlli di sicurezza vengono eseguiti sul codice scritto dall''IA come sul vostro.
Un modello dati unico. Aperto ai bordi.
Codice, pipeline, pacchetti, segnalazioni di sicurezza, deploy, rilasci — tutto nello stesso sistema, connesso anziché sincronizzato. Qualsiasi editor, agente o modello che portate si integra via MCP e lavora dalla stessa vista autorevole. Aperto ai bordi, governato al centro.
Il contesto separa l'IA veloce dall'IA affidabile.
Gli agenti senza contesto scrivono codice che sembra corretto e si rompe in produzione, perché non vedono cosa dipende da una modifica o cosa esiste già. Il knowledge graph di GitLab mantiene una mappa viva del modo in cui codice, pipeline, deploy e segnalazioni di sicurezza si collegano, così le domande sul raggio d'impatto o sulle conseguenze a valle ricevono risposta in secondi, non in giorni. Qualsiasi agente può consultarlo.
Una governance strutturale, non aggiunta dopo.
Il codice scritto dall'IA passa per le stesse scansioni di sicurezza, le stesse approvazioni e la stessa traccia di audit del codice scritto da voi. Gli agenti hanno identità con ambito definito, politiche comportamentali e catena di custodia completa. Portate il vostro modello, il vostro cloud, il vostro agente: tutto è governato dallo stesso tessuto.
Dal tradizionale all'autonomo, sulla stessa piattaforma.
Alcuni team continueranno a scrivere codice a mano. Altri guideranno gli agenti su compiti specifici. Pochi eseguiranno gli agenti in modo autonomo su lavori a basso rischio. Tutti e tre i modelli convivono sullo stesso modello dati e sulla stessa governance: i team avanzano al proprio ritmo, senza dover ripiattaformare al variare della loro maturità in IA.
Stiamo costruendo attivamente questa skill, e il team che ci lavora vuole che si adatti a come lavori davvero. Dicci cosa funziona e cosa ti blocca. Condividi il tuo feedback con noi.
Altri due punti in cui l'IA di GitLab incontra la vostra CI
GitLab CI Skill è pensata per creare e validare nuove pipeline nel tuo editor. Quando il lavoro di CI/CD cambia forma, GitLab dispone di prodotti complementari per gli altri momenti.
Arrivate da GitHub Actions?
La skill di migrazione da GitHub Actions legge il vostro .github/workflows/ e lo converte in GitLab CI/CD idiomatico, segnalando ciò che richiede una decisione manuale. Stessi editor, stesso flusso di lavoro.
La pipeline si sta complicando?
CI Expert Agent vive all'interno di GitLab Duo Agent Platform con il contesto completo del progetto: legge i log dei job in tempo reale, ottimizza i tempi di build, esegue il debug dei job instabili e opera su pipeline multi-progetto. Per quando le pipeline smettono di essere qualcosa che scrivete e diventano qualcosa che gestite.