È stata rilasciata la versione 13.4 con lo storage HashiCorp per le variabili CI, l'Agente Kubernetes e il centro sicurezza, oltre a funzionalità attivabili nel piano Starter
In GitLab pensiamo sempre a come aiutare gli utenti a ridurre i rischi, aumentare l'efficienza e la velocità di consegna sulla vostra piattaforma preferita. Questo mese abbiamo introdotto molte novità utili che ampliano le funzionalità di sicurezza, riducono le vulnerabilità, aumentano l'efficienza, semplificano l'uso di GitLab e aiutano il vostro team a fornire funzionalità ancora più rapidamente. Speriamo che vi siano utili le funzionalità principali di questo rilascio, insieme a 53 altre nuove funzionalità, aggiunte in questo rilascio.
Maggiori capacità di sicurezza
Ci sforziamo di aggiungere ogni mese alcune nuove funzionalità a GitLab DevSecOps, e questo rilascio non fa eccezione. nell'ambito della costruzione e del deployment. Inoltre, le organizzazioni che desiderano mantenere la separazione dei compiti nel deployment del codice possono ora . Questo ruolo è in linea con e consentirà di convalidare le merge request (nella localizzazione italiana di GitLab "richieste di fusione") e distribuire il codice in ambienti protetti, senza fornire accesso per modificare il codice stesso.
Un altro modo per ridurre i rischi è l'uso del nuovo . Gli operatori possono distribuire cluster Kubernetes da GitLab senza dover aprire l'accesso al proprio cluster a tutto Internet. Presentiamo inoltre il supporto automatico per il controllo delle versioni dei nuovi file di stato Terraform con per supportare la conformità e facilitare il debugging. Infine, il pannello di controllo della sicurezza nell'istanza è diventato un con report sulle vulnerabilità e impostazioni di sicurezza.
Un'esperienza più conveniente ed efficace con GitLab
Abbiamo migliorato la nostra ricerca globale, aggiungendo , che consente di passare facilmente agli ultimi ticket, gruppi, progetti, impostazioni e sezioni di aiuto. Siamo lieti di annunciare che in GitLab Pages per la reindirizzamento di singole pagine e directory all'interno del sito, consentendo agli utenti di distribuire i propri siti in modo più efficace. E per coloro che desiderano ricevere informazioni più dettagliate sulla distribuzione, questa release consente !
Contributi open source
Presentiamo , aggiunta da . Le annotazioni sulla copertura dei test unitari del codice modificato forniscono agli sviluppatori una chiara comprensione della copertura del codice durante la revisione; queste informazioni aiutano ad accelerare la revisione e ridurre il tempo necessario per il merge e la distribuzione di nuovo codice. Inoltre, abbiamo e pianifichiamo .
E questo è solo l'inizio!
Come sempre, nella panoramica generale c'è troppo poco spazio e ci sono moltissime funzionalità interessanti nella release 13.4. Ecco ancora alcune:
- .
Se desideri anticipare cosa ti aspetta in prossimo rilascio, dai un'occhiata a .
.
di questo mese —
Fabio ha apportato un contributo significativo in — una funzionalità che la comunità di GitLab attendeva da tempo. Questo è davvero un contributo importante con modifiche sostanziali che hanno richiesto una continua collaborazione con i membri del team di GitLab e hanno coinvolto numerosi ambiti del progetto, come UX, frontend e backend.
Caratteristiche principali del rilascio di GitLab 13.4
Utilizza le chiavi di HashiCorp Vault nei job CI
(PREMIUM, ULTIMATE, SILVER, GOLD)
Con il rilascio 12.10, GitLab ha introdotto la possibilità di ricevere e trasmettere chiavi nei job CI utilizzando il gestore di job di GitLab (GitLab runner). Ora stiamo espandendo , aggiungendo una nuova sintassi secrets nel file .gitlab-ci.yml. Questo renderà più semplice la configurazione e l'utilizzo del vault di HashiCorp con GitLab.
e .
Presentiamo GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
L'integrazione di GitLab con Kubernetes consente da tempo il deployment su cluster Kubernetes senza la necessità di configurazioni manuali. Molti utenti apprezzano la facilità d'uso di questa combinazione, mentre altri hanno incontrato alcune difficoltà. Per l'attuale integrazione, il tuo cluster deve essere accessibile da Internet affinché GitLab possa connettersi. Per molte organizzazioni, ciò non è fattibile, poiché limitano l'accesso ai cluster per motivi di sicurezza, conformità o regolamentazioni. Per superare queste limitazioni, gli utenti devono creare i propri strumenti sopra GitLab, altrimenti non sarebbero in grado di sfruttare questa funzionalità.
Oggi presentiamo GitLab Kubernetes Agent, un nuovo modo di distribuire su cluster Kubernetes. L'agente opera all'interno del tuo cluster, quindi non sarà necessario aprirlo a tutta l'internet. L'agente coordina la distribuzione richiedendo nuove modifiche a GitLab, invece di ricevere aggiornamenti da GitLab per il cluster. Indipendentemente dal metodo GitOps che utilizzi, GitLab è la soluzione per te.
Tieni presente che questo è il primo rilascio dell'agente. Attualmente ci siamo concentrati sulla configurazione e gestione delle distribuzioni tramite codice per GitLab Kubernetes Agent. Alcune funzioni esistenti di integrazione con Kubernetes, come le schede di distribuzione e le applicazioni gestite da GitLab, non sono ancora supportate. , che queste funzionalità saranno aggiunte all'agente in futuri rilasci, insieme a nuove integrazioni focalizzate sulla sicurezza e sulla conformità.
e .
Consenti agli utenti di avere permessi per distribuire senza accesso al codice
(PREMIUM, ULTIMATE, SILVER, GOLD)
In precedenza, il sistema di autorizzazioni in GitLab non consentiva di suddividere in modo efficace le responsabilità all'interno del team tra chi si occupa dello sviluppo e chi si occupa del deployment. Con il rilascio di GitLab 13.4, puoi concedere il permesso di approvare le merge request per il deployment, così come di effettuare il deployment del codice a persone che non scrivono codice, senza fornire loro diritti di accesso da maintainer (nella localizzazione russa di GitLab "сопровождающий").
e .
Centro sicurezza
(ULTIMATE, GOLD)
In precedenza, la gestione delle vulnerabilità a livello di istanza era limitata sia in termini di funzionalità che di flessibilità. L'interfaccia consisteva in una singola pagina che riuniva dettagli sulle vulnerabilità, grafici delle metriche e impostazioni. Non c'era molto spazio per sviluppare queste funzionalità o per utilizzare altri strumenti di sicurezza.
Abbiamo apportato cambiamenti fondamentali nella gestione della sicurezza e della sua trasparenza in GitLab. La dashboard della sicurezza dell'istanza è diventata un vero e proprio centro di sicurezza. La modifica più significativa è l'introduzione di una nuova struttura di menu: invece di una sola pagina, ora hai accesso separato al pannello di controllo della sicurezza, al report delle vulnerabilità e alla sezione delle impostazioni. Anche se la funzionalità non è cambiata, questa suddivisione permette di migliorare questa sezione, cosa che altrimenti sarebbe stata difficile. Inoltre, crea una base per l'aggiunta di altre funzionalità relative alla sicurezza in futuro.
La sezione dedicata al report delle vulnerabilità ora ha più spazio per visualizzare dettagli importanti. Qui sono raccolte le vulnerabilità attualmente presenti nell'elenco delle vulnerabilità del progetto. Spostare i widget con le metriche delle vulnerabilità in una sezione separata crea un'interfaccia di gestione della sicurezza più conveniente. Ora è una base per future visualizzazioni — non solo per la gestione delle vulnerabilità, ma anche per qualsiasi metrica relativa alla sicurezza. Infine, un'area di impostazioni separata crea uno spazio comune per tutte le impostazioni di sicurezza a livello di istanza, non solo per la gestione delle vulnerabilità.
e .
Funzionalità attivabili ora in GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
In GitLab 11.4 è stata rilasciata . Nella 12.2 abbiamo introdotto strategie per e , e nella 13.1 abbiamo aggiunto e per diversi ambienti.
All'inizio di quest'anno, GitLab si è impegnato a in open source. In questa release abbiamo completato il trasferimento delle funzionalità attivabili nel piano Starter e continueremo il loro trasferimento in Core con Siamo lieti di offrire questa opportunità a un numero maggiore di utenti e vogliamo sapere come la utilizzerete.
e .
Navigazione rapida dalla barra di ricerca
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A volte, mentre navighi in GitLab, vuoi andare direttamente a un progetto specifico anziché alla pagina dei risultati di ricerca.
Con la barra di ricerca globale puoi accedere rapidamente agli ultimi ticket, gruppi, progetti, impostazioni e sezioni della documentazione. Puoi persino usare la scorciatoia da tastiera /, per spostare il cursore sulla barra di ricerca, rendendo la navigazione in GitLab ancora più efficiente!
e .
Visualizzazione della copertura del codice nelle differenze delle merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Durante la revisione di una merge request, potrebbe essere difficile determinare se il codice modificato è coperto dai test unitari. Invece, i revisori possono fare affidamento sulla copertura complessiva e richiederne un aumento prima di approvare la merge request. Questo può portare a un approccio casuale alla scrittura dei test, che in realtà non migliorerà la qualità del codice o la sua copertura da parte dei test.
Ora, durante la visualizzazione del diff della merge request, vedrai una rappresentazione visiva della copertura del codice. Nuove annotazioni permetteranno di capire rapidamente se il codice modificato è coperto dai test unitari, il che aiuterà ad accelerare la revisione del codice e il tempo di merge e distribuzione del nuovo codice.
Grazie e Siemens per questa funzionalità!
e .
Più ambienti e progetti nel pannello degli ambienti
(PREMIUM, ULTIMATE, SILVER, GOLD)
Con il rilascio di GitLab 12.5, tramite potevi monitorare lo stato degli ambienti, ma non più di sette ambienti in tre progetti. Abbiamo migliorato questo pannello nella versione 13.4, suddividendolo in pagine per aiutarti a gestire i tuoi ambienti su larga scala. Ora puoi vedere più ambienti in un numero maggiore di progetti.
e .
GitLab ha assunto la gestione del provider GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recentemente abbiamo e pianifichiamo . Negli ultimi mesi abbiamo approvato 21 merge request e chiuso 31 ticket, comprese alcune bug storiche e funzionalità mancanti, come . Puoi nella documentazione di Terraform.
e .
Test di fuzzing API con specifiche OpenAPI o file HAR
(ULTIMATE, GOLD)
Il test di fuzzing API è un ottimo modo per trovare errori e vulnerabilità nelle vostre applicazioni web e API che altri scanner e metodi di test potrebbero perdere.
Il test API con fuzzing in GitLab consente di fornire o della tua applicazione, generando automaticamente dati di input casuali destinati a verificare i casi limite e a trovare errori. I risultati vengono riportati immediatamente all'interno della tua pipeline.
Questa è la nostra prima release del test di fuzzing API e saremo felici di sapere cosa ne pensi. Abbiamo molte altre idee in serbo per il test di fuzzing .
e .
Anteprima dei nuovi grafici nella dashboard delle metriche
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In precedenza, creare un grafico nella dashboard delle metriche in GitLab era un compito complesso. Dopo aver creato la metrica nel file YAML della dashboard, dovevi apportare modifiche a master, senza la possibilità di verificare che il grafico appena creato funzioni esattamente come desiderato. A partire da questa versione, puoi visualizzare in anteprima le modifiche mentre crei il grafico, ottenendo un'idea del risultato prima di inviare le modifiche nel file YAML del pannello.
e .
Dati sulla copertura del codice testato per tutti i progetti del gruppo
(PREMIUM, ULTIMATE, SILVER, GOLD)
Quando gestisci un gran numero di progetti in GitLab, hai bisogno di una fonte unica di informazioni su come nel tempo cambia la copertura del codice in tutti i progetti. In precedenza, visualizzare queste informazioni richiedeva un lavoro manuale noioso e dispendioso in termini di tempo: era necessario scaricare i dati sulla copertura del codice da ogni progetto e combinarli in un foglio.
Con la versione 13.4 è stata introdotta la possibilità di raccogliere facilmente e rapidamente in .csv tutti i dati sulla copertura del codice per tutti i progetti del gruppo o per una selezione di progetti. Questa funzionalità è un MVC, a cui seguirà la possibilità .
e .
Supporto per nuove lingue per un completo fuzzing
(ULTIMATE, GOLD)
Questa release introduce il supporto per diverse nuove lingue nel fuzzing, mirato a una copertura completa.
Ora puoi valutare tutte le funzionalità del fuzzing nelle tue applicazioni Java, Rust e Swift e scoprire bug e vulnerabilità che altri scanner e metodi di testing potrebbero trascurare.
e .
Avvisi nella pagina principale degli ambienti
(PREMIUM, ULTIMATE, SILVER, GOLD)
La pagina degli ambienti mostra lo stato generale dei tuoi ambienti. In questa release, abbiamo migliorato questa pagina aggiungendo la visualizzazione degli avvisi. Gli avvisi attivati insieme allo stato dei tuoi ambienti ti aiuteranno a prendere decisioni più rapide per risolvere le situazioni che si presentano.
e .
I pipeline annidati ora possono avviare i loro pipeline annidati
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
L'uso dei pipeline annidati consente di avviare nuovi pipeline all'interno di pipeline figlio. Un ulteriore livello di profondità può essere utile se hai bisogno di flessibilità per generare un numero variabile di pipeline.
In precedenza, l'uso di pipeline annidati richiedeva che ogni pipeline figlio avesse un'attivazione trigger, impostata manualmente nel pipeline genitore. Adesso puoi creare pipeline annidati che avviano dinamicamente qualsiasi numero di nuovi pipeline interni. Ad esempio, se hai un monorepo, puoi generare dinamicamente il primo pipeline annidato, il quale creerà autonomamente il numero necessario di nuovi pipeline in base alle modifiche nel ramo.
e .
Navigazione migliorata tra i pipeline genitori e quelli annidati
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Navigare tra i pipeline genitori e i sottopipeline era prima scomodo: servivano molti clic per arrivare al pipeline desiderato. Inoltre, non era facile capire quale compito avesse avviato quel pipeline. Ora sarà molto più semplice vedere le connessioni tra i pipeline genitori e i sottopipeline.
e .
I compiti di matrice parallela mostrano le variabili pertinenti nel nome del compito
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Se hai utilizzato , potresti aver notato che era difficile determinare quale variabile della matrice fosse stata utilizzata per un compito specifico, poiché i nomi dei compiti apparivano come matrix 1/4. Nella versione 13.4 vedrai i valori pertinenti delle variabili che sono stati utilizzati in questo compito, invece del nome generico del compito. Ad esempio, se il tuo obiettivo è il debug per l'architettura x86, il compito sarà denominato matrix: debug x86.
e .
Altri miglioramenti in GitLab 13.4
Collegamento dell'account Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Ora gli utenti di GitLab possono collegare i propri account GitLab all'account Atlassian Cloud. Questo permetterà di accedere a GitLab utilizzando le credenziali Atlassian e getterà le basi per futuri miglioramenti nell'integrazione. e con altri prodotti della linea Atlassian.
e .
Esportazione dell'elenco di tutti i commit di merge
(ULTIMATE, GOLD)
Le organizzazioni focalizzate sul rispetto delle normative necessitano di un modo per mostrare agli auditor una visione complessiva dei componenti relativi a qualsiasi modifica specifica in produzione. Nel contesto di GitLab, questo significa raccogliere in un unico luogo tutto: richieste di merge, ticket, pipeline, scansioni di sicurezza e altri dati sui commit. Fino ad ora, era necessario raccogliere manualmente queste informazioni in GitLab o configurare strumenti personalizzati per la raccolta, il che non era molto efficiente.
Ora puoi raccogliere e esportare programmaticamente questi dati per soddisfare i requisiti di audit o per condurre altre analisi. Per esportare l'elenco di tutti i commit di merge per il gruppo corrente, devi andare a e cliccare sul pulsante Elenco di tutti i commit di merge. Il file risultante conterrà tutti i commit della merge request, l'autore, l'ID della merge request associata, il gruppo, il progetto, i validatori e altre informazioni.
e .
Visualizzazione dell'elenco e gestione dei token di accesso personali tramite API
(ULTIMATE, GOLD)
La gestione dell'accesso allo spazio dei nomi di GitLab è una parte fondamentale delle attività di conformità. Dalla sicurezza dei principi di minimo privilegio alla revoca dell'accesso temporizzato, possono esserci diversi requisiti legati ai token di accesso personali in GitLab. Per semplificare la gestione e la manutenzione di tutte queste credenziali degli utenti all'interno del tuo spazio dei nomi, abbiamo fornito la possibilità di visualizzare l'elenco di tutti i token di accesso personali e facoltativamente tramite API.
Questi miglioramenti nell'API di GitLab consentono agli utenti di visualizzare l'elenco e di annullare i propri token di accesso personali e agli amministratori di visualizzare l'elenco e di annullare i token dei propri utenti. Ora sarà più facile per gli amministratori vedere chi ha accesso al proprio namespace, prendere decisioni sul conferimento dell'accesso basate sui dati degli utenti e annullare i token di accesso personali che potrebbero essere stati compromessi o che superano le politiche aziendali di gestione dell'accesso.
e .
Ticket correlati e altre funzionalità ora in GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Qualche mese fa abbiamo annunciato il piano per . Lavorando per mantenere questa promessa, abbiamo reso , e (nella localizzazione italiana di GitLab 'bacheca delle discussioni') disponibili nel piano Core. Questo si applica solo ai rapporti di tipo 'correlato a', mentre i rapporti di tipo 'blocca' e 'è bloccato da' rimangono nei piani a pagamento.
e .
Visualizzazione del nome del branch sorgente nella barra laterale della merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Durante la revisione delle modifiche al codice, delle discussioni e dei commit della merge request, è spesso utile fare il checkout locale del branch per una revisione più approfondita. Tuttavia, con l'aggiunta di più contenuti alla descrizione della merge request, trovare il nome del branch diventa sempre più difficile e si è costretti a scorrere ulteriormente la pagina.
Abbiamo aggiunto il nome del branch nella barra laterale della merge request, rendendolo accessibile in qualsiasi momento ed eliminando la necessità di scrollare l'intera pagina. Come nel caso del link alla merge request, la sezione con il branch sorgente contiene un comodo pulsante 'copia'.
Grazie per il suo enorme contributo allo sviluppo di questa funzionalità!
e .
Indicazione della presenza di file compressi nei diff della merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Le merge request che apportano modifiche a più file a volte possono comprimere le differenze di file di grandi dimensioni, migliorando le prestazioni di visualizzazione. Quando ciò accade, è possibile che un file venga accidentalmente saltato durante la revisione, specialmente nei merge request con un numero elevato di file. A partire dalla versione 13.4, i merge request segnaleranno le differenze che contengono file compressi, in modo da non perdere questi file durante la revisione del codice. Per ulteriore chiarezza, prevediamo di aggiungere un evidenziatore per questi file nella prossima release. Rimanete aggiornati su .
e .
Avviso sulla presenza di file compressi nelle differenze del merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nella sezione delle differenze dei merge request, i file di grandi dimensioni sono compressi per migliorare le prestazioni. Tuttavia, durante la revisione del codice, alcuni file possono essere saltati quando il revisore scorre l'elenco dei file, poiché tutti i file di grandi dimensioni sono compressi.
Abbiamo aggiunto un avviso visibile nella parte superiore della pagina del diff della merge request per informare gli utenti che in questa sezione è presente un file compresso. In questo modo, non perderete alcuna modifica nella merge request durante la revisione.
e .
Ripristino automatico del repository del cluster Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In precedenza, quando il nodo primario del cluster Gitaly veniva disconnesso, i repository su quel nodo venivano contrassegnati come disponibili solo per la lettura. Questo preveniva la perdita di dati in situazioni in cui c'erano modifiche sul nodo che non erano ancora state replicate. Quando il nodo veniva riconnesso, GitLab non si ripristinava automaticamente, e gli amministratori dovevano avviare manualmente il processo di sincronizzazione o accettare la perdita di dati. Situazioni come la conclusione non riuscita di un'attività di replica su un nodo secondario potevano anche portare alla creazione di repository obsoleti o disponibili solo per la lettura. In questo caso, il repository rimaneva obsoleto fino a quando non veniva effettuata la successiva operazione di scrittura che avviava l'attività di replica.
Per risolvere questo problema ora pianifica un'operazione di replica quando individua un repository obsoleto su un nodo e l'ultima versione del repository su un altro. Questa operazione di replica aggiorna automaticamente il repository, eliminando la necessità di ripristinare i dati manualmente. Il ripristino automatico consente anche di portare rapidamente le nodi secondari allo stato attuale nel caso in cui l'operazione di replica fallisca, senza dover attendere la prossima operazione di scrittura. Poiché molti cluster Gitaly memorizzano un gran numero di repository, ciò riduce notevolmente il tempo che gli amministratori e gli ingegneri della sicurezza dei dati dedicano al ripristino dei dati dopo un errore.
Inoltre, la riparazione automatica avvia la replica dei repository su qualsiasi nuovo nodo Gitaly aggiunto al cluster, eliminando il lavoro manuale durante l'aggiunta di nuovi nodi.
e .
Segna l'operazione to-do come completata nella pagina di design
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Una comunicazione efficace in GitLab si basa sulle liste di attività da fare. Se sei stato menzionato in un commento, è fondamentale poter passare all'attività e iniziare a lavorarci o segnarla come completata. È anche importante poter assegnare un'attività a te stesso quando devi lavorare su qualcosa o tornare ad essa più tardi.
In precedenza, non era possibile aggiungere attività o segnarle come completate quando si lavorava con i design. Questo comprometteva gravemente l'efficacia della comunicazione tra i team di prodotto, poiché le liste di attività da fare sono un elemento critico del flusso di lavoro in GitLab.
Nella versione 13.4, i design raggiungono i commenti ai ticket nell'uso delle attività, rendendo il lavoro con essi più coerente ed efficace.
e .
Guida migliorata per la risoluzione dei problemi per CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Abbiamo migliorato la guida alla risoluzione dei problemi per GitLab CI/CD, aggiungendo informazioni aggiuntive sui problemi comuni che potresti incontrare. Speriamo che la documentazione migliorata diventi una risorsa preziosa per aiutarti a configurare e avviare facilmente GitLab CI/CD.
e .
Le merge request non vengono più rimosse dalla coda di merge
(PREMIUM, ULTIMATE, SILVER, GOLD)
In precedenza, le merge request potevano essere rimosse casualmente dalla coda di merge a causa di commenti tardivi. Se una merge request era già in coda e qualcuno aggiungeva un commento che creava una nuova discussione non risolta, la merge request veniva considerata non idonea e quindi rimossa. Ora, dopo che una merge request è stata aggiunta alla coda di merge, è possibile aggiungere nuovi commenti senza timore di interrompere il processo di merge.
e .
Visualizzazione del valore di copertura del codice nella merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Gli sviluppatori devono avere la possibilità di vedere il valore della copertura del codice al termine del pipeline, anche in scenari complessi come quello di un pipeline con più task da analizzare per calcolare il valore della copertura. In precedenza, il widget della merge request mostrava solo la media di questi valori, il che significava dover passare alla pagina del task e tornare alla merge request per ottenere i valori intermedi della copertura. Per risparmiare tempo e ridurre questi passaggi inutili, abbiamo implementato nel widget la visualizzazione della media della copertura, le sue variazioni tra i rami target e di origine e un suggerimento che mostra il valore della copertura per ogni task, sulla base del quale è stata calcolata la media.
e .
Rimozione dei pacchetti dal registro dei pacchetti durante la visualizzazione del gruppo
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Il registro dei pacchetti GitLab è un luogo per memorizzare e distribuire pacchetti in vari formati. Quando hai molti pacchetti nel tuo progetto o gruppo, è importante identificare rapidamente quelli non utilizzati e rimuoverli affinché le persone non li scarichino. Puoi rimuovere i pacchetti dal tuo registro tramite o attraverso l'interfaccia utente del registro dei pacchetti. Tuttavia, finora non hai potuto rimuovere pacchetti mentre visualizzavi il gruppo tramite l'interfaccia utente. Di conseguenza, dovevi rimuovere i pacchetti superflui uno per uno per ogni progetto, il che era inefficace.
Ora puoi rimuovere i pacchetti mentre visualizzi il registro dei pacchetti del gruppo. Basta andare alla pagina del registro dei pacchetti del gruppo, filtrare i pacchetti per nome e rimuovere tutto ciò che non serve.
e .
Scalabilità dei pacchetti Conan a livello di progetto
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Puoi utilizzare il repository Conan su GitLab per pubblicare e distribuire dipendenze C/C++. Tuttavia, in precedenza, i pacchetti potevano essere scalati solo a livello di istanza, poiché il nome del pacchetto Conan poteva contenere al massimo 51 caratteri. Se desideravi pubblicare un pacchetto da una sottogruppo, ad esempio gitlab-org/ci-cd/package-stage/feature-testing/conan, era quasi impossibile farlo.
Ora puoi scalare i pacchetti Conan a livello di progetto, il che semplifica la pubblicazione e la distribuzione delle dipendenze dei tuoi progetti.
e .
Supporto per nuovi gestori di pacchetti e linguaggi per la scansione delle dipendenze
(ULTIMATE, GOLD)
Siamo lieti di aggiungere la scansione delle dipendenze per progetti scritti in C, C++, C# e .Net che utilizzano NuGet 4.9+ o gestori di pacchetti Conan alla nostra lista . Ora puoi includere la scansione delle dipendenze come parte della fase Secure, per controllare le vulnerabilità note delle dipendenze aggiunte tramite i gestori di pacchetti. Le vulnerabilità trovate verranno visualizzate nella tua merge request insieme al livello di gravità, così sarai consapevole dei rischi associati a una nuova dipendenza prima di eseguire il merge. Puoi anche configurare il tuo progetto in modo da richiedere per le dipendenze con vulnerabilità di livello critico (Critical), alto (High) o sconosciuto (Unknown).
e .
Notifiche quando la configurazione della merge request viene modificata in ‘Fusione al termine del pipeline’
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In precedenza, quando si impostava la configurazione della merge request Fondere quando il pipeline termina (Merge When Pipeline Succeeds, MWPS) non venivano inviate notifiche via email. Dovevi controllare manualmente lo stato o aspettare una notifica sulla fusione. In questo rilascio siamo lieti di presentare il contributo dell'utente , che ha risolto questo problema aggiungendo l'invio automatico di notifiche a tutti coloro che sono iscritti alla merge request quando il revisore cambia l'impostazione di merge in MWPS.
e .
Creazione di cluster EKS con versione Kubernetes specificata dall'utente
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Gli utenti di GitLab possono ora scegliere autonomamente la versione di Kubernetes fornita da EKS; è possibile selezionare tra le versioni 1.14–1.17.
e .
Creazione di incidenti come tipi di ticket
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Non ogni problema che si presenta attiva immediatamente l'invio di notifiche: gli utenti segnalano malfunzionamenti, mentre i membri dei team si occupano di problemi di prestazioni. Ora gli incidenti sono una categoria di ticket, in modo che i tuoi team possano crearli rapidamente nel loro flusso di lavoro abituale. Clicca Nuova attività da qualsiasi luogo in GitLab, e nel campo Tipo seleziona Incidente.
e .
Riferimenti alle notifiche di GitLab in Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Abbiamo migliorato le notifiche di GitLab aggiungendo un nuovo tipo di citazione specificamente per esse nella versione Markdown di GitLab, rendendo più semplice condividere e menzionare le notifiche. Usa ^alert#1234, per menzionare una notifica in qualsiasi campo con markup Markdown: in incidenti, ticket o merge request. Questo ti aiuterà anche a identificare i compiti creati dalle notifiche piuttosto che dai ticket o dalle merge request.
e .
Visualizzazione del carico delle notifiche sugli incidenti
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
La descrizione della notifica contiene informazioni fondamentali per diagnosticare guasti e recuperi, e queste informazioni devono essere facilmente accessibili, in modo da non dover passare tra strumenti o schede mentre lavori alla risoluzione dell'incidente. Gli incidenti creati da notifiche mostrano la descrizione completa della notifica nella scheda Dettagli Notifica.
Ricerca avanzata 75% più veloce
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab, come applicazione unificata, ha l'opportunità unica di rendere la ricerca dei contenuti in tutto il flusso di lavoro DevOps rapida. Con GitLab 13.4, la ricerca avanzata restituisce risultati più rapidamente del 75%, quando è , come su GitLab.com.
e .
Visualizzazione dei progetti rimossi per gli amministratori
(CORE, STARTER, PREMIUM, ULTIMATE)
La possibilità di posticipare l'eliminazione di un progetto è stata . Tuttavia, prima non era possibile vedere in un unico posto tutti i progetti in attesa di eliminazione. Ora gli amministratori delle istanze personalizzate di GitLab possono visualizzare tutti i progetti in attesa di eliminazione in un unico luogo — insieme ai pulsanti per un facile ripristino di questi progetti.
Questa funzionalità consente agli amministratori di gestire meglio l'eliminazione dei progetti raccogliendo tutte le informazioni necessarie in un unico posto e fornendo la possibilità di annullare azioni indesiderate di eliminazione.
Grazie per questa funzionalità!
e .
Nell'API è stata aggiunta la supporto per le regole di push per il gruppo
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
In precedenza, le regole di push per i gruppi potevano essere configurate solo visitando ogni gruppo individualmente tramite l'interfaccia utente di GitLab e applicando queste regole. Ora puoi gestire queste regole tramite API per supportare i tuoi strumenti personalizzati e l'automazione di GitLab.
e .
Revoca dei token di accesso personali per il deposito delle credenziali autogestito
(ULTIMATE)
fornisce agli amministratori le informazioni necessarie per gestire le credenziali degli utenti del loro istanza GitLab. Poiché le organizzazioni orientate alla conformità differiscono per rigorosità nelle loro politiche di gestione delle credenziali, abbiamo aggiunto un pulsante che consente agli amministratori di revocare, se lo desiderano, il token di accesso personale dell'utente (PAT). Ora gli amministratori possono facilmente revocare PAT potenzialmente compromessi. Questa funzione è utile per le organizzazioni che necessitano di opzioni più flessibili per garantire il rispetto delle normative, riducendo al minimo le distrazioni per i loro utenti.
e .
File di configurazione per l'editor di siti statici
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 13.4, presentiamo un nuovo modo per configurare l'editor di siti statici. Anche se il file di configurazione non salva e non riceve parametri in questa release, gettiamo le basi per future configurazioni del comportamento dell'editor. Nelle prossime versioni, aggiungeremo nel file .gitlab/static-site-editor.yml parametri per la configurazione , su cui , l'override delle impostazioni di sintassi Markdown e altre impostazioni dell'editor.
e .
Modifica dell'introduzione del file utilizzando l'editor di siti statici
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
La parte introduttiva (front matter) è un modo flessibile e conveniente per definire le variabili di pagina nei file di dati destinati ad essere elaborati da un generatore di siti statici. Viene solitamente utilizzata per impostare il titolo della pagina, il modello di layout o l'autore, ma può essere usata per trasmettere qualsiasi tipo di metadati al generatore durante il rendering della pagina in HTML. Inclusa in cima a ogni file di dati, la parte introduttiva è solitamente formattata come YAML o JSON e richiede una sintassi coerente e precisa. Gli utenti non familiari con le specifiche regole di sintassi possono involontariamente inserire markup non valido, il che può portare a problemi di formattazione o addirittura a guasti nella compilazione.
La modalità di modifica WYSIWYG dell'editor di siti statici rimuove già la parte introduttiva dall'editor per prevenire errori di formattazione. Tuttavia, questo non consente di modificare i valori memorizzati in questa parte senza tornare alla modifica in modalità codice sorgente. Con GitLab 13.4, puoi accedere a qualsiasi campo e modificarne il valore in un'interfaccia familiare basata su moduli. Cliccando il pulsante Impostazioni (Impostazioni) si aprirà un pannello che visualizza un campo modulo per ogni chiave definita all'inizio. I campi vengono riempiti con il valore corrente, e per modificare uno qualsiasi di essi è sufficiente immettere il valore nel modulo web. Questa modifica della parte introduttiva permette di evitare complicazioni nella sintassi e ti offre il completo controllo sul contenuto, garantendo nel contempo una formattazione uniforme del risultato finale.
e .
GitLab per Jira e DVCS Connector ora in Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Per gli utenti Jira in GitLab: e consentono di visualizzare informazioni su commit e merge request di GitLab direttamente in Jira. In combinazione con la nostra integrazione incorporata con Jira, puoi facilmente passare tra le due applicazioni mentre lavori.
Queste funzionalità erano precedentemente disponibili solo nel nostro piano Premium, ma ora sono accessibili a tutti gli utenti!
e .
Votazione a maggioranza per le transazioni del cluster Gitaly (versione beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Il cluster Gitaly consente di replicare i repository Git su più nodi Gitaly 'caldi'. Questo aumenta la resilienza eliminando i punti di guasto unici. , presentate in GitLab 13.3, comportano il broadcast delle modifiche a tutti i nodi Gitaly nel cluster, ma solo i nodi Gitaly che raggiungono un accordo con il nodo principale salvano le modifiche su disco. Se tutti i nodi replica non raggiungono un accordo, solo una copia della modifica verrà salvata su disco, creando un punto di guasto unico fino al completamento della replica asincrona.
Il voto a maggioranza aumenta la resilienza, richiedendo il consenso della maggioranza dei nodi (e non di tutti) prima di salvare le modifiche su disco. Se questa funzionalità attivabile è abilitata, la registrazione deve essere eseguita con successo su più nodi. I nodi non concordi vengono automaticamente sincronizzati tramite replica asincrona dai nodi che hanno formato un quorum.
e .
Supporto per uno schema utente per la validazione JSON in Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
I progetti in cui le persone scrivono configurazioni in formato JSON o YAML sono spesso soggetti a problemi, poiché è facile fare un errore di battitura e rompere qualcosa. È possibile scrivere strumenti di verifica che catturano questi problemi nel pipeline CI, ma utilizzare un file di schema JSON può essere utile per fornire documentazione e suggerimenti.
I partecipanti al progetto possono definire nel loro repository il percorso allo schema utente nel file .gitlab/.gitlab-webide.yml, che indica lo schema e il percorso ai file per la verifica. Al caricamento di un file specifico nel Web IDE, saranno visibili feedback aggiuntivi e controlli che aiutano a creare il file.
e .
Il limite di ramificazione del grafo aciclico diretto (DAG) è stato aumentato a 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Se stai utilizzando pipeline (Directed Acyclic Graph (DAG)), potresti aver notato che il limite di 10 lavori che un job può indicare in needs:, è troppo restrittivo. Nella versione 13.4, il limite predefinito è stato aumentato da 10 a 50 per consentire reti più complesse di relazioni tra i job nelle tue pipeline.
Se sei un amministratore di un'istanza utente di GitLab, puoi aumentare ulteriormente questo limite configurando una funzionalità attivabile, sebbene non offriamo supporto ufficiale per questo.
e .
Comportamento migliorato needs per i job mancati
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In alcuni casi, un job mancante in una pipeline poteva essere erroneamente considerato riuscito per le dipendenze indicate in needs, causando l'avvio di job successivi, cosa che non doveva accadere. Questo comportamento è stato corretto nella versione 13.4, e needs ora gestisce correttamente i casi di job mancati.
e .
Fissa l'ultimo artefatto del compito per evitarne l'eliminazione
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab ora bloccando automaticamente l'ultimo artefatto di un compito e di un pipeline su qualsiasi ramo attivo, merge request o tag, per evitarne l'eliminazione dopo la scadenza. È più facile impostare regole di scadenza più aggressive per pulire gli artefatti più vecchi. Questo aiuta a ridurre l'uso dello spazio e garantisce che tu abbia sempre una copia dell'ultimo artefatto della pipeline.
e .
Guida CI/CD per ottimizzare le pipeline
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ottimizzare il lavoro delle pipeline CI/CD può accelerare le consegne e risparmiare denaro. Abbiamo migliorato la nostra documentazione aggiungendo una guida concisa per ottenere il massimo dall'ottimizzazione delle tue pipeline.
e .
Il report di test è ordinato per stato del test
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— è un modo semplice per visualizzare i risultati di tutti i test in pipeline. Tuttavia, con un gran numero di test, la ricerca dei test falliti può richiedere molto tempo. Altri problemi che possono rendere difficile utilizzare il report includono difficoltà nel scorrere lunghe uscite di traceback e l'arrotondamento del tempo a zero per i test eseguiti in meno di 1 secondo. Ora, per impostazione predefinita, il report di test ordina prima i test falliti, per poi ordinare i test in base alla durata. Questo semplifica la ricerca dei fallimenti e dei test più lunghi. Inoltre, la durata dei test ora viene visualizzata in millisecondi o secondi, rendendo la lettura molto più veloce, e sono stati risolti anche i precedenti problemi di scorrimento.
e .
Limitazioni sulle dimensioni dei file caricati nel registro dei pacchetti
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ora ci sono limitazioni sulla dimensione dei file dei pacchetti che possono essere caricati nel registro dei pacchetti GitLab. Le limitazioni sono state aggiunte per ottimizzare le prestazioni del registro dei pacchetti e prevenire abusi. Le limitazioni dipendono dal formato del pacchetto. Per GitLab.com, le dimensioni massime dei file sono:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Per le istanze GitLab personalizzate, i valori predefiniti sono gli stessi. Tuttavia, l'amministratore può aggiornare le limitazioni utilizzando la .
e .
Utilizza CI_JOB_TOKEN per pubblicare pacchetti PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Puoi utilizzare il repository GitLab PyPI per creare, pubblicare e condividere pacchetti Python insieme al codice sorgente e ai pipeliner CI/CD. Tuttavia, prima non potevi autenticarti nel repository utilizzando una variabile d'ambiente predefinita CI_JOB_TOKEN. Di conseguenza, dovevi usare le tue credenziali personali per aggiornare il repository PyPI, oppure potresti aver deciso di non utilizzare affatto il repository.
Ora è più facile utilizzare GitLab CI/CD per pubblicare e installare pacchetti PyPI utilizzando una variabile d'ambiente predefinita CI_JOB_TOKEN.
e .
Profili dello scanner DAST a richiesta
(ULTIMATE, GOLD)
Per la scansione DAST a richiesta, che è stata , sono stati aggiunti profili dello scanner DAST. Questi ampliano le possibilità di configurazione di questa scansione, consentendo di creare rapidamente diversi profili per coprire più tipi di scansione. Nella versione 13.4, il profilo dello scanner include inizialmente un parametro di timeout del crawler, che stabilisce per quanto tempo il crawler DAST deve funzionare mentre tenta di scoprire tutte le pagine del sito scansionato. Il profilo include anche un parametro di timeout del sito di destinazione, per stabilire quanto a lungo lo scanner deve attendere affinché il sito diventi disponibile prima di interrompere la scansione, se il sito non risponde con un codice di stato 200 o 300. Man mano che miglioreremo continuamente questa funzionalità nelle versioni successive, verranno aggiunti ulteriori parametri di configurazione al profilo dello scanner.
e .
File di configurazione semplici per i redirect di GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Se utilizzi GitLab Pages e desideri gestire meglio le modifiche agli URL, avrai notato che gestire i redirect sul tuo sito GitLab Pages era impossibile. GitLab ora ti consente di impostare regole per reindirizzare un URL a un altro per il tuo sito Pages, aggiungendo un file di configurazione al tuo repository. Questa funzione è stata resa possibile grazie al contributo di Kevin Barnett (), del nostro Eric Eastwood () e del team di GitLab. Grazie a tutti per il vostro contributo.
e .
Stato di Terraform gestito da GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
L'accesso alle versioni precedenti dello stato di Terraform è necessario sia per la compliance sia per il debug, se necessario. Il supporto per la gestione delle versioni dello stato di Terraform gestito da GitLab è disponibile a partire da GitLab 13.4. La gestione delle versioni è attivata automaticamente per i nuovi file di stato di Terraform. I file di stato esistenti saranno in una release successiva.
e .
Dettagli importanti sulle notifiche di incidenti
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Quando gestisci gli incidenti, è fondamentale poter identificare facilmente da quanto tempo l'allerta è aperta e quante volte è stato attivato l'evento. Questi dettagli sono spesso cruciali per determinare l'impatto sul cliente e su quali priorità la tua squadra deve concentrarsi. Nel nuovo pannello dei dettagli degli incidenti, mostriamo l'ora di inizio dell'allerta, il numero di eventi e un link all'allerta originale. Queste informazioni sono disponibili per gli incidenti creati a partire da allerte.
e .
Impostazione e modifica del parametro di gravità dell'incidente
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Il parametro 'gravità dell'incidente' consente ai professionisti della risposta e agli interessati di determinare le conseguenze di un'interruzione e i metodi e l'urgenza della risposta. Mentre il tuo team condivide i risultati durante la risoluzione dell'incidente e il ripristino dell'operatività, possono modificare questo parametro. Ora puoi modificare la gravità dell'incidente nel pannello laterale destro della pagina 'Dettagli incidenti', e il grado di gravità è visualizzato nell'elenco degli incidenti.
e .
Creazione, modifica e rimozione di regole di sicurezza della rete per i container
(ULTIMATE, GOLD)
Questo miglioramento dell'editor delle regole di sicurezza della rete per i container consente agli utenti di creare, modificare e rimuovere facilmente le proprie regole direttamente dall'interfaccia utente di GitLab. Le funzionalità dell'editor includono la modalità .yaml per utenti esperti e un editor di regole con un'interfaccia intuitiva per coloro che hanno poca familiarità con le regole di rete. Puoi trovare nuove opzioni di gestione delle regole nella sezione Sicurezza e conformità > Gestione delle minacce > Politiche (Security & Compliance > Threat Management > Policies).
e .
Supporto per lo storage di oggetti blob Azure
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sia GitLab che GitLab Runner ora supportano , semplificando l'avvio dei servizi GitLab su Azure.
Le istanze di GitLab supportano Azure per tutti i tipi di storage di oggetti, inclusi file LFS, artefatti CI e . Per configurare lo storage di oggetti blob Azure, segui le istruzioni per l'installazione o .
I gestori di job di GitLab supportano anche Azure per il caching . Puoi configurare lo storage di Azure tramite la sezione .
e .
Pacchetti Omnibus ARM64 per Ubuntu e OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
In risposta alla crescente domanda di supporto per l'esecuzione di GitLab su architettura ARM a 64 bit, siamo lieti di annunciare la disponibilità del pacchetto ufficiale ARM64 Omnibus per Ubuntu 20.04. Un enorme grazie a Zitai Chen e Guillaume Gardet per il loro importante contributo: le loro richieste di fusione hanno avuto un ruolo chiave in questo!
Per scaricare e installare il pacchetto per Ubuntu 20.04, visita la nostra e selezionare Ubuntu.
e .
Supporto per l'autenticazione tramite smart card per il chart Helm di GitLab
(PREMIUM, ULTIMATE)
Le smart card, come le carte di accesso comune (CAC), possono ora essere utilizzate per l'autenticazione in un'istanza di GitLab distribuita tramite il chart Helm. Le smart card vengono autenticati in un database locale mediante certificati X.509. Di conseguenza, il supporto per le smart card con il chart Helm è ora in linea con il supporto per le smart card disponibile nelle distribuzioni Omnibus.
e .
Le note di rilascio dettagliate e le istruzioni per l'aggiornamento/installazione possono essere lette nel post originale in inglese: .
La traduzione dall'inglese è stata effettuata da , , e .
Fonte: habr.com
