Progetti и sulla decisione di creare un servizio di sviluppo collaborativo Git Forge, che sarà realizzato utilizzando la piattaforma GitLab. GitLab diventerà la piattaforma principale per interagire con i repository Git e per ospitare progetti relativi alle distribuzioni CentOS e Fedora. Servizio utilizzato in precedenza continuerà ad esistere, ma sarà affidato alle cure di una comunità interessata allo sviluppo continuo. Pagure verrà rimosso dal supporto del team CPE (Community Platform Engineering) impiegato presso Red Hat, impegnato nel mantenimento dell'infrastruttura per lo sviluppo e la pubblicazione delle versioni di Fedora e CentOS.
Nel valutare le possibili soluzioni per il nuovo Git Forge, abbiamo considerato
Pagure e Gitlab. Sulla base di uno studio di circa e i desideri dei partecipanti ai progetti Fedora, CentOS, RHEL e CPE, sono stati formati i requisiti di funzionalità e la scelta è stata fatta a favore di Gitlab. Oltre alle operazioni standard con i repository (unione, creazione di fork, aggiunta di codice, ecc.), tra i requisiti chiave sono stati indicati la sicurezza, la facilità d'uso e la stabilità della piattaforma.
I requisiti includevano funzionalità come l'invio di richieste push su HTTPS, mezzi per limitare l'accesso alle filiali, supporto per filiali private, separazione dell'accesso per utenti esterni e interni (ad esempio, per lavorare sull'eliminazione delle vulnerabilità durante un embargo sulla divulgazione di informazioni sul problema) , interfaccia di familiarità, unificazione di sottosistemi per lavorare con report 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 alla fine hanno influenzato la decisione di scegliere questa piattaforma, è stato menzionato il supporto per sottogruppi con accesso selettivo ai repository, la possibilità di utilizzare un bot per unioni automatiche (è necessario CentOS Stream per mantenere i pacchetti con il kernel), la presenza di strumenti integrati per la pianificazione dello sviluppo, possibilità di utilizzare un servizio SAAS già pronto con un livello di disponibilità garantito (libererà risorse per il mantenimento dell'infrastruttura server).
La decisione è già critiche tra gli sviluppatori dovute al fatto che la decisione è stata presa senza un'ampia discussione preliminare. Sono state inoltre sollevate preoccupazioni sul fatto che il servizio non utilizzerebbe l'edizione Comminity gratuita di GitLab. In particolare, le funzionalità necessarie per implementare i requisiti per Git Forge descritti nel bando sono disponibili solo nella versione proprietaria .
È stata criticata anche l'intenzione di utilizzare il servizio SAAS (application as a service) fornito da GitLab, invece di implementare GitLab sui propri server, il che porta il servizio fuori controllo (ad esempio, è impossibile essere sicuri che tutte le vulnerabilità in il sistema vengono prontamente eliminati, l'infrastruttura viene mantenuta, un giorno non ci sarà più ed è escluso il sabotaggio da parte di personale di ditta terza). Anche la soluzione non funziona , che specificano che il progetto deve privilegiare alternative libere.
Nel frattempo, GitLab sulla scoperta di implementazioni di 18 funzionalità precedentemente offerte solo nelle edizioni proprietarie di GitLab. Le funzionalità coprono varie aree di gestione dell'intero ciclo di sviluppo del software, tra cui pianificazione dello sviluppo, creazione di progetti, verifica, gestione dei pacchetti, generazione di versioni, configurazione e sicurezza.
Le seguenti funzioni sono state trasferite all'aperto:
- Allegare il problema correlato;
- Esporta il problema da GitLab a CSV;
- Una modalità di pianificazione, organizzazione e visualizzazione del processo di sviluppo di singole funzionalità o rilasci;
- Servizio integrato per connettere i partecipanti al progetto con terze parti tramite e-mail.
- Terminale Web per IDE Web;
- Possibilità di sincronizzare i file per testare le modifiche al codice nel terminale web;
- Controlli di progettazione che ti consentono di caricare modelli e risorse su Issue, utilizzando Issue come unico punto di accesso a tutto ciò di cui hai bisogno per sviluppare una nuova funzionalità;
- Rapporti 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 consente di installare una nuova versione dell'applicazione su una piccola parte dei sistemi;
- Distribuzioni incrementali, che consentono inizialmente di distribuire le nuove versioni solo a un numero limitato di sistemi, aumentando gradualmente la copertura fino al 100%;
- Flag di attivazione delle funzionalità, che permettono di consegnare il progetto in varie edizioni, attivando dinamicamente alcune funzionalità;
- Modalità di panoramica della distribuzione, che consente di valutare lo stato di ciascun ambiente di integrazione continua basato su Kubernetes;
- Supporto per la definizione di più cluster Kubernetes nel configuratore (ad esempio, puoi utilizzare cluster Kubernetes separati per implementazioni di prova e carichi di lavoro);
- Supporto per la definizione di policy di sicurezza della rete di contenitori che consentono di limitare l'accesso tra i pod Kubernetes.
Inoltre si può notare GitLab aggiorna 12.9.1, 12.8.8 e 12.7.8 (Community Edition ed Enterprise Edition), che risolvono la vulnerabilità. Il problema è presente dal rilascio di GitLab EE/CE 8.5 e consente di leggere il contenuto di qualsiasi file locale quando si sposta un problema tra progetti.
I dettagli sulla vulnerabilità verranno divulgati dopo 30 giorni.
Fonte: opennet.ru