Progetti e per la creazione del servizio di sviluppo collaborativo Git Forge, che sarà costruito utilizzando la piattaforma GitLab. GitLab diventerà la piattaforma primaria per l'interazione con i repository Git e per l'hosting di progetti legati alle distribuzioni di CentOS e Fedora. Il servizio precedentemente utilizzato continuerà a esistere, ma sarà affidato alla comunità interessata a proseguire lo sviluppo. Pagure verrà tolto dal supporto del team CPE (Community Platform Engineering) di Red Hat, che si occupa della manutenzione dell'infrastruttura per lo sviluppo e la pubblicazione delle versioni di Fedora e CentOS.
Per la valutazione delle possibili soluzioni per il nuovo Git Forge sono stati considerati
Pagure e Gitlab. Sulla base dello studio di circa e suggerimenti da parte dei partecipanti ai progetti Fedora, CentOS, RHEL e CPE, sono stati formulati requisiti funzionali e fatta la scelta a favore di Gitlab. Oltre alle operazioni standard con i repository (fusioni, creazione di fork, aggiunta di codice, ecc.), tra i requisiti chiave sono stati menzionati la sicurezza, la facilità d'uso e la stabilità della piattaforma.
Tra i requisiti erano incluse funzionalità come l'invio di richieste push tramite HTTPS, strumenti per limitare l'accesso ai rami, supporto per rami privati, separazione dell'accesso per utenti esterni e interni (ad esempio, per il lavoro di correzione delle vulnerabilità durante l'embargo sulla divulgazione delle informazioni sul problema), familiarità dell'interfaccia, unificazione dei sottosistemi per lavorare con segnalazioni di problemi, codice, documentazione e pianificazione di nuove funzionalità, disponibilità di strumenti per l'integrazione con IDE, supporto per flussi di lavoro standard.
Tra le funzionalità di GitLab che hanno influito definitivamente sulla decisione di scelta di questa piattaforma ci sono il supporto di sottogruppi con accesso selettivo ai repository, la possibilità di utilizzare un bot per fusioni automatiche (richiede CentOS Stream per mantenere i pacchetti del kernel), disponibilità di strumenti integrati per la pianificazione dello sviluppo, capacità di utilizzare un servizio SAAS già pronto con un livello di disponibilità garantito (permetterà di liberare risorse per la manutenzione dell'infrastruttura server).
La decisione è già critiche tra gli sviluppatori riguardo al fatto che la decisione è stata presa senza un ampio dibattito preliminare. Sono state inoltre espresse preoccupazioni sul fatto che il servizio non utilizzerà l'edizione Community libera di GitLab. In particolare, le funzionalità necessarie per implementare i requisiti descritti nell'annuncio per Git Forge sono disponibili solo nella versione proprietaria .
È stata criticata anche l'intenzione di utilizzare il servizio SAAS fornito da GitLab (applicazione come servizio), invece di distribuire GitLab sui propri server, il che esclude il servizio dal controllo (ad esempio, non è possibile essere certi che tutte le vulnerabilità del sistema vengano risolte tempestivamente, supportata l'infrastruttura, a un certo punto non ci sarà ed esclusa qualsiasi deviazione da parte del personale di aziende terze). La decisione non è nemmeno coerente con , che stabilisce che il progetto dovrebbe preferire alternative libere.
Nel frattempo, GitLab ha annunciato il rilascio di 18 funzionalità che erano state precedentemente offerte solo nelle edizioni proprietarie di GitLab. Le funzionalità coprono varie aree di gestione dell'intero ciclo di sviluppo del software, inclusi pianificazione dello sviluppo, creazione di progetti, verifica, gestione dei pacchetti, creazione di rilasci, configurazione e protezione.
Tra le funzionalità tradotte in versioni libere ci sono:
- Collegamento di issue correlate;
- Esportazione delle issue da GitLab in CSV;
- Modalità di pianificazione, ordinamento e visualizzazione del processo di sviluppo di singole funzionalità o rilasci;
- Servizio integrato per collegare i membri del progetto con terze parti tramite email.
- Web terminal per Web IDE;
- Possibilità di sincronizzare i file per testare le modifiche al codice nel web terminal;
- Strumenti di gestione del design che consentono di caricare nei issue layout e risorse, usando i issue come unico punto di accesso a tutto ciò che è necessario per sviluppare una nuova funzionalità;
- Report sulla qualità del codice;
- Supporto per gestori di pacchetti Conan (C/C++), Maven (Java), NPM (node.js) e NuGet (.NET);
- Supporto per distribuzioni canary, che consentono di installare una nuova versione dell'applicazione su una piccola parte dei sistemi;
- Distribuzioni incremental, che permettono di fornire nuove versioni inizialmente solo a un numero limitato di sistemi, aumentando gradualmente la copertura fino al 100%;
- Flag di attivazione delle funzionalità, che consentono di fornire il progetto in diverse edizioni, attivando dinamicamente determinate opzioni;
- Modalità di revisione delle distribuzioni, che consente di valutare lo stato di ogni ambiente di integrazione continua basato su Kubernetes;
- Supporto per la definizione di più cluster Kubernetes nel configuratore (ad esempio, è possibile utilizzare cluster Kubernetes separati per implementazioni di prova e carichi di lavoro);
- Supporto per la definizione di politiche di sicurezza di rete per i container, che consentono di delimitare l'accesso tra i pod Kubernetes.
In aggiunta, si può notare aggiornamenti GitLab 12.9.1, 12.8.8 e 12.7.8 (Community Edition e Enterprise Edition), in cui è stata risolta una vulnerabilità. Il problema si manifesta a partire dal rilascio di GitLab EE/CE 8.5 e consente di leggere il contenuto di qualsiasi file locale durante il trasferimento delle issue tra i progetti.
I dettagli sulla vulnerabilità saranno rivelati tra 30 giorni.
Fonte: opennet.ru
