GitLab 11.10 con pipeline nella dashboard, pipeline per risultati uniti e suggerimenti su più righe nelle merge request.
Informazioni utili sulla disponibilità dei pipeline nei vari progetti
GitLab continua a migliorare la trasparenza del ciclo di vita DevOps. In questa versione è stato aggiunto un riepilogo dello stato dei pipeline.
È utile, anche se stai esaminando il pipeline di un solo progetto, ma particolarmente vantaggioso se , — il che è comune se usi microservizi e desideri avviare un pipeline per il testing e la distribuzione del codice da diversi repository di progetti. Ora puoi vedere immediatamente la disponibilità , ovunque siano in esecuzione.
Esecuzione di pipeline per risultati uniti
Col passare del tempo, i rami sorgente e obiettivo divergono, e può verificarsi una situazione in cui funzionano separatamente ma non insieme. Ora puoi . In questo modo, potrai notare rapidamente errori che si manifesterebbero solo con frequenti spostamenti di modifiche tra i rami, consentendoti di correggere più rapidamente gli errori nel pipeline e di utilizzarlo in modo più efficiente. .
Ulteriore ottimizzazione della collaborazione
In GitLab 11.10, ci sono ancora più funzionalità per migliorare la collaborazione e semplificare i flussi di lavoro. In abbiamo introdotto suggerimenti per le merge request, consentendo ai revisori di proporre modifiche di una riga nei commenti alla merge request, e di poterle immediatamente impegnare direttamente dalla conversazione. I nostri utenti hanno apprezzato questa funzionalità e hanno chiesto di ampliarla. Ora puoi suggerire , specificando quali righe eliminare e quali aggiungere.
Grazie per i vostri riscontri e suggerimenti!
E non è tutto...
In questo rilascio ci sono così tante fantastiche funzionalità, ad esempio, , una , e la possibilità di . Di seguito i dettagli su ciascuna di esse.
Miglior dipendente del mese () — Takuya Noguti
Questo mese l'impiegato più prezioso è stato Takuya Noguchi (). Takuya : ha corretto bug, completato il lavoro in backend e frontend e migliorato l'interfaccia utente. Grazie!
Caratteristiche principali di GitLab 11.10
Pipeline nella dashboard
PREMIUM, ULTIMATE, SILVER, GOLD
Nella dashboard di GitLab vengono visualizzate informazioni sui progetti per l'intero istanza di GitLab. Puoi aggiungere progetti singoli uno alla volta e selezionare quale progetto ti interessa.
In questa versione abbiamo aggiunto sulla dashboard informazioni sullo stato delle pipeline. Ora gli sviluppatori possono vedere il funzionamento delle pipeline in tutti i progetti necessari — in un'unica interfaccia.
Pipeline per risultati unificati
PREMIUM, ULTIMATE, SILVER, GOLD
Di solito, nel corso del tempo, il ramo sorgente si discosta da quello di destinazione, se non si spostano continuamente le modifiche tra di essi. Di conseguenza, le pipeline dei rami sorgente e di destinazione sono 'verdi' e non ci sono conflitti di merge, ma durante la fusione si verifica un errore a causa dell'incompatibilità delle modifiche.
Quando un pipeline di merge request crea automaticamente un nuovo link che contiene il risultato unito del merge dei rami sorgente e di destinazione, possiamo avviare il pipeline a questo link e garantire che il risultato finale funzioni.
Se utilizzi pipeline di merge request (in qualsiasi qualità) e usi dei runner GitLab privati della versione 11.8 o precedente, è necessario aggiornarli per evitare problemi. . Questo non influisce sugli utenti dei runner GitLab pubblici.
Proposta di modifiche su più righe
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Durante la collaborazione su merge request, noti frequentemente problemi e proponi soluzioni. A partire dalla versione 11.6 di GitLab supportiamo per una riga.
Nella versione 11.10, nei commenti al diff della merge request, è possibile proporre modifiche per più righe, e poi qualsiasi utente con autorizzazioni di scrittura sul ramo sorgente può accettarle con un solo clic. Questa nuova funzionalità permette di evitare il copia e incolla, come nelle versioni precedenti.
Etichette in un'area
PREMIUM, ULTIMATE, SILVER, GOLD
Con le etichette in un'unica area, i team possono applicare etichette mutuamente escluenti (nella stessa area) per un'attività, una merge request o un'epic in scenari con campi personalizzati o stati di flusso di lavoro personalizzati. Queste vengono configurate utilizzando una sintassi specifica con i due punti nel titolo dell'etichetta.
Supponiamo che tu abbia bisogno di un campo personalizzato nelle attività per tenere traccia del sistema operativo della piattaforma a cui sono destinati le tue funzionalità. Ogni attività dovrebbe appartenere solo a una piattaforma. Puoi creare etichette platform::iOS, platform::Android, platform::Linux e altre se necessario. Se applichi un'etichetta di questo tipo a un'attività, verrà automaticamente rimossa un'altra etichetta esistente che inizia con platform::.
Supponiamo che tu abbia etichette workflow::development, workflow::review e workflow::deployed, che rappresentano lo stato del flusso di lavoro nel tuo team. Se un'attività ha già un'etichetta workflow::development, e lo sviluppatore desidera spostare l'attività nella fase workflow::review, basta applicare la nuova etichetta e l'old (workflow::development) viene automaticamente rimosso. Questo comportamento è già presente quando si spostano compiti tra le liste di etichette nel pannello dei compiti che rappresenta il flusso di lavoro del vostro team. Ora i membri del team che non lavorano direttamente con il pannello dei compiti possono modificare lo stato del flusso di lavoro direttamente nelle attività.
Pulizia più approfondita del registro dei contenitori
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Con l'uso normale del registro dei contenitori con pipeline CI, inviate diverse modifiche separate in un solo tag. A causa dell'implementazione della distribuzione Docker, il comportamento predefinito è quello di mantenere tutte le modifiche nel sistema, ma questo alla fine occupa molta memoria. Utilizzando l'opzione -m con registry-garbage-collect, è possibile rimuovere rapidamente tutte le modifiche precedenti e liberare spazio prezioso.
Acquisto di minuti aggiuntivi per CI Runner
BRONZE, SILVER, GOLD
Gli utenti con piani a pagamento di GitLab.com (Gold, Silver, Bronze) possono ora acquistare minuti aggiuntivi per CI Runner. In passato, era necessario rimanere all'interno del limite previsto dal piano. Con questo miglioramento, è possibile acquistare in anticipo minuti oltre il limite per evitare interruzioni dovute all'arresto delle pipeline.
Attualmente 1000 minuti costano 8 dollari, e possono essere acquistati in qualunque quantità. I minuti aggiuntivi inizieranno ad essere utilizzati quando esaurirai la quota mensile, e il restante dei minuti aggiuntivi verrà trasferito al mese successivo. vogliamo aggiungere questa funzione anche nei piani gratuiti.
Auto DevOps composable
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Con Auto DevOps, i team adottano pratiche DevOps moderne quasi senza sforzo. A partire da GitLab 11.10, ogni job in Auto DevOps è fornito come . Gli utenti possono utilizzare in GitLab CI per includere singole fasi di Auto DevOps, pur utilizzando il proprio file gitlab-ci.yml. In questo modo, si possono includere solo i job necessari e beneficiare degli aggiornamenti upstream.
Gestione automatica dei membri del gruppo su GitLab.com tramite SCIM
ARGENTO, ORO
In precedenza, gestire l'appartenenza ai gruppi su GitLab.com richiedeva un intervento manuale. Ora è possibile utilizzare SAML SSO e gestire i membri tramite SCIM, per creare, eliminare e aggiornare gli utenti su GitLab.com.
Questo è particolarmente utile per le aziende con un elevato numero di utenti e fornitori di identità centralizzati. Ora puoi avere una fonte unica di verità come Azure Active Directory, e gli utenti verranno creati e rimossi automaticamente tramite il fornitore di identità, anziché manualmente.
Accesso a GitLab.com tramite fornitore SAML
ARGENTO, ORO
In precedenza, quando si utilizzava SAML SSO per i gruppi, l'utente doveva accedere con le credenziali di GitLab e il fornitore di identità. Ora è possibile accedere direttamente tramite SSO come utente GitLab collegato al gruppo configurato.
Gli utenti non dovranno effettuare l'accesso due volte, quindi per le aziende è più conveniente utilizzare SAML SSO per GitLab.com.
Altri miglioramenti in GitLab 11.10
Schema degli epic secondari
ULTIMATE, GOLD
Nella precedente versione abbiamo aggiunto gli epic secondari (epic degli epic) per semplificare la gestione della struttura di distribuzione dei compiti. Gli epic secondari vengono visualizzati nella pagina dell'epico genitore.
In questa versione, sulla pagina dell'epico genitore viene visualizzato lo schema degli epic secondari, quindi i team possono vedere la cronologia degli epic secondari e gestire le dipendenze temporali.
Schermate contestuali dei merge request
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
In questo aggiornamento presentiamo schermate informative che appaiono quando si passa il cursore sul link del merge request. In precedenza mostravamo solo il titolo del merge request, mentre ora mostriamo anche lo stato del merge request, lo stato della CI pipeline e un URL breve.
Nei prossimi aggiornamenti prevediamo di aggiungere ulteriori informazioni importanti, come , e introdurremo schermate contestuali per .
Filtraggio dei merge request per rami target
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
I flussi di lavoro Git per il rilascio o la distribuzione del software sono spesso correlati a diversi rami a lungo termine — per apportare correzioni a versioni precedenti (ad esempio, stable-11-9) o per passare dal controllo qualità alla produzione (ad esempio, integration), ma non è facile trovare merge request per questi rami tra i numerosi merge request aperti.
L'elenco dei merge request per progetti e gruppi può ora essere filtrato per ramo target del merge request, rendendo più semplice trovare quello desiderato.
Grazie, Hiroyuki Sato ()!
Invio e merge con pipeline riuscita
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Se utilizziamo il metodo di sviluppo basato su trunk, dobbiamo evitare rami a lungo termine a favore di brevi rami temporanei con un solo proprietario. Piccole modifiche vengono spesso inviate direttamente al ramo di destinazione, ma in questo modo rischiamo di compromettere la build.
In questo rilascio, GitLab supporta nuove opzioni di invio in Git per aprire automaticamente merge request, impostare il ramo di destinazione e garantire un merge in caso di pipeline riuscita dalla riga di comando durante l'invio al ramo.
Integrazione migliorata con pannelli di monitoraggio esterni
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab può rivolgersi a più server Prometheus (a livello di ambiente, progetto e ), ma avere più endpoint può complicare il sistema o non essere supportato dai pannelli di monitoraggio standard. In questo rilascio, i team possono utilizzare una sola API Prometheus, semplificando notevolmente l'integrazione con servizi come Grafana.
Ordinamento delle pagine Wiki per data di creazione
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
In Wiki, i membri del team possono condividere documentazione e altre informazioni importanti insieme al codice sorgente e alle attività. In questa versione, l'elenco delle pagine nel Wiki può essere ordinato per data di creazione e titolo, per trovare rapidamente i contenuti recentemente creati.
Monitoraggio delle risorse richieste dal cluster
ULTIMATE, GOLD
GitLab aiuta a monitorare il cluster Kubernetes per le applicazioni in fase di sviluppo e in produzione. A partire da questa versione, monitora le risorse della CPU e la memoria richieste dal cluster, per identificare potenziali complessità prima che diventino problemi.
Visualizzazione delle metriche del bilanciatore di carico nel pannello di monitoraggio Grafana
CORE, STARTER, PREMIUM, ULTIMATE
È fondamentale tenere d'occhio le prestazioni dell'istanza GitLab. In passato, offrivamo pannelli di monitoraggio predefiniti tramite un'istanza integrata di Grafana. A partire da questa versione, abbiamo incluso pannelli aggiuntivi per il monitoraggio dei bilanciatori di carico NGINX.
SAST per Elixir
ULTIMATE, GOLD
Continuiamo a espandere il supporto per i linguaggi e ad approfondire i controlli di sicurezza. In questa versione abbiamo incluso controlli di sicurezza per progetti su e progetti creati su .
Più richieste in un unico diagramma
PREMIUM, ULTIMATE, SILVER, GOLD
In GitLab è possibile creare diagrammi per visualizzare le metriche raccolte. Spesso, ad esempio, quando è necessario analizzare il valore massimo o medio di una metrica, si desidera visualizzare più valori su un unico diagramma. A partire da questa versione, avete questa possibilità.
Risultati DAST nel pannello di sicurezza del gruppo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Abbiamo aggiunto i risultati del Dynamic Application Security Testing (DAST) al pannello di sicurezza del gruppo, insieme a SAST, scansione dei container e scansione delle dipendenze.
Aggiunta di metadati nel rapporto di scansione dei container
ULTIMATE, GOLD
In questa versione, il rapporto di scansione dei container include più metadati: abbiamo aggiunto il componente interessato (funzionalità Clair) ai metadati esistenti: priorità, identificativo (con riferimento a mitre.org) e livello interessato (ad esempio, debian:8).
Aggiunta del tipo di rapporto sulle metriche nelle merge request
PREMIUM, ULTIMATE, SILVER, GOLD
GitLab fornisce già diversi tipi di rapporti che possono essere inclusi direttamente nelle merge request: dai rapporti sulla e nella fase di revisione fino a e nella fase di protezione.
Seppur siano rapporti importanti, anche informazioni di base che si adattano a diversi scenari sono necessarie. In GitLab 11.10, forniamo rapporti sulle metriche direttamente nella merge request, che richiede semplicemente una coppia chiave-valore. In questo modo, gli utenti possono monitorare le variazioni nel tempo, comprese le metriche personalizzate, e le modifiche alle metriche per una specifica merge request. L'uso della memoria, il testing dei carichi specifici e gli stati di operatività possono essere trasformati in metriche semplici, che possono essere visualizzate direttamente nelle merge request insieme ad altri rapporti integrati.
Supporto per progetti Maven multi-modulo per la scansione delle dipendenze
ULTIMATE, GOLD
In questa versione, i progetti multimodulari Maven supportano la scansione delle dipendenze GitLab. In precedenza, se un sottomodulo aveva una dipendenza da un altro sottomodulo dello stesso livello, non poteva risolvere il download dal repository centrale Maven. Ora, un progetto multimodulare Maven viene creato con due moduli e una dipendenza tra i due. La dipendenza tra moduli dello stesso livello è ora disponibile nel repository locale Maven, permettendo di continuare la build.
Gli utenti possono modificare il percorso per il clone in CI
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Per impostazione predefinita, GitLab Runner clona il progetto in un percorso nidificato unico in $CI_BUILDS_DIR. Ma per alcuni progetti, come Golang, è necessario clonare il codice in una cartella specifica affinché possa essere compilato.
In GitLab 11.10, abbiamo introdotto la variabile GIT_CLONE_PATH, che consente di specificare un percorso concreto in cui GitLab Runner clona il progetto prima di eseguire il job.
Mascheramento semplice delle variabili protette nei log
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab offre diversi modi per e delle variabili in GitLab CI/CD. Tuttavia, le variabili possono comunque finire nei log di build, intenzionalmente o accidentalmente.
GitLab prende molto sul serio la gestione dei rischi e degli audit e continua ad aggiungere funzionalità per garantire la conformità. Con GitLab 11.10, abbiamo introdotto la possibilità di mascherare alcuni tipi di variabili nei log delle tracce delle job, aumentando il livello di protezione contro la possibile esposizione del contenuto di queste variabili nei registri. Inoltre, GitLab ora molte variabili token integrate.
Attivazione e disattivazione di Auto DevOps a livello di gruppo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Con Auto DevOps su GitLab.com, puoi affrontare con facilità i moderni flussi di lavoro DevOps — dalla costruzione alla consegna.
A partire da GitLab 11.10, puoi attivare e disattivare Auto DevOps per tutti i progetti in un gruppo.
Pagina delle licenze semplificata e migliorata
STARTER, PREMIUM, ULTIMATE
Per rendere più semplice la gestione delle chiavi di licenza, abbiamo modificato il design della pagina delle licenze nel pannello di amministrazione, evidenziando gli elementi più importanti.
Aggiornamento del selettore delle etichette per i deployment Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Nelle pannelli di deployment, vengono visualizzate informazioni su tutti i deployment Kubernetes.
In questa versione, abbiamo modificato il modo in cui le etichette vengono associate ai deployment. Ora sono disponibili corrispondenze per app.example.com/app e app.example.com/env o app. Questo eviterà conflitti durante il filtraggio e il rischio di deploy errati legati al progetto.
Inoltre, nella versione GitLab 12.0 noi , e la corrispondenza sarà possibile solo per app.example.com/app e app.example.com/env.
Creazione dinamica delle risorse Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
L'integrazione di Kubernetes in GitLab consente di utilizzare la funzione RBAC tramite un account di servizio e uno spazio dei nomi dedicato per ogni progetto GitLab. A partire da questa versione, per massimizzare l'efficienza, queste risorse verranno create solo quando necessarie per il deploy.
Durante il deploy Kubernetes, GitLab CI creerà queste risorse prima del deploy.
Runner di gruppo per cluster a livello di gruppo
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
I cluster a livello di gruppo ora supportano l'installazione di GitLab Runner. I runner Kubernetes a livello di gruppo vengono visualizzati per i progetti secondari come runner di gruppo, contrassegnati con l'etichetta cluster e kubernetes.
Contatore delle chiamate per le funzioni Knative
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Le funzioni distribuite con , ora mostrano il numero di chiamate ricevute per ciascuna funzione. Per fare ciò, è necessario installare Prometheus nel cluster dove è installato Knative.
Controllo dei parametri git clean per i job GitLab CI/CD
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Per impostazione predefinita, GitLab Runner esegue git clean nel processo di pulizia del codice durante l'esecuzione di un job in GitLab CI/CD. A partire da GitLab 11.10, gli utenti possono controllare i parametri passati al comando git clean. Questo è utile per i team con runner dedicati, così come per quelli che raccolgono progetti da grandi monorepository. Ora possono gestire il processo di pulizia prima dell'esecuzione degli script. La nuova variabile GIT_CLEAN_FLAGS ha per impostazione predefinita il valore -ffdx e accetta tutti i parametri possibili del comando [git clean](https://git-scm.com/docs/git-clean).
Autenticazione esterna in Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Ambienti protetti possono richiedere una risorsa di autorizzazione esterna aggiuntiva per accedere al progetto. Abbiamo aggiunto il supporto per un ulteriore livello di controllo accessi in e abbiamo ricevuto molte richieste per aprire questa funzionalità in Core. Siamo lieti di presentare l'autenticazione esterna e un ulteriore livello di sicurezza per le istanze di Core, dato che questa funzionalità è necessaria per alcuni partecipanti.
Possibilità di creare progetti nei gruppi in Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Il ruolo di Developer può creare progetti nei gruppi , e ora è possibile anche in Core. La creazione di progetti è una funzionalità fondamentale per una collaborazione produttiva in GitLab, e grazie all'inclusione di questa funzione in Core, i partecipanti all'istanza possono ora dedicarsi più facilmente a qualcosa di nuovo.
GitLab Runner 11.10
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Oggi abbiamo lanciato GitLab Runner 11.10! GitLab Runner è un progetto open source utilizzato per eseguire compiti CI/CD e inviare i risultati nuovamente a GitLab.
Le modifiche più interessanti:
- .
- .
- .
- .
- .
Un elenco completo delle modifiche è disponibile nel changelog di GitLab Runner: .
Correzione del valore restituito project_id nella API di ricerca blob in Elasticsearch
STARTER, PREMIUM, ULTIMATE
Abbiamo corretto un errore nell'API di ricerca blob in Elasticsearch, che restituiva erroneamente 0 per project_id. Sarà necessario , per ottenere i valori corretti project_id dopo l'installazione di questa versione di GitLab.
Miglioramenti di Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Abbiamo apportato i seguenti miglioramenti a Omnibus in GitLab 11.10:
- GitLab 11.10 include , , l'ultimo aggiornamento include un nuovo catalogo di integrazione per un facile trasferimento dei dati da Hipchat e molto altro. Questa versione include , e raccomandiamo di aggiornare.
- Noi , rendendo ora semplice avviare il monitoraggio dell'istanza di GitLab.
- Abbiamo aggiunto il supporto per la rimozione delle vecchie immagini dei container dal registro Docker.
- Abbiamo aggiornato i ca-certs al 2019-01-23.
Miglioramenti 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. Alcuni miglioramenti in GitLab 11.10:
- .
- .
- .
- .
- .
- .
- .
- .
Miglioramento dei diagrammi di GitLab
CORE, STARTER, PREMIUM, ULTIMATE
Abbiamo apportato le seguenti migliorie ai diagrammi di GitLab:
- .
Funzionalità obsolete
GitLab Geo garantirà l'archiviazione hash in GitLab 12.0
GitLab Geo richiede per mitigare la concorrenza sui nodi secondari. Questo è stato registrato 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
Supporto per Ubuntu 14.04
GitLab 11.10 sarà l'ultima versione con .
Canonical ha annunciato la fine del supporto standard per Ubuntu 14.04 da . Consigliamo agli utenti di passare a una versione LTS supportata: Ubuntu 16.04 o Ubuntu 18.04.
Data di rimozione: 22 maggio 2019
Limitazione del numero massimo di pipeline create da un singolo push
In precedenza, GitLab creava pipeline per HEAD ogni branch nel push. Questo è utile per gli sviluppatori che spingono più modifiche contemporaneamente (ad esempio, in un branch feature e in un branch develop).
Ma quando si esegue il push di un grande repository, con molti branch attivi (ad esempio, per spostamenti, mirror o diramazioni), non è necessario creare una pipeline per ogni branch. A partire da GitLab 11.10, stiamo creando al momento del push.
Data di rimozione: 22 maggio 2019
Percorsi legacy obsoleti del codice GitLab Runner
A partire da GitLab 11.9, GitLab Runner utilizza per clonare/chiamare il repository. Attualmente, GitLab Runner utilizzerà il vecchio metodo se il nuovo non è supportato. Per ulteriori dettagli, vedi .
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 .
Nella versione 11.3, GitLab Runner ha iniziato a supportare ; il che ha portato a nuove impostazioni per . In , è disponibile una tabella delle modifiche e istruzioni per passare alla nuova configurazione. Maggiori dettagli sono disponibili in .
Questi percorsi non saranno più disponibili in GitLab 12.0. Come utente, non è necessario cambiare nulla, ma assicurati che l'istanza di GitLab funzioni con la versione 11.9+ prima di aggiornare 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 !
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 viene avviato utilizzando nuovi comandi. Questo riguarda solo gli utenti che . Maggiori dettagli sono disponibili in .
Data di rimozione: 22 giugno 2019
Rimozione del meccanismo legacy git clean da GitLab Runner
In GitLab Runner 11.10 configurare come il Runner esegue il comando git clean. Inoltre, la nuova strategia di pulizia rimuove l'uso di git reset e posiziona il comando git clean dopo il passaggio di scarico.
Poiché questo cambiamento di comportamento può influire su alcuni utenti, abbiamo preparato un parametro FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Se impostato su true, ripristinerà la strategia legacy di pulizia. Maggiori informazioni sull'uso dei parametri delle funzioni in GitLab Runner possono essere trovate .
In GitLab Runner 12.0 rimuoveremo il supporto per la strategia di pulizia legacy e la possibilità di ripristinarla tramite il parametro della funzione. Maggiori dettagli sono disponibili in .
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
Registro delle modifiche
Trova tutte queste modifiche nel registro delle modifiche:
Installazione
Se stai configurando una nuova installazione di GitLab, visita .
Aggiornamento
Dai un'occhiata a .
Piani di abbonamento GitLab
GitLab è disponibile in due varianti: e .
: localmente o su una piattaforma cloud a preferenza.
- Core: per piccoli team, progetti personali o la versione di prova di GitLab a tempo illimitato.
- Starter: per team che lavorano in un unico ufficio su più progetti e necessitano di supporto professionale.
- Premium: per team distribuiti che necessitano di funzionalità avanzate, alta disponibilità e supporto 24/7.
- Ultimate: per le aziende che necessitano di una strategia e attuazione affidabili con sicurezza e conformità migliorate.
— GitLab.com: ospitato, gestito e amministrato da GitLab per singoli sviluppatori e team.
- Free: repository privati illimitati e numero illimitato di membri del progetto. I progetti privati hanno accesso a funzionalità di livello Free, mentre hanno accesso a funzionalità di livello Gold.
- Bronze: per team che necessitano di accesso a funzionalità avanzate del flusso di lavoro.
- Silver: per team che necessitano di capacità DevOps più affidabili, conformità e supporto rapido.
- Gold: adatto per molte operazioni CI/CD. Tutti i progetti aperti possono utilizzare gratuitamente le funzionalità Gold, indipendentemente dal piano.
Fonte: habr.com
