Rilevamento rapido delle perdite di segreti
Sembra un errore da poco: condividere accidentalmente le credenziali in un repository pubblico. Eppure, le conseguenze possono essere gravi. Non appena un malintenzionato ottiene la tua password o la tua API key, prenderà il controllo del tuo account, ti bloccherà e utilizzerà ingannevolmente i tuoi fondi. Inoltre, c'è il rischio dell'effetto domino: l'accesso a un account apre le porte ad altri. Le conseguenze sono elevate, quindi è fondamentale scoprire al più presto le perdite di segreti.
In questa versione introduciamo l'opzione nell'ambito della nostra funzionalità SAST. Ogni commit viene scansionato nel job CI/CD per la ricerca di segreti. Se viene trovato un segreto, il sviluppatore riceve un avviso nella merge request. Può immediatamente revocare le credenziali compromesse e crearne di nuove.
Assicurare una corretta gestione delle modifiche
Con l'aumento della complessità, diventa sempre più difficile mantenere la coerenza tra le diverse parti dell'organizzazione. Maggiore è il numero di utenti dell'applicazione e più alti sono i ricavi, maggiore è l'impatto di un merge di codice errato o non sicuro. Per molte organizzazioni, garantire un processo di revisione corretto prima del merge del codice è un requisito fondamentale, poiché i rischi sono molto elevati.
Con GitLab 11.9, più controllo e una struttura più efficace — grazie a . In passato, per ottenere un'approvazione, era sufficiente indicare una persona o un gruppo (ogni membro del quale poteva concedere l'approvazione). Ora è possibile aggiungere più regole affinché la merge request richieda l'approvazione da persone specifiche o addirittura da più membri di un gruppo specifico. Inoltre, nelle regole di approvazione è integrata la funzione Code Owners, che consente di identificare facilmente la persona che ha fornito l'approvazione.
Questo consente alle organizzazioni di implementare processi complessi di risoluzione, mantenendo al contempo la semplicità di un'unica applicazione GitLab, dove compiti, codice, pipeline e dati di monitoraggio sono visibili e accessibili per prendere decisioni e accelerare il processo di risoluzione.
ChatOps è ora open source
GitLab ChatOps è uno strumento di automazione efficace che consente di eseguire qualsiasi job CI/CD e di richiederne lo stato direttamente in chat come Slack e Mattermost. , ChatOps era parte dell'abbonamento GitLab Ultimate. In base alla 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 stessa funzionalità.
Con GitLab 11.9 abbiamo , quindi ora è 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à: per esempio, , e , — non vediamo l'ora di parlarne!
L'impiegato più valorizzato di questo mese è stato Marcel Amirault(di questo mese))
Marcel ha costantemente contribuito a migliorare la documentazione di GitLab. Ha per aumentare la qualità e l'usabilità dei nostri documenti. Domo arigato [grazie mille (giap.) — n.d.t.] Marcel, lo apprezziamo sinceramente!
Funzionalità principali aggiunte nella release di GitLab 11.9
Rilevamento di segreti e credenziali nel repository
(ULTIMATE, GOLD)
Gli sviluppatori a volte trasmettono senza volerlo segreti e credenziali nei repository remoti. Se altre persone hanno accesso a questa fonte, o se il progetto è pubblico, le informazioni riservate vengono esposte e possono essere utilizzate dai malintenzionati per accedere a risorse come gli ambienti di distribuzione.
GitLab 11.9 introduce un nuovo test — “Secret Detection”. Scansione il contenuto del repository alla ricerca di chiavi API e altre informazioni che non dovrebbero trovarsi qui. GitLab visualizza i risultati in un rapporto SAST nel widget della merge request, nei rapporti dei pipeline e nei pannelli di sicurezza.
Se hai già attivato SAST per la tua applicazione, non devi fare nulla, basta usufruire dei vantaggi di questa nuova funzionalità. È già inclusa nella configurazione per impostazione predefinita.
Regole di approvazione delle merge request
(PREMIUM, ULTIMATE, SILVER, GOLD)
La revisione del codice è un elemento fondamentale di ogni progetto di successo, ma non è sempre chiaro chi debba occuparsi della revisione delle modifiche. Spesso è auspicabile il coinvolgimento di revisori provenienti da team diversi: team di sviluppo, team interfaccia utenti, team di produzione.
Le regole di approvazione migliorano il processo di interazione tra le persone coinvolte nella revisione del codice: definiscono il gruppo di approvatori autorizzati e il numero minimo di approvazioni. Le regole di approvazione sono visualizzate nel widget della merge request, consentendo di designare 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 per impostazione predefinita. In GitLab 11.3 abbiamo introdotto l'opzione per identificare i membri del team responsabili dei singoli codici all'interno del progetto. La funzione Code Owners è integrata nelle regole di risoluzione, consentendo di trovare rapidamente le persone giuste per rivedere le modifiche.
Spostamento di ChatOps in Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Introdotto inizialmente in GitLab Ultimate 10.6, ChatOps è ora parte di GitLab Core. GitLab ChatOps offre la possibilità di eseguire attività GitLab CI tramite Slack utilizzando la funzione .
Rilasciamo il codice sorgente di questa funzione in conformità con il nostro . Utilizzandola con maggiore frequenza, la comunità potrà contribuire di più.
Audit delle opzioni delle funzionalità
(PREMIUM, ULTIMATE, SILVER, GOLD)
Operazioni come l'aggiunta, la rimozione o la modifica dei parametri delle funzioni vengono ora registrate nel registro delle attività di GitLab, permettendo di vedere cosa è stato cambiato e quando. È successo un incidente e vuoi controllare cosa è cambiato di recente? Oppure hai semplicemente bisogno di controllare come sono stati modificati i parametri delle funzioni durante un audit? Ora è molto semplice farlo.
Rimozione delle vulnerabilità delle merge request
(ULTIMATE, GOLD)
Per risolvere rapidamente le vulnerabilità del codice, il processo deve essere semplice. È fondamentale semplificare le correzioni di sicurezza, permettendo agli sviluppatori di concentrarsi sui propri compiti diretti. In GitLab 11.7 abbiamo , ma doveva essere scaricato, applicato a livello locale e poi trasferito nel repository remoto.
In GitLab 11.9 questo processo è stato automatizzato. Risolvete le vulnerabilità senza uscire 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 che il problema sia stato risolto, aggiungete la correzione al ramo principale, se il pipeline è a posto.
Visualizzazione dei risultati della scansione dei container nella dashboard 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à in grado di influenzare le applicazioni. Ecco perché è fondamentale che il pannello contenga tutte le informazioni necessarie in un unico luogo e permetta agli utenti di esaminare i dati prima di affrontare le vulnerabilità.
In GitLab 11.9, i risultati della scansione dei container sono stati aggiunti al cruscotto, oltre ai già esistenti risultati SAST e alla 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 molto rapidamente e richiedono costantemente aggiornamenti per mantenere l'efficacia e la protezione del codice. Cambiare la definizione di un job è complicato quando si gestiscono più progetti. E comprendiamo anche che nessuno desidera rischiare l'uso dell'ultima versione di GitLab senza la certezza della sua piena compatibilità con l'istanza attuale di GitLab.
Proprio per questo motivo abbiamo introdotto in GitLab 11.7 un nuovo meccanismo di definizione dei job con .
A partire da GitLab 11.9, offriremo modelli integrati per tutti i lavori di sicurezza: ad esempio, sast e dependency_scanning, compatibili con la versione corrispondente di GitLab.
Includili direttamente nella tua configurazione e si aggiorneranno con il sistema ad ogni aggiornamento a una nuova versione di GitLab. Le configurazioni del pipeline non cambiano.
Il nuovo modo di definire i lavori di sicurezza è ufficiale e non supporta alcuna altra definizione precedente dei lavori o frammenti di codice. È necessario aggiornare quanto prima la definizione per utilizzare la nuova parola chiave
template. Il supporto per qualsiasi altra sintassi 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 scriveva il commento iniziale doveva decidere in anticipo se necessitava di una discussione.
Abbiamo allentato questa limitazione. Prendi qualsiasi commento in GitLab (su task, merge request e epic) e rispondi ad esso, avviando così la discussione. In questo modo i team interagiscono in modo più organizzato.
Modelli di progetto per .NET, Go, iOS e Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Per semplificare la creazione di nuovi progetti per gli utenti, offriamo diversi nuovi modelli di progetto:
- Iniziale , che include un'applicazione di base con CI.
- Un 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 la compilazione iOS, dovrai fornire il tuo server di costruzione se desideri usarlo con GitLab CI/CD.
- sono configurati per funzionare con Netlify.
Richiedi l'approvazione delle merge request dai Code Owners
(PREMIUM, ULTIMATE, SILVER, GOLD)
Non è sempre ovvio chi approva una merge request.
Ora GitLab supporta la richiesta di approvazione della merge request, a seconda dei file che la richiesta modifica, tramite . I Code Owners vengono designati tramite un file chiamato CODEOWNERS, il cui formato è simile a gitattributes.
Il supporto per l'attribuzione automatica dei Code Owners come responsabili per l'approvazione della merge request è stato aggiunto già in .
Spostamento di file in Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ora, rinominando un file o una cartella, è possibile spostarlo da Web IDE al repository nel nuovo percorso.
Etichette in ordine alfabetico
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Le etichette di GitLab sono incredibilmente versatili e i team le trovano sempre nuove applicazioni. Di conseguenza, gli utenti aggiungono spesso molte etichette a un problema, a una merge request o a un'epica.
Con GitLab 11.9 abbiamo semplificato un po' l'uso delle etichette. Negli issue, nelle merge request e nelle epiche, le etichette visualizzate nella barra laterale sono ora disposte in ordine alfabetico. Questo vale anche per la visualizzazione dell'elenco di questi oggetti.
Commenti rapidi filtrando le attività per issue
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Recentemente abbiamo introdotto una funzionalità che consente agli utenti di filtrare il feed delle attività per issue, merge request o epiche, permettendo di concentrarsi solo sui commenti o sulle note di sistema. Questa impostazione viene memorizzata per ciascun utente nel sistema, e può accadere che un utente non realizzi che, visualizzando un problema alcuni giorni dopo, sta vedendo un feed filtrato. Gli sembra che non sia possibile lasciare un commento.
Abbiamo migliorato questa interazione. Ora gli utenti possono passare rapidamente alla modalità che consente di lasciare commenti senza dover scorrere nuovamente fino all'inizio del feed. Questo si applica a task, merge request ed epics.
Modifica dell'ordine degli epics figli
(ULTIMATE, GOLD)
Recentemente abbiamo rilasciato , che consentono di utilizzare epics di epics (oltre ai task figli degli epics).
Ora è possibile modificare l'ordine degli epics figli semplicemente trascinandoli, proprio come nel caso dei task figli. I team possono utilizzare l'ordine per riflettere le priorità o definire l'ordine di esecuzione del lavoro.
Messaggi di sistema personalizzati nell'intestazione e nel piè di pagina online e via email
(CORE, STARTER, PREMIUM, ULTIMATE)
In precedenza abbiamo aggiunto una funzione che consente ai messaggi di intestazione e piè di pagina personalizzati di apparire su ogni pagina in GitLab. È stata accolta con favore e i team la utilizzano per condividere informazioni importanti: ad esempio, messaggi di sistema relativi al loro instance di GitLab.
Siamo lieti di introdurre questa funzionalità in Core, così ancora più persone possono usufruirne. Inoltre, consentiamo agli utenti di visualizzare gli stessi messaggi in tutte le email inviate tramite GitLab, per garantire coerenza con gli altri punti di interazione degli utenti con GitLab.
Filtra per attività riservate
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Le attività riservate sono uno strumento utile per i team, che consente di condurre discussioni chiuse su argomenti delicati all'interno di un progetto aperto. In particolare, sono ideali per lavorare su vulnerabilità di sicurezza. Finora gestire le attività riservate non è stato molto semplice.
In GitLab 11.9, l'elenco delle attività di GitLab ora è filtrato per attività riservate o non riservate. Ciò riguarda anche la ricerca di attività tramite API.
Ringraziamo 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 servire varie applicazioni/funzioni serverless con un endpoint unico.
Ora l'integrazione di Kubernetes in GitLab consente di cambiare/aggiornare il dominio dell'utente dopo il deploy di Knative nel cluster Kubernetes.
Controllo del formato del certificato Kubernetes CA
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Quando si aggiunge un cluster Kubernetes esistente, GitLab ora verifica che il certificato CA fornito abbia un formato PEM valido. Questo elimina possibili errori nell'integrazione di Kubernetes.
Espansione dello strumento di confronto delle merge request a tutto il file
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nel visualizzare le modifiche in una merge request, ora è possibile espandere lo strumento di confronto per ogni file, mostrando l'intero file per un contesto più ampio e consentendo commenti sulle righe non modificate.
Esecuzione di lavori specifici per le merge request solo quando vengono modificati determinati file
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 11.6 è stata aggiunta la possibilità di definire per i lavori dei pipeline, in modo che gli utenti possano eseguire compiti specifici solo quando viene creata una merge request.
Ora stiamo espandendo questa funzionalità: è stata aggiunta la logica di connessione , e gli utenti possono eseguire lavori specifici solo per le merge request e solo quando vengono modificati 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 «pronta all'uso».
Visualizzazione degli epic primari nella barra laterale degli epic
(ULTIMATE, GOLD)
Recentemente abbiamo introdotto , che consente di utilizzare gli epic degli epic.
In GitLab 11.9 abbiamo semplificato il meccanismo di visualizzazione di questa relazione. Ora è visibile non solo l'epico genitore di un epic specifico, ma anche l'intero albero degli epic nella barra laterale a destra. Si può vedere se questi epic sono chiusi o meno e si può persino accedervi direttamente.
Link a un nuovo compito da un compito spostato e chiuso
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab è facile spostare un compito in un altro progetto tramite la barra laterale o un'azione rapida. In background, il compito esistente viene chiuso e nel progetto di destinazione viene creato un nuovo compito con tutti i dati copiati, comprese le note di sistema e gli attributi della barra laterale. Questa è una funzionalità eccellente.
Considerando che c'è una nota di sistema riguardo al trasferimento, gli utenti, quando visualizzano un'attività chiusa, possono provare confusione: non possono non capire che l'attività è stata chiusa a causa del trasferimento.
In questa release indichiamo direttamente sull'icona nella parte superiore della pagina dell'attività chiusa che è stata trasferita, e includiamo un link integrato al nuovo compito, in modo che chiunque atterrasse sul vecchio possa passare rapidamente al nuovo.
Integrazione YouTrack
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab si integra con molti sistemi di tracciamento delle attività esterni, il che facilita alle squadre l'utilizzo di GitLab per altre funzioni, mantenendo comunque lo strumento di gestione delle attività che hanno scelto.
In questa release abbiamo aggiunto la possibilità di integrazione con YouTrack di JetBrains.
Ringraziamo per il contributo di Kotau Yauhen ()!
Ridimensionamento dell'albero dei file della merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Quando si visualizzano le modifiche della merge request, ora è possibile ridimensionare l'albero dei file per visualizzare nomi di file lunghi o risparmiare spazio su schermi piccoli.
Accesso ai pannelli delle attività recenti
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Le panelli delle attività sono molto utili, e i team creano più panelli per ogni progetto e gruppo. Recentemente abbiamo aggiunto un pannello di ricerca per filtrare rapidamente tutti i panelli di vostro interesse.
In GitLab 11.9 abbiamo anche introdotto la sezione Recenti nel menu a discesa. In questo modo, è possibile accedere rapidamente ai panelli con cui avete interagito di recente.
La possibilità di creare rami protetti da parte degli sviluppatori
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
I rami protetti impediscono di spostare o unire codice non revisionato. Tuttavia, se a nessuno è consentito 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 fork consente a chiunque di partecipare a progetti open source: senza bisogno di permessi di scrittura, semplicemente copiando il repository in un nuovo progetto. Mantenere copie complete di repository Git spesso forkati non è efficiente. Ora con Git alternatives i fork condividono oggetti comuni dal progetto superiore nel pool di oggetti per ridurre i requisiti di spazio su disco.
I pool di oggetti per i fork vengono creati solo per progetti aperti, se è collegato un repository 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 prassi comune in qualsiasi progetto di successo, ma può essere difficile per il revisore tenere traccia delle merge request.
In GitLab 11.9, l'elenco delle merge request viene filtrato per l'approvatore assegnato. Così puoi trovare le merge request che ti sono state assegnate come revisore.
Grazie 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)
Navigando le modifiche nella merge request, è possibile passare rapidamente tra i file usando ]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 della funzionalità GitLab CI, il template serverless gitlab-ci.yml è stato notevolmente semplificato. Per introdurre nuove funzionalità nelle future release, 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 ritornano all'indirizzo IP (come GKE di Google), mentre altre usano il nome DNS (come EKS di AWS).
La nostra integrazione Kubernetes ora supporta entrambi i tipi di endpoint per la visualizzazione nella sezione clusters progetto.
Grazie per il contributo di Aaron Walker ()!
Limitazione dell'accesso per l'accesso a JupyterHub solo per i membri del gruppo/progetto
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Il deployment di JupyterHub tramite l'integrazione di GitLab con Kubernetes è un ottimo modo per gestire e utilizzare Jupyter Notebook in grandi gruppi. È anche utile controllare l'accesso a essi quando si trasferiscono dati riservati o personali.
In GitLab 11.9, the ability to log into JupyterHub instances deployed via Kubernetes is limited to project members with the 'developer' access level (through a group or project).
Time ranges customizable for security dashboard schemes
(ULTIMATE, GOLD)
The group security dashboard includes a vulnerability scheme to review the current security status of group projects. This is very useful for security directors to configure processes and understand how the team operates.
In GitLab 11.9, you can now select the time range for this vulnerability scheme. By default, it is set to the last 90 days, but you can set it to a range of 60 or 30 days, depending on the needed level of detail.
This does not affect data in counters or lists, only the data points displayed on the scheme.
Adding Auto DevOps build job for tags
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
The Auto DevOps build stage creates a build of your application using the project's Dockerfile or Heroku buildpack.
In GitLab 11.9, the generated Docker image embedded in the tags pipeline will be named similarly to traditional image names using the tag commit instead of the SHA 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 controllare come le modifiche influenzano lo stato del tuo codice e del tuo progetto.
In GitLab 11.9 abbiamo aggiornato il motore all'ultima versione (), per fornire i vantaggi del supporto per un ulteriore linguaggio e analisi statica per GitLab Code Quality.
Grazie per il contributo del membro del team GitLab Core Takuya Noguchi ()!
Ridimensionamento e scorrimento del pannello delle metriche
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Quando si analizzano anomalie delle prestazioni, è spesso utile esaminare più da vicino le singole parti di una certa metrica.
Con GitLab 11.9, gli utenti potranno ridimensionare singoli intervalli di tempo sul pannello delle metriche, scorrere l'intero intervallo di tempo e tornare facilmente alla vista dell'intervallo di tempo originale. Questo consente di esaminare facilmente e rapidamente gli eventi desiderati.
SAST per TypeScript
(ULTIMATE, GOLD)
è un linguaggio di programmazione relativamente nuovo basato su .
In GitLab 11.9, the Static Application Security Testing (SAST) feature analyzes and detects vulnerabilities in TypeScript code, displaying them in the merge request widget, at the pipeline level, and on the security dashboard. The current job definition sast does not need to be changed, and it is also automatically included in .
SAST for multi-module Maven projects
(ULTIMATE, GOLD)
Maven projects are often organized to combine within a single repository. Previously, GitLab could not properly scan such projects, meaning developers and security professionals did not receive vulnerability reports.
GitLab 11.9 offers enhanced support for the SAST feature for this particular project configuration, allowing for testing against vulnerabilities in the source state. Thanks to the flexibility of the analyzers, the configuration is determined automatically, and you don’t need to change anything to view results for multi-module Maven applications. As usual, similar improvements are also available for .
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 utilizzato per eseguire job CI/CD e inviare i risultati a GitLab.
Di seguito sono riportate alcune modifiche in GitLab Runner 11.9:
- .
- e .
- . Questo include anche .
- per supportare , che appariranno in GitLab 11.10.
- .
- .
- Spostamento di diversi script — inclusi e — in Go.
- .
- .
- .
Un elenco completo delle modifiche è disponibile nel changelog di GitLab Runner: .
Miglioramenti allo schema di GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
Sono stati apportati i seguenti miglioramenti al chart di GitLab:
- È stata aggiunta la supporto per Google Cloud Memorystore.
- Impostazioni Cron job , poiché vengono utilizzati 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 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 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 , , il cui ultimo rilascio include MFA per Team Edition, prestazioni migliorate delle immagini e molto altro. Questa versione include anche ; si raccomanda di aggiornare.
- È stato aggiunto un nuovo parametro che garantisce la compatibilità del registro GitLab con versioni di Docker fino alla 1.10. Per attivarlo, impostare
registry['compatibility_schema1_enabled'] = true in gitlab.rb. - Il registro GitLab ora esporta metriche Prometheus e viene automaticamente monitorato 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à obsolete
GitLab Geo garantirà l'archiviazione hash in GitLab 12.0
GitLab Geo richiede per mitigare la competizione (race condition) sui nodi secondari. Questo è stato segnalato in .
In GitLab abbiamo aggiunto questo requisito nella documentazione di Geo: .
In GitLab sudo gitlab-rake gitlab: geo: check controlla se l'archiviazione hash è abilitata e se tutti i progetti sono trasferiti. Vedi . Se utilizzi Geo, ti preghiamo di eseguire questo controllo e di migrare il prima possibile.
In GitLab avviso disattivabile permanentemente verrà visualizzato nella pagina Area Admin › Geo › Nodi, se i controlli sopra menzionati non sono autorizzati.
In GitLab Geo utilizzerà i requisiti per l'archiviazione hash. Vedi .
Data di rimozione: 22 giugno 2019
Integrazione Hipchat
Hipchat . Inoltre, nella versione 11.9 .
Data di rimozione: 22 marzo 2019.
Supporto per CentOS 6 per GitLab Runner con Docker executor
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. Maggiori dettagli possono essere trovati in .
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 la configurazione del server dei metric per GitLab Runner. metrics_server verrà rimosso a favore di listen_address in GitLab 12.0. Consulta di più in . Ulteriori dettagli in .
Nella versione 11.3, GitLab Runner ha iniziato a supportare , che ha portato a nuove configurazioni per . In è riportata una tabella delle modifiche e le istruzioni per passare alla nuova configurazione. Consulta di più in .
Questi percorsi non sono più disponibili in GitLab 12.0. Come utente, non devi modificare nulla, devi solo assicurarti che l'istanza di GitLab funzioni con la versione 11.9+ quando si esegue l'aggiornamento a GitLab Runner 12.0.
Data di rimozione: 22 giugno 2019
Parametro obsoleto per la funzionalità di punto di ingresso per GitLab Runner
In 11.4 è stato introdotto un parametro per la funzionalità del GitLab Runner per risolvere problemi come e .
In GitLab 12.0 passeremo a un comportamento corretto, come se il parametro della funzionalità fosse disabilitato. Consulta di più in .
Data di rimozione: 22 giugno 2019
Supporto obsoleto per le distribuzioni Linux che hanno raggiunto EOL per GitLab Runner
Alcune distribuzioni Linux in cui è possibile installare GitLab Runner hanno esaurito il supporto.
In GitLab 12.0, GitLab Runner non distribuirà più pacchetti in tali distribuzioni Linux. L'elenco completo delle distribuzioni non più supportate è disponibile nella nostra . Grazie a Javier Ardo () per il suo !
Data di rimozione: 22 giugno 2019
Rimozione dei vecchi comandi GitLab Runner Helper
Nell'ambito degli sforzi di supporto abbiamo dovuto rinunciare ad alcuni vecchi comandi utilizzati per .
In GitLab 12.0, GitLab Runner is launched using new commands. This only applies to users who override . Maggiori dettagli sono disponibili in .
Data di rimozione: 22 giugno 2019
Developers can delete Git tags in GitLab 11.10.
Historically, removing or editing release notes for Git tags in unprotected branches was limited to .
As developers can add tags and also modify and delete unprotected branches, they should be able to delete Git tags. In GitLab 11.10, to our permissions model to improve workflow and help developers use tags more effectively.
If you want to maintain this restriction for maintainers and owners, use .
Data di rimozione: April 22, 2019.
Support for Prometheus 1.x in Omnibus GitLab.
Starting from GitLab, , the built-in version of Prometheus 1.0 is excluded from Omnibus GitLab. . However, the metrics format is incompatible with version 1.0. Existing versions can be upgraded to 2.0 and, if necessary, data can be migrated .
In GitLab version verrà automaticamente installato Prometheus 2.0, se non ci sono stati aggiornamenti. I dati di Prometheus 1.0 andranno persi poiché non vengono trasferiti.
Data di rimozione: 22 giugno 2019
TLS v1.1
Starting from GitLab, per migliorare la sicurezza. Questo risolve numerosi problemi, incluso Heartbleed, e rende GitLab “pronto all'uso” conforme allo standard PCI DSS 3.1.
Per disabilitare immediatamente TLS v1.1, impostare nginx['ssl_protocols'] = "TLSv1.2" in gitlab.rband e avvia gitlab-ctl reconfigure.
Data di rimozione: 22 giugno 2019
Modello OpenShift per l'installazione di GitLab
Ufficiale è il metodo consigliato per eseguire GitLab su Kubernetes, inclusa .
per l'installazione di GitLab è obsoleto e non sarà più supportato in .
Data di rimozione: 22 giugno 2019
Le definizioni precedenti dei lavori di sicurezza
Con l'introduzione di tutte le precedenti definizioni dei lavori diventeranno obsolete e saranno 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 dal pannello di amministrazione in GitLab 12.0 e raccomandiamo di utilizzare .
Data di rimozione: 22 giugno 2019
Fonte: habr.com
