È stata rilasciata la versione 13.4 con il repository HashiCorp per le variabili CI, l'Agent Kubernetes e un centro sicurezza, insieme a funzionalità attivabili nel Starter
In GitLab pensiamo sempre a come aiutare gli utenti a ridurre i rischi, migliorare l'efficienza e velocizzare le consegne sulla vostra piattaforma preferita. Questo mese abbiamo aggiunto diverse novità utili, che ampliano le capacità di sicurezza, riducono il numero di vulnerabilità, aumentano l'efficienza, semplificano l'uso di GitLab e aiutano il vostro team a consegnare funzionalità ancora più velocemente. Speriamo che le principali funzionalità di questo rilascio siano utili a voi e 53 altre nuove funzionalità, aggiunte in questo rilascio.
Maggiori capacità di sicurezza
Cerchiamo di aggiungere ogni mese diverse nuove funzionalità a GitLab DevSecOps, e questo rilascio non fa eccezione. durante la build e il deployment. Inoltre, le organizzazioni che desiderano mantenere una separazione dei compiti nel deployment del codice possono ora . Questo ruolo corrisponde e consentirà di approvare le merge request e di distribuire codice in ambienti protetti, senza offrire accesso alle modifiche del codice stesso.
Un altro modo per ridurre i rischi è utilizzare il nuovo . Gli operatori possono distribuire cluster Kubernetes da GitLab senza la necessità di rendere accessibile il proprio cluster a tutto internet. Presentiamo anche il supporto automatico per il versioning dei nuovi file di stato Terraform con per supportare la conformità e facilitare il debug. Infine, il pannello di sicurezza nell'istanza si è trasformato in con report sulle vulnerabilità e impostazioni di sicurezza.
Lavorare con GitLab è ora più comodo ed efficace
Abbiamo migliorato la nostra ricerca globale, aggiungendo , che consente di accedere facilmente agli ultimo ticket, gruppi, progetti, impostazioni e sezioni di aiuto. Siamo lieti di annunciare che in GitLab Pages per la reindirizzazione di pagine e directory specifiche all'interno del sito, consentendo agli utenti di distribuire i propri siti in modo più efficiente. E per coloro che desiderano ricevere informazioni più dettagliate sulla distribuzione, questa versione consente !
Depositi con codice sorgente aperto
Presentiamo , aggiunto da . Le annotazioni sulla copertura dei test unitari del codice modificato forniscono agli sviluppatori una chiara visione della copertura del codice durante la revisione; queste informazioni aiutano a velocizzare la revisione e a ridurre il tempo necessario per il merge e la distribuzione di nuovo codice. Inoltre, abbiamo e prevediamo .
E questo è solo l'inizio!
Come sempre, nella panoramica generale c'è troppo poco spazio, e le funzionalità interessanti nella versione 13.4 sono molte. Ecco ancora alcune:
- .
Se desideri sapere in anticipo cosa ti aspetta nel prossimo rilascio, guarda .
.
di questo mese —
Fabio ha apportato un contributo significativo in — una funzionalità a lungo attesa nella comunità di GitLab. È davvero un contributo importante con modifiche non banali che hanno richiesto costante collaborazione con i membri del team di GitLab, toccando molte aree del progetto, come UX, frontend e backend.
Le funzionalità principali della versione GitLab 13.4
Utilizza le chiavi HashiCorp Vault nei jobs CI
(PREMIUM, ULTIMATE, SILVER, GOLD)
Nella versione 12.10, GitLab ha introdotto la possibilità di ricevere e passare le chiavi nei jobs CI tramite il runner GitLab. Ora stiamo ampliando , aggiungendo una nuova sintassi secrets nel file .gitlab-ci.yml. Questo faciliterà la configurazione e l'uso dello storage HashiCorp con GitLab.
e .
Presentiamo l'Agente Kubernetes di GitLab
(PREMIUM, ULTIMATE)
L'integrazione di GitLab con Kubernetes consente da tempo di implementare nei cluster Kubernetes senza la necessità di configurazioni manuali. Molti utenti hanno apprezzato la semplicità d'uso di questa combinazione, mentre altri hanno riscontrato alcune difficoltà. Per l'integrazione attuale, il tuo cluster deve essere accessibile da Internet affinché GitLab possa accedervi. Per molte organizzazioni, questo non è fattibile, poiché limitano l'accesso ai cluster per motivi di sicurezza, conformità o regolamentazione. Per aggirare queste limitazioni, gli utenti dovevano creare i propri strumenti sopra GitLab, altrimenti non sarebbero stati in grado di utilizzare questa funzionalità.
Oggi presentiamo GitLab Kubernetes Agent: un nuovo modo di implementare nei cluster Kubernetes. L'agente lavora all'interno del tuo cluster, quindi non sarà necessario aprirlo a tutto Internet. L'agente coordina l'implementazione, richiedendo nuove modifiche a GitLab, invece di ricevere aggiornamenti da GitLab sul cluster. Indipendentemente dal metodo GitOps che utilizzi, GitLab farà al caso tuo.
Si prega di notare che questo è il primo rilascio dell'agente. Attualmente, ci siamo concentrati sulla configurazione e gestione delle implementazioni tramite codice per GitLab Kubernetes Agent. Alcune funzionalità esistenti dell'integrazione Kubernetes, come le schede di implementazione e le applicazioni gestite da GitLab, non sono ancora supportate. , che queste funzionalità verranno aggiunte all'agente in future versioni, così come nuove integrazioni mirate alla sicurezza e alla conformità.
e .
Consenti agli utenti di autorizzare le implementazioni senza accesso al codice
(PREMIUM, ULTIMATE, SILVER, GOLD)
In passato, il sistema di autorizzazione in GitLab non consentiva una chiara separazione dei compiti nel tuo team tra chi si occupa dello sviluppo e chi si occupa delle implementazioni. Con il rilascio di GitLab 13.4, puoi concedere l'autorizzazione per la revisione delle merge request per le implementazioni e anche per l'effettiva implementazione del codice a persone che non scrivono codice, senza concedere loro i diritti di accesso da maintainer.
e .
Centro di 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 pagina unica che racchiudeva i dettagli delle vulnerabilità, i grafici delle metriche e le impostazioni. Non c'era molto spazio per lo sviluppo di queste funzioni o per l'utilizzo di altri strumenti di sicurezza.
Abbiamo apportato modifiche fondamentali alla gestione della sicurezza e alla sua trasparenza in GitLab. La dashboard della sicurezza dell'istanza si è trasformata in un intero centro di sicurezza. La modifica principale è stata l'introduzione di una nuova struttura di menu: invece di una sola pagina, ora puoi vedere separatamente il pannello di controllo della sicurezza, il report delle vulnerabilità e la sezione delle impostazioni. Anche se le funzionalità non sono cambiate, la suddivisione in parti consentirà di migliorare questa sezione, cosa che altrimenti sarebbe stata difficile. Questo crea anche una base per aggiungere in futuro altre funzionalità relative alla sicurezza.
Ora c'è più spazio nella sezione dedicata al report delle vulnerabilità per mostrare dettagli importanti. Qui sono raccolte le vulnerabilità che attualmente si trovano nell'elenco delle vulnerabilità del progetto. Spostare i widget con le metriche delle vulnerabilità in una sezione separata crea un pannello di controllo della sicurezza più comodo. Adesso è una base per future visualizzazioni — non solo per la gestione delle vulnerabilità, ma anche per qualsiasi metrica relativa alla sicurezza. Infine, un'area distinta per le impostazioni 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 . In 12.2 abbiamo introdotto strategie per esse e , e in 13.1 abbiamo aggiunto e per diversi ambienti.
All'inizio di quest'anno, GitLab si è impegnato a in open source. In questo rilascio abbiamo completato il trasferimento delle funzionalità attivabili nel piano Starter e continueremo a trasferirle nel Core con . Siamo felici di offrire questa opportunità a un numero più ampio di utenti e vogliamo sapere come le utilizzerete.
e .
Navigazione rapida dalla barra di ricerca
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A volte, navigando su GitLab, desideri andare direttamente a un progetto specifico invece di una pagina con i risultati di ricerca.
Con la barra di ricerca globale puoi accedere rapidamente agli ultimi ticket, gruppi, progetti, impostazioni e sezioni della guida. Puoi persino utilizzare la scorciatoia da tastiera /, per spostare il cursore sulla barra di ricerca e muoverti ancora più efficacemente su GitLab!
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 può essere difficile determinare se il codice modificato sia coperto dai test unitari. Invece, i revisori possono fare affidamento sulla copertura complessiva e richiedere un aumento prima di approvare la merge request. Questo può portare a un approccio disordinato nella scrittura dei test, che in realtà non migliorerà la qualità del codice o la sua copertura.
Ora, quando visualizzi le differenze di una merge request, vedrai una rappresentazione visiva della copertura del codice. Nuove annotazioni consentiranno di capire rapidamente se il codice modificato è coperto da test unitari, aiutando ad accelerare la revisione del codice e il tempo di merging e deployment del nuovo codice.
Grazie e Siemens per questa funzionalità!
e .
Più ambienti e progetti nella barra 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 questa barra nel rilascio 13.4, suddividendola in pagine per aiutarti a gestire e mantenere i tuoi ambienti su larga scala. Ora puoi vedere più ambienti in un numero maggiore di progetti.
e .
GitLab ha adottato la gestione del provider GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recentemente abbiamo e prevediamo Nell'ultimo mese abbiamo accettato 21 merge request e chiuso 31 ticket, inclusi alcuni bug storici e funzionalità mancanti come Puoi nella documentazione di Terraform.
e .
Test di fuzzing API con specifiche OpenAPI o file HAR
(ULTIMATE, GOLD)
Il fuzzing testing delle API è un ottimo modo per individuare errori e vulnerabilità nelle vostre applicazioni web e API che altri scanner e metodi di test potrebbero trascurare.
Il test delle API tramite fuzzing in GitLab consente di fornire o della vostra applicazione, generando automaticamente dati di input casuali destinati a testare i casi limite e scoprire errori. I risultati vengono visualizzati immediatamente all'interno della vostra pipeline.
Questa è la nostra prima versione del test delle API tramite fuzzing e siamo curiosi di sapere cosa ne pensate. Abbiamo molte altre , su cui ci baseremo in seguito al rilascio di questa funzionalità.
e .
Anteprima di nuovi grafici sulla dashboard delle metriche
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In precedenza, la creazione di grafici sulla dashboard delle metriche in GitLab era un compito complesso. Una volta creato il metrica nel file YAML della dashboard, apportavate modifiche a master, senza avere la possibilità di verificare che il grafico appena creato funzionasse come necessario. A partire da questa versione, potrete visualizzare in anteprima le modifiche mentre create il grafico, ottenendo un’idea del risultato prima di inviare le modifiche nel file YAML della dashboard.
e .
Dati sulla copertura del codice dei test per tutti i progetti del gruppo
(PREMIUM, ULTIMATE, SILVER, GOLD)
Quando gestite un gran numero di progetti in GitLab, avete bisogno di una fonte unica di informazioni su come evolve nel tempo la copertura del codice in tutti i progetti. In precedenza, visualizzare queste informazioni richiedeva un lavoro manuale noioso e laborioso: era necessario scaricare i dati sulla copertura del codice dei test da ogni progetto e combinarli in un tabella.
Nella versione 13.4 è stata introdotta la possibilità di raccogliere facilmente e rapidamente tutti i dati sulla copertura del codice di tutti i progetti del gruppo o di un campione di progetti in un .csv file. Questa funzionalità è una MVC, seguita dalla possibilità di .
e .
Supporto per nuovi linguaggi per un fuzzing testing completo
(ULTIMATE, GOLD)
Questa versione introduce il supporto per diversi nuovi linguaggi per il fuzzing testing, mirato a una copertura completa.
Ora puoi valutare tutte le possibilità del fuzzing testing nelle tue applicazioni in Java, Rust e Swift e scoprire errori e vulnerabilità che altri scanner e metodi di test potrebbero trascurare.
e .
Avvisi sulla pagina principale degli ambienti
(PREMIUM, ULTIMATE, SILVER, GOLD)
La pagina degli ambienti mostra lo stato complessivo dei tuoi ambienti. In questa versione abbiamo migliorato questa pagina aggiungendo la visualizzazione degli avvisi. Gli avvisi attivi insieme allo stato dei tuoi ambienti ti aiuteranno a prendere misure correttive più rapidamente.
e .
I pipeline annidati possono ora eseguire i propri pipeline annidati
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Con l'uso di pipeline annidati, è ora possibile avviare nuovi pipeline all'interno dei pipeline figlio. Un ulteriore livello di profondità può essere utile se hai bisogno di flessibilità per generare un numero variabile di pipeline.
In precedenza, quando si utilizzavano i pipeline annidati, ogni pipeline figlio aveva bisogno di un trigger configurato manualmente nel pipeline genitore. Ora puoi creare pipeline annidati che attiveranno dinamicamente qualsiasi numero di nuovi pipeline annidati. Ad esempio, se hai un monorepo, puoi generare dinamicamente il primo pipeline annidato, che creerà 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)
In precedenza, muoversi tra i pipeline genitori e annidati non era molto conveniente: erano necessari molti clic per raggiungere il pipeline desiderato. Era anche difficile capire quale attività avesse avviato quel pipeline. Ora sarà molto più facile vedere le relazioni tra i pipeline genitori e quelli annidati.
e .
I task di matrice paralleli mostrano variabili pertinenti nel nome del task
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Se hai utilizzato , potresti aver notato che era difficile determinare quale variabile della matrice fosse utilizzata per un task specifico, poiché i nomi dei task sembravano come matrix 1/4. Nella versione 13.4 vedrete valori rilevanti delle variabili utilizzate in questo compito, invece del nome generico del compito. Per esempio, se il vostro obiettivo è il debug per l'architettura x86, il compito si chiamerà matrix: debug x86.
e .
Altri miglioramenti in GitLab 13.4
Collegamento dell'account Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Gli utenti di GitLab ora potranno collegare i loro account GitLab all'account Atlassian Cloud. Questo permetterà di autenticarsi in GitLab con le credenziali Atlassian e getterà le basi per futuri miglioramenti nell'integrazione e con altri prodotti della gamma Atlassian.
e .
Esportazione della lista di tutti i commit di merge
(ULTIMATE, GOLD)
Le organizzazioni focalizzate sul rispetto dei requisiti hanno bisogno di un modo per mostrare agli auditor una visione globale dei componenti legati a qualsiasi specifica modifica in produzione. Nel contesto di GitLab, questo significa che è necessario raccogliere in un unico posto tutto: richieste di merge, ticket, pipeline, scansioni di sicurezza e altri dati sui commit. Fino ad ora, dovevate raccogliere manualmente queste informazioni in GitLab o configurare i vostri strumenti per raccoglierle, il che era poco efficiente.
Ora potete raccogliere e esportare programmaticamente questi dati per soddisfare i requisiti di audit o per altre analisi. Per esportare l'elenco di tutti i commit di merge per l'attuale gruppo, dovete andare al e cliccare sul pulsante Elenco di tutti i commit di merge. Il file risultante conterrà tutti i commit della richiesta di merge, il loro autore, l'ID della richiesta di merge associata, il gruppo, il progetto, le approvazioni e ulteriori informazioni.
e .
Output dell'elenco e gestione dei token di accesso personali tramite API
(ULTIMATE, GOLD)
La gestione dell'accesso allo spazio dei nomi GitLab è una parte importante delle attività di conformità. Dai principi del minimo privilegio alla disattivazione dell'accesso a tempo — potrebbero esserci diversi requisiti legati ai token di accesso personali in GitLab. Per facilitare la gestione di tutte queste credenziali utente all'interno dello spazio dei nomi, abbiamo fornito la possibilità di visualizzare l'elenco di tutti i token di accesso personali e opzionalmente tramite API.
Questi miglioramenti nell'API di GitLab consentono agli utenti di generare un elenco e revocare i propri token di accesso personali, mentre gli amministratori possono generare un elenco e revocare i token dei propri utenti. Ora sarà più facile per gli amministratori vedere chi ha accesso al proprio namespace, prendere decisioni di concessione dell'accesso basate sui dati degli utenti e revocare i token di accesso personali che potrebbero essere stati compromessi o che non rispettano 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 un piano per . Lavorando per mantenere questa promessa, abbiamo creato , e (nella localizzazione russa 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 ramo 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 auspicabile eseguire un checkout locale del ramo per una revisione più approfondita. Tuttavia, trovare il nome del ramo diventa sempre più difficile man mano che viene aggiunto contenuto alla descrizione della merge request, costringendo a scorrere sempre più la pagina.
Abbiamo aggiunto il nome del ramo nella barra laterale della merge request, rendendolo disponibile in qualsiasi momento e eliminando la necessità di scorrere l'intera pagina. Come per il collegamento alla merge request, la sezione con il ramo 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 delle merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Le merge request che apportano modifiche a più file a volte accorciano i diff di file di grandi dimensioni per migliorare le prestazioni di visualizzazione. Quando ciò accade, potrebbe capitare di saltare accidentalmente un file durante la revisione, specialmente nelle merge request con un numero elevato di file. A partire dalla versione 13.4, le merge request evidenzieranno i diff contenenti file accorciati, così non perderai questi file durante il processo di revisione del codice. Per una maggiore chiarezza, prevediamo di aggiungere una evidenziazione di questi file in una futura release. Tieni d'occhio gli aggiornamenti in .
e .
Avviso sulla presenza di file accorciati nel diff della merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nella sezione dei diff delle merge request, i file di grandi dimensioni vengono accorciati per migliorare le prestazioni. Tuttavia, durante la revisione del codice, alcuni file potrebbero essere saltati quando il revisore scorre l'elenco dei file, poiché tutti i file di grandi dimensioni sono accorciati.
Abbiamo aggiunto un avviso visibile in cima alla pagina del diff della merge request per informare gli utenti che in questa sezione è presente un file accorciato. In questo modo, non perderai 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 scollegato, i repository su quel nodo venivano contrassegnati come accessibili solo in lettura. Questo evitava la perdita di dati in situazioni in cui vi erano modifiche che non erano ancora state replicate. Quando il nodo si ricollegava, GitLab non veniva ripristinato automaticamente, e gli amministratori dovevano avviare manualmente il processo di sincronizzazione o rassegnarsi alla perdita di dati. Anche altre situazioni, come un fallimento del task di replicazione sul nodo secondario, potevano portare a repository obsoleti o accessibili solo in lettura. In tal caso, il repository rimaneva obsoleto fino a quando non era stata eseguita la successiva operazione di scrittura che avrebbe attivato il task di replicazione.
Per risolvere questo problema ora pianifica un'operazione di replica quando rileva un repository obsoleto su un nodo e l'ultima versione del repository su un altro. Questa operazione di replica rende automaticamente il repository aggiornato, eliminando la necessità di ripristinare i dati manualmente. Il ripristino automatico consente anche un rapido aggiornamento dei nodi secondari, nel caso in cui l'operazione di replica fallisca, invece di dover attendere la prossima operazione di scrittura. Poiché molti cluster Gitaly ospitano un grande numero di repository, questo riduce significativamente il tempo che gli amministratori e gli ingegneri della affidabilità spendono per il ripristino dei dati dopo un errore.
Inoltre, la riparazione automatica avvia la replicazione dei repository su qualsiasi nuovo nodo Gitaly aggiunto al cluster, eliminando il lavoro manuale nell'aggiunta di nuovi nodi.
e .
Contrassegna 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 operazioni to-do. Se sei stato menzionato in un commento, è fondamentale avere la possibilità di passare all'operazione e iniziare a lavorare, oppure contrassegnarla come già completata. È anche importante poter assegnare l'operazione a te stesso quando hai bisogno di lavorare su qualcosa o di tornarci in un secondo momento.
In precedenza non era possibile aggiungere operazioni o contrassegnarle come completate quando si lavorava sui design. Questo ha seriamente compromesso l'efficacia della comunicazione tra i team di prodotto, poiché le operazioni to-do sono un elemento critico del flusso di lavoro in GitLab.
Nella versione 13.4 i design raggiungono i commenti sui ticket nell'utilizzo delle operazioni, rendendo il loro utilizzo più coerente ed efficiente.
e .
Guida migliorata alla 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 sulle problematiche comuni che potresti riscontrare. Speriamo che la documentazione migliorata diventi una risorsa preziosa per aiutarti a configurare e avviare rapidamente e semplicemente GitLab CI/CD.
e .
Le merge request non escono più dalla coda di merge
(PREMIUM, ULTIMATE, SILVER, GOLD)
In precedenza, le merge request potevano uscire dalla coda di merge casualmente a causa di commenti tardivi. Se una merge request era già nella coda e qualcuno aggiungeva un commento che creava una nuova discussione irrisolta, la merge request era considerata non idonea per il merge ed usciva dalla coda. Ora, dopo che la merge request viene aggiunta alla coda di merge, è possibile aggiungere nuovi commenti senza temere di interrompere il processo di merge.
e .
Visualizzazione nel merge request del valore di copertura del codice per i job
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Gli sviluppatori devono avere la possibilità di vedere il valore di copertura del codice dopo il completamento del pipeline, anche in scenari complessi, come il funzionamento del pipeline con più job, che devono essere analizzati per calcolare il valore di copertura. In precedenza, il widget del merge request mostrava solo la media di questi valori, il che significava che dovevi passare alla pagina del job e tornare al merge request per ottenere i valori intermediali di copertura. Per risparmiare tempo e liberarti di questi passaggi superflui, abbiamo fatto in modo che il widget mostrasse la media della copertura, la sua variazione tra il branch di destinazione e quello di origine e un suggerimento che mostra il valore di copertura per ogni job su cui è stata calcolata la media.
e .
Rimozione di pacchetti dal registry durante la visualizzazione del gruppo
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Il registry dei pacchetti di GitLab è un luogo per memorizzare e distribuire pacchetti in vari formati. Quando ci sono molti pacchetti nel tuo progetto o gruppo, è necessario identificare rapidamente i pacchetti non utilizzati e rimuoverli, in modo che le persone non possano scaricarli. Puoi rimuovere i pacchetti dal tuo registry tramite o tramite l'interfaccia utente del registry dei pacchetti. Tuttavia, fino ad ora non potevi rimuovere i pacchetti durante la visualizzazione del gruppo tramite l'interfaccia utente. Di conseguenza, dovevi rimuovere i pacchetti non necessari separatamente per ogni progetto, il che era inefficiente.
Ora puoi rimuovere i pacchetti durante la visualizzazione del registry dei pacchetti del gruppo. Basta andare alla pagina del registry dei pacchetti del gruppo, filtrare i pacchetti per nome e rimuovere tutti quelli non necessari.
e .
Scalabilità dei pacchetti Conan a livello di progetto
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Puoi utilizzare il repository Conan in 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 volevi pubblicare un pacchetto da una sottogruppo, per 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 facilita 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 felici di aggiungere la scansione delle dipendenze per progetti con codice 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 Sicura, per controllare le dipendenze aggiunte tramite gestori di pacchetti per eventuali vulnerabilità note. Le vulnerabilità trovate verranno visualizzate nella tua richiesta di merge insieme al livello di gravità, affinché tu sappia quali rischi comporta la 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 richiesta di merge viene modificata in 'Fusione al termine del pipeline'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In precedenza, quando veniva impostata la configurazione della richiesta di merge Fondere quando il pipeline è completato (Merge When Pipeline Succeeds, MWPS) non veniva inviata alcuna email di notifica. Dovevi controllare manualmente lo stato o aspettare una notifica di completamento del merge. In questa release siamo felici di presentare il contributo dell'utente , che ha risolto questo problema aggiungendo l'invio automatico di notifiche a tutti gli iscritti alla richiesta di merge quando il revisore cambia l'impostazione di fusione su MWPS.
e .
Creazione di cluster EKS con versione Kubernetes fornita dall'utente
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Gli utenti di GitLab possono ora scegliere la versione di Kubernetes che sarà fornita da EKS; è possibile scegliere 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 guasti, mentre i membri dei team indagano sui problemi di prestazioni. Ora gli incidenti sono un tipo di ticket, così le tue squadre potranno crearli rapidamente all'interno del flusso di lavoro abituale. Clicca Nuovo compito da qualsiasi luogo in GitLab, e nel campo Tipo seleziona Incidente.
e .
Riferimento delle notifiche GitLab in Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Abbiamo migliorato le notifiche GitLab, aggiungendo un nuovo tipo di riferimento appositamente per esse nella versione Markdown di GitLab, facilitando la condivisione e la menzione delle notifiche. Usa ^alert#1234, per menzionare la notifica in qualsiasi campo con markup Markdown: negli incidenti, nei ticket o nelle merge request. Questo ti aiuterà anche a identificare le attività create dalle notifiche e non 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 critiche per diagnosticare guasti e recupero, e queste informazioni devono essere facilmente accessibili, così non è necessario passare da un'applicazione all'altra o da una scheda all'altra mentre lavori per risolvere l'incidente. Gli incidenti creati dalle notifiche mostrano una descrizione completa della notifica nella scheda Dettagli della Notifica.
Ricerca avanzata 75% più veloce
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Con GitLab, come applicazione unica, c'è un'opportunità unica di rendere la ricerca di contenuti in tutto il flusso di lavoro DevOps rapida. In GitLab 13.4, la ricerca avanzata restituisce risultati 75% più velocemente quando è , come su GitLab.com.
e .
Visualizzazione dei progetti rimossi per gli amministratori
(CORE, STARTER, PREMIUM, ULTIMATE)
La possibilità di posticipare la rimozione di un progetto è stata . Tuttavia, in passato non era possibile vedere in un unico luogo tutti i progetti in attesa di eliminazione. Ora gli amministratori delle istanze utente di GitLab possono visualizzare tutti i progetti in attesa di eliminazione in un unico posto, insieme ai pulsanti per un facile recupero di questi progetti.
Questa funzionalità consente agli amministratori di avere un controllo migliore sull'eliminazione dei progetti, raccogliendo tutte le informazioni necessarie in un unico luogo e offrendo la possibilità di annullare azioni indesiderate di eliminazione.
Grazie per questa funzione!
e .
Nel 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 di gruppo potevano essere configurate solo visitando ogni gruppo singolarmente 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 di credenziali autogestito
(ULTIMATE)
fornisce agli amministratori le informazioni necessarie per gestire le credenziali degli utenti nella loro istanza di GitLab. Poiché le organizzazioni incentrate sulla conformità differiscono nella severità delle loro regole 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 la compliance, 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 introduciamo un nuovo modo per configurare l'editor di siti statici. Anche se il file di configurazione non salva né recupera parametri in questa release, poniamo le basi per future configurazioni del comportamento dell'editor. Nelle prossime release aggiungeremo nel file .gitlab/static-site-editor.yml parametri per impostare , su cui , ridefinire le impostazioni della sintassi Markdown e altre impostazioni dell'editor.
e .
Modifica della parte introduttiva 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 all'elaborazione da parte di un generatore di siti statici. Di solito viene utilizzata per impostare il titolo della pagina, il modello di layout o l'autore, ma può essere utilizzata per trasmettere qualsiasi tipo di metadati al generatore durante il rendering della pagina in HTML. Inclusa nella parte superiore di ogni file di dati, la parte introduttiva è solitamente formattata come YAML o JSON e richiede una sintassi coerente e precisa. Gli utenti poco familiari con le regole di sintassi specifiche possono inavvertitamente inserire un markup non valido, il che, a sua volta, può causare problemi di formattazione o anche guasti nella compilazione.
La modalità di modifica WYSIWYG dell'editor di siti statici rimuove già la parte introduttiva dall'editor per evitare questi errori di formattazione. Tuttavia, non consente di modificare i valori contenuti in questa parte senza tornare alla modifica in modalità codice sorgente. In GitLab 13.4 puoi accedere a qualsiasi campo e modificarne il valore in un'interfaccia familiare basata su moduli. Facendo clic sul pulsante Impostazioni (Impostazioni) si aprirà un pannello che mostra il campo modulo per ogni chiave definita all'inizio. I campi vengono popolati con il valore corrente, e per modificare uno di essi è sufficiente inserire il valore nel modulo web. Questa modifica della parte introduttiva consente di evitare complessità di sintassi e ti offre il pieno controllo sul contenuto, garantendo al 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 di Jira in GitLab: e consentono di visualizzare informazioni su commit e merge request di GitLab direttamente in Jira. In combinazione con la nostra integrazione nativa con Jira, puoi facilmente muoverti 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 "caldi" Gitaly. Ciò aumenta la resilienza eliminando i singoli punti di guasto. , presentate in GitLab 13.3, innescano una diffusione delle modifiche a tutti i nodi Gitaly nel cluster, ma solo i nodi Gitaly che votano in accordo con il nodo principale salvano le modifiche su disco. Se non tutti i nodi replica arrivano a un accordo, solo una copia della modifica sarà salvata su disco, creando un singolo punto di guasto fino al termine della replica asincrona.
La votazione 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 dovrà essere completata con successo su più nodi. I nodi non concordi si sincronizzano automaticamente tramite replica asincrona con i nodi che hanno formato il quorum.
e .
Supporto per uno schema personalizzato 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, perché è facile fare un errore di battitura e danneggiare qualcosa. È possibile scrivere strumenti di verifica per catturare questi problemi nel pipeline CI, ma utilizzare un file schema JSON può essere utile per fornire documentazione e suggerimenti.
I partecipanti al progetto possono definire nel loro repository il percorso allo schema personalizzato nel file .gitlab/.gitlab-webide.yml, che specifica lo schema e il percorso ai file da controllare. Quando si carica un file specifico in Web IDE, sarà visibile un feedback aggiuntivo e una verifica che aiuterà a creare il file.
e .
Il limite di ramificazione del grafo aciclico diretto (DAG) è aumentato a 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Se utilizzi pipeline (Directed Acyclic Graph (DAG)), puoi aver notato che il limite di 10 lavori che un lavoro può specificare in needs:, troppo severo. Nella versione 13.4 il limite predefinito è stato aumentato da 10 a 50 per garantire reti di relazioni più complesse tra i compiti nei vostri pipeline.
Se sei un amministratore dell'istanza utente di GitLab, puoi aumentare ulteriormente questo limite attivando una funzionalità opzionale, anche se non offriamo supporto ufficiale per questo.
e .
Comportamento migliorato needs per i compiti saltati
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In alcuni casi, un compito saltato nel pipeline poteva essere erroneamente considerato riuscito per le dipendenze specificate in needs, il che causava l'esecuzione di compiti successivi, cosa che non avrebbe dovuto accadere. Questo comportamento è stato corretto nella versione 13.4, e needs ora gestisce correttamente i casi di compiti saltati.
e .
Blocca l'ultimo artefatto del compito per impedirne la rimozione
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab ora blocca automaticamente l'ultimo artefatto di un compito e del pipeline su qualsiasi ramo attivo, richiesta di merge o tag, per impedirne la rimozione dopo la scadenza. Diventa più semplice stabilire regole di scadenza più aggressive per liberare vecchi artefatti. Questo aiuta a ridurre l'utilizzo dello spazio su disco e garantisce che abbiate sempre una copia dell'ultimo artefatto dal pipeline.
e .
Guida CI/CD per l'ottimizzazione del pipeline
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ottimizzare il pipeline CI/CD può aumentare la velocità di consegna e risparmiare denaro. Abbiamo migliorato la nostra documentazione aggiungendo una guida sintetica per ottenere il massimo dall'ottimizzazione dei vostri pipeline.
e .
Il rapporto di test è ordinato per stato del test
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— è un modo semplice per vedere i risultati di tutti i test nel pipeline. Tuttavia, con un numero elevato di test, trovare i test falliti può richiedere molto tempo. Altri problemi che possono rendere difficile utilizzare il report includono difficoltà a scorrere dati di output lunghi e arrotondare il tempo a zero per i test eseguiti in meno di 1 secondo. Ora, per impostazione predefinita, il report di test colloca prima i test falliti all'inizio del report, e poi ordina i test in base alla durata. Questo semplifica la ricerca di errori e test lunghi. Inoltre, la durata dei test ora viene visualizzata in millisecondi o secondi, rendendo la lettura molto più rapida e risolvendo anche i problemi di scorrimento precedenti.
e .
Limiti sulla dimensione dei file caricati nel registry dei pacchetti
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ora ci sono limiti sulla dimensione dei file dei pacchetti che possono essere caricati nel registry dei pacchetti GitLab. Sono stati aggiunti limiti per ottimizzare le prestazioni del registry e prevenire abusi. I limiti 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 personalizzate di GitLab, i valori predefiniti sono gli stessi. Tuttavia, l'amministratore può aggiornare i limiti tramite .
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 pipeline CI/CD. In precedenza, non riuscivi ad autenticarti al repository usando una variabile d'ambiente predefinita CI_JOB_TOKEN. Di conseguenza, dovevi utilizzare le tue credenziali personali per aggiornare il repository PyPI, o 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 su richiesta
(ULTIMATE, GOLD)
Per la scansione DAST su richiesta, che è stata , sono stati aggiunti profili dello scanner DAST. Questi ampliano le opzioni di configurazione di questa scansione, consentendo di creare rapidamente più profili per coprire diversi tipi di scansione. Nella versione 13.4, il profilo dello scanner include inizialmente un parametro di timeout per il crawler, che stabilisce quanto a lungo deve funzionare il crawler DAST quando tenta di scoprire tutte le pagine del sito esaminato. Il profilo include anche un parametro di timeout per il sito target, per stabilire per quanto tempo lo scanner deve attendere che il sito diventi disponibile, prima di interrompere la scansione, se il sito non risponde con un codice di stato 200 o 300. Mentre continueremo a migliorare questa funzionalità nelle prossime versioni, verranno aggiunti ulteriori parametri di configurazione al profilo dello scanner.
e .
File di configurazione semplice 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, potresti aver notato che gestire i redirect sul tuo sito GitLab Pages era impossibile. GitLab ora ti consente di configurare regole per reindirizzare un URL a un altro per il tuo sito Pages, aggiungendo un file di configurazione al repository. Questa funzionalità è stata resa possibile grazie alla partecipazione di Kevin Barnett (), il nostro Eric Eastwood () e il 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 soddisfare i requisiti che per il debug, se necessario. Il supporto per il versionamento dello stato di Terraform gestito da GitLab è disponibile a partire da GitLab 13.4. Il versionamento viene attivato automaticamente per i nuovi file di stato di Terraform. I file di stato esistenti di Terraform verranno in una versione successiva.
e .
Dettagli importanti sulla notifica degli incidenti
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Durante la gestione degli incidenti, è fondamentale poter determinare facilmente quanto tempo l'allerta sia stata attiva e quante volte si è verificato l'evento. Questi dettagli sono spesso cruciali per valutare l'impatto sul cliente e per decidere quali azioni la tua squadra dovrebbe intraprendere per prime. Nella nuova scheda dei dettagli sugli incidenti, mostriamo l'orario di inizio dell'allerta, il numero di eventi e un link all'allerta originale. Queste informazioni sono disponibili per gli incidenti generati dagli avvisi.
e .
Impostazione e modifica del livello di gravità dell'incidente
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Il parametro "gravità dell'incidente" consente ai responsabili della risposta e alle parti interessate di determinare le conseguenze di un'interruzione, nonché i metodi e l'urgenza della risposta. Man mano che il tuo team comunica i risultati durante la risoluzione dell'incidente e ripristina il normale funzionamento, può modificare questo parametro. Ora puoi modificare la gravità dell'incidente nel pannello laterale destro della pagina "Dettagli incidenti", e il livello di gravità viene visualizzato nell'elenco degli incidenti.
e .
Creazione, modifica e rimozione di regole di sicurezza della rete dei container
(ULTIMATE, GOLD)
Questo miglioramento dell'editor delle regole di sicurezza della rete dei 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 possibilità di gestione delle regole nella sezione Sicurezza e conformità > Gestione delle minacce > Regole (Sicurezza & Conformità > Gestione delle minacce > Politiche).
e .
Supporto per lo storage di oggetti blob di Azure
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sia GitLab che GitLab Runner ora supportano , semplificando l'esecuzione 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 di Azure, segui le istruzioni per l'installazione o .
I gestori di lavori di GitLab supportano anche Azure per lo storage . Il deposito Azure può essere configurato tramite la sezione .
e .
Pacchetti Omnibus ARM64 per Ubuntu e OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
In risposta alla crescente domanda per supporto all'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 ringraziamento a Zitai Chen e Guillaume Gardet per il loro significativo contributo — le loro richieste di merge hanno avuto un ruolo chiave in questo!
Per scaricare e installare il pacchetto per Ubuntu 20.04, visita la nostra e seleziona Ubuntu.
e .
Supporto all'autenticazione tramite smart card per il chart Helm di GitLab
(PREMIUM, ULTIMATE)
Le smart card, come le carte d'accesso comuni (CAC), possono ora essere utilizzate per l'autenticazione su un'istanza di GitLab distribuita tramite il chart Helm. Le smart card si autenticano nel database locale utilizzando certificati X.509. Grazie a ciò, il supporto per le smart card nel chart Helm è ora in linea con il supporto per 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: .
Il lavoro di traduzione dall'inglese è stato effettuato da , , e .
Fonte: habr.com
