Rilevamento rapido delle perdite di segreti
Sembra un piccolo errore: inviare accidentalmente le credenziali in un repository condiviso. Tuttavia, le conseguenze possono essere gravi. Non appena un attaccante ottiene la tua password o la tua chiave API, può prendere il controllo del tuo account, bloccarti e utilizzare i tuoi soldi in modo fraudolento. Inoltre, si può verificare un effetto domino: l'accesso a un account apre l'accesso ad altri. Le scommesse sono alte, quindi è estremamente importante scoprire le perdite di segreti il prima possibile.
In questa release presentiamo l'opzione all'interno della nostra funzionalità SAST. Ogni commit viene scansionato in un lavoro CI/CD per eventuali segreti. Se viene trovato un segreto, lo sviluppatore riceve un avviso nella merge request. Può quindi annullare le credenziali trapelate sul posto e crearne di nuove.
Garanzia di una corretta gestione delle modifiche
Con la crescita e la complessità, mantenere la coerenza tra le diverse parti dell'organizzazione diventa sempre più difficile. Più utenti ci sono nell'app e maggiore è il reddito, più gravi sono le conseguenze di un merge di codice errato o non sicuro. Per molte organizzazioni, garantire un processo di revisione adeguato prima del merge del codice è un requisito rigoroso, poiché i rischi sono molto alti.
In GitLab 11.9 c'è maggiore controllo e una struttura più efficace grazie a . In precedenza, per ottenere un'approvazione, era sufficiente nominare una singola persona o gruppo (ogni membro del quale poteva fornire l'approvazione). Ora è possibile aggiungere più regole affinché le merge request richiedano l'approvazione da parte di persone specifiche o di più membri di un gruppo specifico. Inoltre, nelle regole di approvazione è integrata la funzionalità Code Owners, che consente di identificare facilmente chi ha fornito l'approvazione.
Questo consente alle organizzazioni di attuare processi di approvazione complessi, mantenendo al contempo la semplicità di un'unica applicazione GitLab, dove compiti, codice, pipeline e dati di monitoraggio sono visibili e accessibili per decisioni e accelerare il processo di approvazione.
ChatOps è ora open source
GitLab ChatOps è uno strumento di automazione efficace che consente di eseguire qualsiasi job CI/CD e richiederne lo stato direttamente in applicazioni di chat come Slack e Mattermost. , ChatOps era parte dell'abbonamento GitLab Ultimate. Sulla base della e , a volte spostiamo le funzionalità verso il basso e mai verso l'alto.
Nel caso di ChatOps, abbiamo capito che questa funzionalità potrebbe essere utile a tutti e che il coinvolgimento della comunità potrebbe giovare alla funzionalità stessa.
In GitLab 11.9 abbiamo , rendendolo così disponibile gratuitamente per l'uso in GitLab Core autogestito e su GitLab.com, ed aperto alla comunità.
E molto altro!
In questo rilascio ci sono così tante fantastiche funzionalità: ad esempio, , e , - che non vediamo l'ora di raccontarvi!
Il dipendente più prezioso () di questo mese è stato riconosciuto come Marcel Amirault ()
Marcel ci ha costantemente aiutato a migliorare la documentazione di GitLab. Lui per migliorare la qualità e la facilità d'uso dei nostri documenti. Domo arigato [grazie mille (giap.) — nt.] Marcel, lo apprezziamo sinceramente!
Funzionalità principali aggiunte nel rilascio di GitLab 11.9
Rilevamento di segreti e credenziali nel repository
(ULTIMATE, GOLD)
A volte gli sviluppatori trasferiscono involontariamente segreti e credenziali nei repository remoti. Se altre persone hanno accesso a questa sorgente, oppure se il progetto è aperto, le informazioni riservate vengono esposte e possono essere utilizzate da malintenzionati per accedere a risorse come gli ambienti di distribuzione.
GitLab 11.9 ha un nuovo test — “Rilevazione di Segreti”. Scansiona il contenuto del repository alla ricerca di chiavi API e altre informazioni che non dovrebbero trovarsi qui. GitLab mostra i risultati nel report SAST nel widget della merge request, nei report dei pipeline e nei cruscotti di sicurezza.
Se hai già collegato SAST per la tua applicazione, non devi fare nulla, basta sfruttare i vantaggi di questa nuova funzionalità. È anche inclusa nella configurazione per impostazione predefinita.
Regole per le merge request
(PREMIUM, ULTIMATE, SILVER, GOLD)
La revisione del codice è un elemento imprescindibile di ogni progetto di successo, ma non è sempre chiaro chi debba occuparsi della revisione delle modifiche. Spesso è auspicabile la partecipazione di revisori provenienti da team diversi: il team di sviluppo, il team di interazione con gli utenti, il team di produzione.
Le regole di approvazione consentono di migliorare il processo di interazione tra le persone coinvolte nella revisione del codice: viene definito il gruppo di soggetti autorizzati e il numero minimo di approvazioni. Le regole di approvazione vengono visualizzate nel widget della richiesta di unione, permettendo di nominare rapidamente il prossimo revisore.
In GitLab 11.8 le regole di approvazione erano disattivate per impostazione predefinita. A partire dalla versione GitLab 11.9 sono disponibili di default. In GitLab 11.3 abbiamo introdotto l'opzione per identificare i membri del team responsabili di specifici codici all'interno del progetto. La funzione Code Owners è integrata nelle regole di approvazione, permettendo di trovare rapidamente le persone giuste per rivedere le modifiche.
Trasferimento di ChatOps in Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Introdotto originariamente in GitLab Ultimate 10.6, ChatOps è migrato in GitLab Core. GitLab ChatOps offre la possibilità di avviare job di GitLab CI tramite Slack utilizzando la funzionalità .
Stiamo aprendo il codice sorgente di questa funzionalità in conformità con il nostro . Utilizzandola frequentemente, la comunità contribuirà maggiormente.
Audit delle configurazioni delle funzionalità
(PREMIUM, ULTIMATE, SILVER, GOLD)
Operazioni come l'aggiunta, la rimozione o la modifica dei parametri delle funzionalità vengono ora registrate nel registro delle audit di GitLab, consentendo di vedere cosa e quando è stato modificato. Hai subito un incidente e devi verificare cosa è cambiato di recente? O hai solo bisogno di controllare come sono stati modificati i parametri delle funzionalità durante un audit? Ora è molto facile farlo.
Eliminazione delle vulnerabilità nelle merge request
(ULTIMATE, GOLD)
Per affrontare rapidamente le vulnerabilità del codice, il processo deve essere semplice. È importante semplificare le correzioni di sicurezza per consentire agli sviluppatori di concentrarsi sui compiti principali. In GitLab 11.7 abbiamo , ma doveva essere caricato, applicato localmente e poi le modifiche dovevano essere trasferite nel repository remoto.
In GitLab 11.9 questo processo è automatizzato. Risolvi le vulnerabilità direttamente dall'interfaccia web di GitLab. La richiesta di merge viene creata direttamente dalla finestra delle informazioni sulle vulnerabilità, e questo nuovo ramo conterrà già la correzione. Dopo aver verificato se il problema è risolto, aggiungi la correzione al ramo originale, se il pipeline è a posto.
Visualizzazione dei risultati della scansione dei contenitori nel pannello di sicurezza del gruppo
(ULTIMATE, GOLD)
Il pannello di sicurezza del gruppo consente agli specialisti di concentrarsi sulle questioni più importanti per il lavoro, fornendo una panoramica chiara e dettagliata di tutte le possibili vulnerabilità che potrebbero influenzare le applicazioni. Ecco perché è importante che il pannello contenga tutte le informazioni necessarie in un unico posto, consentendo agli utenti di esaminare i dati in dettaglio prima di risolvere le vulnerabilità.
In GitLab 11.9 i risultati della scansione del contenitore sono stati aggiunti alla dashboard, oltre a quelli già esistenti di SAST e dei risultati della scansione delle dipendenze. Ora tutta la panoramica è in un unico posto, indipendentemente dalla fonte del problema.
Modelli CI/CD per i lavori di sicurezza
(ULTIMATE, GOLD)
Le funzionalità di sicurezza di GitLab si evolvono rapidamente e richiedono aggiornamenti costanti per mantenere l'efficacia e la protezione del codice. Modificare la definizione di un job è difficile quando gestisci più progetti. E sappiamo anche: nessuno vuole rischiare di utilizzare l'ultima versione di GitLab senza avere la certezza della sua completa compatibilità con l'istanza attuale di GitLab.
È proprio per questa ragione che abbiamo introdotto in GitLab 11.7 un nuovo meccanismo di definizione dei job utilizzando .
A partire da GitLab 11.9 offriremo template integrati per tutti i jobs di sicurezza: ad esempio, sast e dependency_scanning, compatibili con la versione di GitLab corrispondente.
Includili direttamente nella tua configurazione e verranno aggiornati insieme al sistema ad ogni aggiornamento alla nuova versione di GitLab. Le configurazioni del pipeline, nel frattempo, non cambiano.
Il nuovo modo di definire i jobs di sicurezza è ufficiale e non supporta altre precedenti definizioni di job o frammenti di codice. È necessario aggiornare la definizione il prima possibile per utilizzare la nuova parola chiave
template. Il supporto per qualsiasi altro syntax potrebbe essere rimosso in GitLab 12.0 o in altre future versioni.
Altri miglioramenti in GitLab 11.9
Risposta al commento
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab ci sono discussioni sui temi. Finora l'utente che scrive il commento iniziale doveva decidere fin dall'inizio se aveva bisogno di una discussione.
Abbiamo allentato questa restrizione. Prendi qualsiasi commento in GitLab (su task, merge request ed epic) e rispondi a esso, avviando così la discussione. Questo rende l'interazione delle squadre più organizzata.
Modelli di progetto per .NET, Go, iOS e Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Per semplificare la creazione di nuovi progetti da parte degli utenti, offriamo diversi nuovi modelli di progetto:
- Iniziale , che include un'applicazione di base con CI.
- Modello pronto all'uso che combina e GitLab CI/CD.
- , pronta per una personalizzazione iniziale in GitLab. Tieni presente che, poiché è necessario un runner MacOS dedicato per compilare iOS, dovrai fornire un tuo server di compilazione, se desideri utilizzarlo con GitLab CI/CD.
- sono configurati per lavorare con Netlify.
Richiedi l'approvazione delle merge request dai Code Owners
(PREMIUM, ULTIMATE, SILVER, GOLD)
Non è sempre chiaro chi approva la merge request.
Ora GitLab supporta la richiesta di approvazione delle merge request, a seconda dei file che la richiesta modifica, tramite . I Code Owners vengono assegnati tramite un file chiamato CODEOWNERS, il cui formato è simile a gitattributes.
Il supporto per l'assegnazione automatica dei Code Owners come responsabili dell'approvazione delle merge request è stato aggiunto in .
Spostamento di file in Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ora, rinominando un file o una cartella, è possibile spostarli dal Web IDE al repository in un nuovo percorso.
Etichette in ordine alfabetico
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Le etichette di GitLab sono incredibilmente versatili e i team trovano costantemente nuovi modi per utilizzarle. Di conseguenza, gli utenti spesso aggiungono molte etichette a task, merge request o epic.
In GitLab 11.9 abbiamo semplificato l'uso delle etichette. Nei task, merge request ed epic, le etichette visualizzate nella barra laterale sono ordinate alfabeticamente. Questo vale anche per la visualizzazione dell'elenco di questi oggetti.
Commenti rapidi durante il filtraggio delle azioni per task
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recentemente abbiamo introdotto una funzionalità che consente agli utenti di filtrare il feed delle attività in base a compiti, merge request o epic, permettendo di concentrarsi solo sui commenti o sulle note di sistema. Questa impostazione viene salvata per ogni utente nel sistema, e può capitare che l'utente non si renda conto che, visualizzando un compito dopo qualche giorno, stia vedendo un feed filtrato. Potrebbe sembrare che non sia possibile lasciare un commento.
Abbiamo migliorato questa interazione. Ora gli utenti possono passare rapidamente a una modalità che consente di lasciare commenti senza dover scorrere di nuovo fino in cima al feed. Questo riguarda compiti, merge request ed epic.
Modifica dell'ordine degli epic figli
(ULTIMATE, GOLD)
Recentemente abbiamo rilasciato , che consentono di utilizzare epic di epic (oltre ai compiti figli degli epic).
Ora è possibile modificare l'ordine degli epic figli tramite semplice trascinamento, come nel caso dei compiti figli. I team possono utilizzare l'ordine per riflettere le priorità o stabilire l'ordine di esecuzione delle attività.
Messaggi di sistema personalizzati per intestazioni e piè di pagina su internet ed e-mail
(CORE, STARTER, PREMIUM, ULTIMATE)
In precedenza, abbiamo aggiunto una funzionalità che consente ai messaggi di intestazione e piè di pagina personalizzati di apparire su ogni pagina in GitLab. È stata accolta calorosamente, e i team la utilizzano per condividere informazioni importanti: ad esempio, messaggi di sistema legati alla loro istanza di GitLab.
Siamo lieti di introdurre questa funzionalità in Core, così ora può essere utilizzata da ancora più persone. Inoltre, consentiamo agli utenti di visualizzare, se lo desiderano, gli stessi messaggi in tutte le e-mail inviate tramite GitLab, per una coerenza con un altro punto di contatto dell'utente con GitLab.
Filtro per compiti riservati
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
I compiti riservati sono uno strumento utile per i team, consentendo discussioni riservate su argomenti delicati all'interno di un progetto aperto. In particolare, sono perfetti per lavorare sulle vulnerabilità di sicurezza. Fino ad ora, gestire i compiti riservati non è stato molto facile.
In GitLab 11.9, l'elenco delle attività di GitLab è ora filtrato per attività riservate o non riservate. Questo vale anche per la ricerca delle attività tramite l'API.
Grazie per il contributo di Robert Schilling ()!
Modifica del dominio Knative dopo il deployment
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Specificare un dominio personalizzato durante l'installazione di Knative consente di gestire diverse applicazioni/funzioni serverless con un endpoint unico.
Ora l'integrazione di Kubernetes in GitLab consente di modificare/aggiornare un dominio personalizzato dopo il deployment di Knative nel cluster Kubernetes.
Verifica del formato del certificato CA di Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Quando si aggiunge un cluster Kubernetes esistente, GitLab verifica ora che il certificato CA fornito sia nel formato PEM valido. Questo elimina possibili errori con l'integrazione di Kubernetes.
Estensione dello strumento di confronto delle merge request a tutto il file
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Esaminando le modifiche nella merge request, ora è possibile espandere lo strumento di confronto per ogni file, per mostrare l'intero file fornendo un contesto maggiore e per lasciare commenti sulle righe non modificate.
Esecuzione di lavori specifici per le merge request solo in caso di modifica di determinati file
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 11.6 è stata introdotta la possibilità di definire per i lavori nei pipeline, affinché gli utenti possano eseguire compiti specifici solo alla creazione di una merge request.
Ora stiamo ampliando questa funzionalità: è stata aggiunta la logica di collegamento , e gli utenti possono eseguire lavori specifici solo per le merge request e solo in caso di modifica di determinati file.
Grazie per il contributo di Hiroyuki Sato ()!
Monitoraggio automatico di GitLab con Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana è ora inclusa nel nostro pacchetto Omnibus, semplificando la comprensione del funzionamento della tua istanza.
Configura grafana['enable'] = true in gitlab.rb, e Grafana sarà disponibile all'indirizzo: https://your.gitlab.instance/-/grafana. Nel prossimo futuro, introdurremo anche «out of the box».
Visualizzazione degli epics principali nella barra laterale degli epics
(ULTIMATE, GOLD)
Di recente abbiamo presentato , che consente di utilizzare epics di epics.
In GitLab 11.9 abbiamo semplificato il meccanismo per visualizzare questa relazione. Ora è visibile non solo l'epic madre di un dato epic, ma anche l'intero albero degli epics nella barra laterale a destra. È possibile vedere se questi epics sono chiusi o meno e si può anche accedere direttamente ad essi.
Collegamento a un nuovo problema da un problema spostato e chiuso
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab è facile spostare un'attività in un altro progetto utilizzando la barra laterale o un'azione rapida. In background, l'attività esistente viene chiusa e nel progetto di destinazione viene creata una nuova attività con tutti i dati copiati, incluse le note di sistema e gli attributi della barra laterale. È una funzionalità eccellente.
Considerando che c'è una nota di sistema sullo spostamento, gli utenti, quando visualizzano un'attività chiusa, si sentono confusi: non possono non comprendere che l'attività è stata chiusa per il motivo dello spostamento.
In questa versione, indichiamo direttamente sull'icona in alto della pagina dell'attività chiusa che è stata spostata, e includiamo un link integrato alla nuova attività, in modo che chiunque visiti quella vecchia possa passare rapidamente a quella nuova.
Integrazione YouTrack
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab si integra con molti sistemi esterni di tracciamento delle attività, rendendo più facile per i team utilizzare GitLab per altre funzioni, mantenendo però lo strumento di gestione delle attività scelto.
In questa versione, abbiamo aggiunto la possibilità di integrazione con YouTrack di JetBrains.
Grazie per il contributo di Kotau Yauhen ()!
Ridimensionamento dell'albero dei file della merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Durante la visualizzazione delle modifiche alla merge request, ora è possibile ridimensionare l'albero dei file per visualizzare nomi di file lunghi o risparmiare spazio su schermi piccoli.
Passaggio ai pannelli delle attività più recenti
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
I pannelli delle attività sono molto utili e i team creano più pannelli per ciascun progetto e gruppo. Di recente, abbiamo aggiunto un pannello di ricerca per filtrare rapidamente tutti i pannelli di tuo interesse.
In GitLab 11.9 abbiamo anche introdotto la sezione Recent nel menu a discesa. In questo modo, puoi passare rapidamente ai pannelli con cui hai interagito di recente.
Possibilità per gli sviluppatori di creare rami protetti
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
I rami protetti non consentono di spostare o unire codice non revisionato. Tuttavia, se a nessuno è permesso di spostare rami protetti, nessuno può creare un nuovo ramo protetto: ad esempio, un ramo di rilascio.
In GitLab 11.9 gli sviluppatori possono creare rami protetti da rami già protetti tramite GitLab o API. L'uso di Git per spostare un nuovo ramo protetto è ancora limitato, per evitare di creare accidentalmente nuovi rami protetti.
Deduplicazione degli oggetti Git per rami aperti (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Il branching consente a chiunque di partecipare a progetti open source: senza autorizzazione per la scrittura, copiando semplicemente il repository in un nuovo progetto. Mantenere copie complete di repository Git frequentemente ramificati è inefficiente. Ora, con Git alternative i rami condividono oggetti comuni dal progetto principale nel pool di oggetti, per ridurre i requisiti di archiviazione su disco.
I pool di oggetti per i rami vengono creati solo per progetti aperti, se è connesso uno storage hashato. I pool di oggetti vengono abilitati tramite il parametro della funzione object_pools.
Filtraggio dell'elenco delle merge request per gli approvatori assegnati
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
La revisione del codice è una pratica comune per ogni progetto di successo, ma i revisori possono avere difficoltà a tenere traccia delle merge request.
In GitLab 11.9, l'elenco delle merge request è filtrato per l'approvatore assegnato. In questo modo, puoi trovare le merge request assegnate a te come revisore.
Ringraziamo per il contributo di Glavin Wiechert ()!
Scorciatoie da tastiera per il file successivo e precedente nella merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Durante la revisione delle modifiche in una merge request, puoi passare rapidamente tra i file utilizzando ]o j per andare al file successivo e [ o k per tornare al file precedente.
Semplificazione .gitlab-ci.yml per progetti serverless
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Creato sulla base delle funzionalità GitLab CI, modello serverless gitlab-ci.yml notevolmente semplificato. Per introdurre nuove funzionalità nelle future versioni, non è necessario apportare modifiche a questo file.
Supporto per i nomi host Ingress
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Durante il deployment del controller Kubernetes Ingress, alcune piattaforme tornano all'indirizzo IP (ad esempio, GKE di Google), mentre altre tornano al nome DNS (ad esempio, EKS di AWS).
La nostra integrazione Kubernetes ora supporta entrambi i tipi di endpoint da visualizzare nella sezione clusters del progetto.
Ringraziamo per il contributo di Aaron Walker ()!
Restrizione dell'accesso all'accesso a JupyterHub solo per membri del gruppo/progetto
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Deployare JupyterHub utilizzando l'integrazione di GitLab con Kubernetes è un ottimo modo per mantenere e utilizzare Jupyter Notebook in grandi gruppi. È anche utile controllare l'accesso a questi quando si trattano dati riservati o personali.
In GitLab 11.9, l'accesso alle istanze di JupyterHub distribuite tramite Kubernetes è limitato ai membri del progetto con livello di accesso "sviluppatore" (tramite gruppo o progetto).
Intervalli temporali personalizzabili per gli schemi del pannello di sicurezza
(ULTIMATE, GOLD)
Il pannello di sicurezza del gruppo include uno schema delle vulnerabilità per visualizzare lo stato attuale della sicurezza dei progetti del gruppo. Questo è molto utile per i direttori della sicurezza per impostare processi e comprendere il funzionamento del team.
In GitLab 11.9 è ora possibile selezionare l'intervallo temporale di questo schema delle vulnerabilità. Di default sono gli ultimi 90 giorni, ma è possibile impostare un intervallo di 60 o 30 giorni, a seconda del livello di dettaglio necessario.
Questo non influisce sui dati nei contatori o nell'elenco, solo sui punti dati visualizzati nello schema.
Aggiunta di un lavoro di build Auto DevOps per i tag
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Il passaggio alla build automatica di Auto DevOps crea una build della tua applicazione, utilizzando il Dockerfile del progetto o il pacchetto di build di Heroku.
In GitLab 11.9, l'immagine Docker ottenuta, incorporata nel pipeline dei tag, riceve un nome simile ai tradizionali nomi delle immagini utilizzando il tag del commit invece dell'SHA del commit.
Grazie per il contributo di Aaron Walker!
Aggiornamento di Code Climate alla versione 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab utilizza per verificare come le modifiche influenzano lo stato del tuo codice e del progetto.
In GitLab 11.9 abbiamo aggiornato il motore all'ultima versione (), per fornire vantaggi di ulteriore linguaggio e supporto per l'analisi statica della Qualità del Codice di GitLab.
Grazie per il contributo del membro del team GitLab Core Takuya Noguti ()!
Ridimensionamento e scorrimento del pannello delle metriche
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Quando esplora anomalie nelle prestazioni, è spesso utile dare un'occhiata più da vicino a parti singole di una specifica metrica.
Con GitLab 11.9, gli utenti potranno ridimensionare singoli intervalli temporali nel pannello delle metriche, scorere l'intero intervallo di tempo e tornare facilmente alla vista dell'intervallo di tempo originale. Questo rende facile e veloce esaminare gli eventi rilevanti.
SAST per TypeScript
(ULTIMATE, GOLD)
è un linguaggio di programmazione relativamente nuovo basato su .
In GitLab 11.9, la funzionalità di Static Application Security Testing (SAST) analizza e rileva le vulnerabilità nel codice TypeScript, mostrandole nel widget della merge request, a livello di pipeline e nel pannello di sicurezza. L'attuale definizione del job sast non deve essere modificata e viene inoltre attivata automaticamente in .
SAST per progetti Maven multiprogetto
(ULTIMATE, GOLD)
I progetti Maven sono spesso organizzati per unire in un unico repository. In passato, GitLab non era in grado di scansionare correttamente tali progetti, e gli sviluppatori e gli esperti di sicurezza non ricevevano report sulle vulnerabilità.
GitLab 11.9 offre supporto avanzato per la funzione SAST per questa specifica configurazione del progetto, garantendo la possibilità di testare le vulnerabilità nello stato sorgente. Grazie alla flessibilità degli analizzatori, la configurazione viene definita automaticamente e non è necessario apportare modifiche per visualizzare i risultati per le applicazioni Maven multiprogetto. Come al solito, miglioramenti simili sono disponibili anche con .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Oggi abbiamo anche rilasciato GitLab Runner 11.9! GitLab Runner è un progetto open source e viene utilizzato per eseguire job CI/CD e inviare i risultati a GitLab.
Di seguito sono riportate alcune modifiche in GitLab Runner 11.9:
- .
- e .
- . Ciò esclude anche .
- per supportare , che appariranno in GitLab 11.10.
- .
- .
- Spostamento di diversi script — incluso e — in Go.
- .
- .
- .
L'elenco completo delle modifiche è disponibile nel changelog di GitLab Runner: .
Miglioramenti per lo schema di GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
Nel chart di GitLab sono stati apportati i seguenti miglioramenti:
- Aggiunta del supporto per Google Cloud Memorystore.
- Le impostazioni del Cron job , poiché vengono utilizzate da più servizi.
- Il registro è stato aggiornato alla versione 2.7.1.
- È stato aggiunto un nuovo parametro che garantisce la compatibilità del registro GitLab con le versioni di Docker fino alla 1.10. Per attivarlo, impostare
registry.compatibility.schema1.enabled: true.
Miglioramento delle prestazioni
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Continuiamo a migliorare le prestazioni di GitLab con ogni rilascio per istanze di GitLab di qualsiasi dimensione. Ecco alcuni miglioramenti in GitLab 11.9:
- .
- .
- .
- .
Miglioramenti di Omnibus
(CORE, STARTER, PREMIUM, ULTIMATE)
In GitLab 11.9 sono stati apportati i seguenti miglioramenti a Omnibus:
- GitLab 11.9 include , , nel cui ultimo rilascio sono inclusi MFA per Team Edition, aumento delle prestazioni delle immagini e molto altro. Questa versione include anche ; si raccomanda l'aggiornamento.
- È stato aggiunto un nuovo parametro che garantisce la compatibilità del registro GitLab con le versioni di Docker fino alla 1.10. Per attivarlo, impostare
registry['compatibility_schema1_enabled'] = true in gitlab.rb. - Il registro di GitLab ora esporta metriche Prometheus e viene monitorato automaticamente dal .
- È stata aggiunta la supporto per Google Cloud Memorystore, che richiede .
opensslaggiornato alla versione 1.0.2r,nginx— alla versione 1.14.2,python— alla versione 3.4.9,jemalloc— alla versione 5.1.0,docutils— alla versione 0.13.1,gitlab-monitor— alla versione 3.2.0.
Funzionalità deprecate
GitLab Geo fornirà lo storage hashato in GitLab 12.0
GitLab Geo è richiesto per mitigare le condizioni di competizione (race condition) sui nodi secondari. Questo è stato segnalato in .
In GitLab abbiamo aggiunto questo requisito nella documentazione Geo: .
In GitLab sudo gitlab-rake gitlab: geo: check controlla se lo storage hashato è abilitato e se tutti i progetti sono trasferiti. Vedi. . Se utilizzi Geo, ti preghiamo di eseguire questa verifica e di migrare il prima possibile.
In GitLab avviso disabilitabile permanente verrà visualizzato nella pagina Area Admin › Geo › Nodi, se le verifiche sopra menzionate non sono autorizzate.
In GitLab Geo utilizzerà i requisiti per lo storage hashato. Vedi. .
Data di rimozione: 22 giugno 2019
Integrazione Hipchat
Hipchat . Inoltre, nella versione 11.9 .
Data di rimozione: 22 marzo 2019.
Supporto CentOS 6 per GitLab Runner con l'esecutore Docker
GitLab Runner non supporta CentOS 6 quando si utilizza Docker in GitLab 11.9. Questo è il risultato dell'aggiornamento della libreria di base di Docker, che non supporta più CentOS 6. Per maggiori dettagli, vedere .
Data di rimozione: 22 marzo 2019.
Percorsi legacy obsoleti del codice GitLab Runner
A partire da GitLab 11.9, GitLab Runner utilizza clonazione/chiamata del repository. Attualmente, GitLab Runner utilizzerà il vecchio metodo se il nuovo non è supportato.
In GitLab 11.0 abbiamo modificato l'aspetto della configurazione del server delle metriche per GitLab Runner. metrics_server sarà rimosso a favore di listen_address in GitLab 12.0. Ulteriori dettagli possono essere trovati in . E ulteriori dettagli in .
Nella versione 11.3, GitLab Runner ha iniziato a supportare , che ha portato a nuove impostazioni per . In è stata fornita una tabella delle modifiche e istruzioni per passare alla nuova configurazione. Per maggiori dettagli, vedere .
Questi percorsi non sono più disponibili in GitLab 12.0. Come utente, non è necessario modificare nulla, basta assicurarsi che l'istanza di GitLab funzioni con la versione 11.9+ durante l'aggiornamento a GitLab Runner 12.0.
Data di rimozione: 22 giugno 2019
Parametro obsoleto per la funzione del punto di ingresso per GitLab Runner
In 11.4, GitLab Runner ha introdotto il parametro della funzione per risolvere problemi come e .
In GitLab 12.0 ci sposteremo su un comportamento corretto, come se il parametro della funzione fosse disabilitato. Ulteriori dettagli possono essere trovati in .
Data di rimozione: 22 giugno 2019
Supporto obsoleto per distribuzioni Linux che hanno raggiunto l'EOL per GitLab Runner
Alcune distribuzioni Linux, in cui è possibile installare GitLab Runner, hanno terminato il loro ciclo di vita.
In GitLab 12.0, GitLab Runner non distribuirà più pacchetti a tali distribuzioni Linux. L'elenco completo delle distribuzioni non più supportate può essere trovato nel nostro . Grazie a Javier Ardo () per il suo !
Data di rimozione: 22 giugno 2019
Rimozione dei comandi obsoleti di GitLab Runner Helper
Come parte degli sforzi per supportare è stato necessario rinunciare ad alcuni comandi obsoleti utilizzati per .
In GitLab 12.0, GitLab Runner viene avviato con nuovi comandi. Questo riguarda solo gli utenti che sovrascrivono . Ulteriori dettagli possono essere trovati in .
Data di rimozione: 22 giugno 2019
Gli sviluppatori possono eliminare i tag Git in GitLab 11.10
L'eliminazione o la modifica delle note di rilascio per i tag Git in rami non protetti è storicamente limitata solo a .
Poiché gli sviluppatori possono aggiungere tag e modificare o eliminare rami non protetti, devono avere la possibilità di eliminare i tag Git. In GitLab 11.10 al nostro modello di autorizzazioni per migliorare il flusso di lavoro e aiutare gli sviluppatori a utilizzare i tag in modo migliore ed efficiente.
Se desideri mantenere questa limitazione per collaboratori e proprietari, usa .
Data di rimozione: 22 aprile 2019
Supporto per Prometheus 1.x in Omnibus GitLab
A partire da GitLab , la versione integrata di Prometheus 1.0 è esclusa da Omnibus GitLab. . Tuttavia, il formato delle metriche non è compatibile con la versione 1.0. Le versioni esistenti possono essere aggiornate a 2.0 e, se necessario, trasferire i dati .
In GitLab versione verrà automaticamente installato Prometheus 2.0, se non è stato già aggiornato. I dati da Prometheus 1.0 andranno persi poiché non vengono trasferiti.
Data di rimozione: 22 giugno 2019
TLS v1.1
A partire da GitLab per migliorare la sicurezza. Ciò risolve numerosi problemi, incluso Heartbleed, e rende GitLab compatibile "out of the box" con lo standard PCI DSS 3.1.
Per disabilitare immediatamente TLS v1.1, impostare nginx['ssl_protocols'] = "TLSv1.2" in gitlab.rband e eseguire gitlab-ctl reconfigure.
Data di rimozione: 22 giugno 2019
Modello OpenShift per l'installazione di GitLab
Ufficiale — è il metodo raccomandato per eseguire GitLab su Kubernetes, incluso .
per l'installazione di GitLab è obsoleto e non sarà più supportato in .
Data di rimozione: 22 giugno 2019
Definizioni precedenti dei lavori di sicurezza
Con l'introduzione di tutte le precedenti definizioni dei lavori verranno obsolete e verranno rimosse in GitLab 12.0 o successivamente.
Aggiorna le definizioni dei lavori per utilizzare la nuova sintassi e sfruttare tutte le nuove funzionalità di sicurezza fornite da GitLab.
Data di rimozione: 22 giugno 2019
Sezione Informazioni di Sistema nel pannello di amministrazione
GitLab fornisce informazioni sulla tua istanza di GitLab in admin/system_info, ma queste informazioni potrebbero non essere accurate.
Noi del pannello di amministrazione in GitLab 12.0 e raccomandiamo di utilizzare .
Data di rimozione: 22 giugno 2019
Fonte: habr.com
