Fedora och CentOS kör Git Forge. GitLab öppnar 18 proprietära funktioner

Projekt CentOS и fedora rapporterade om beslutet att skapa en samarbetsutvecklingstjänst Git Forge, som kommer att byggas med hjälp av GitLab-plattformen. GitLab kommer att bli den primära plattformen för att interagera med Git-förråd och för att vara värd för projekt relaterade till CentOS- och Fedora-distributioner. Tidigare använd tjänst pagura kommer att finnas kvar, men överlämnas till en gemenskap som är intresserad av fortsatt utveckling. Pagure kommer att tas bort från stödet från CPE-teamet (Community Platform Engineering) som är anställd på Red Hat, som är engagerat i att underhålla infrastrukturen för utveckling och publicering av Fedora- och CentOS-utgåvor.

När vi utvärderade möjliga lösningar för nya Git Forge, övervägde vi
Pagure och Gitlab. Baserat på en studie av ca 300 recensioner och önskemål från deltagare i Fedora-, CentOS-, RHEL- och CPE-projekten, funktionskrav utformades och valet gjordes till förmån för Gitlab. Förutom standardoperationer med repositories (sammanfoga, skapa gafflar, lägga till kod etc.), angavs säkerhet, användarvänlighet och stabilitet för plattformen bland nyckelkraven.

Kraven inkluderade funktioner som att skicka push-förfrågningar över HTTPS, sätt att begränsa åtkomst till filialer, stöd för privata filialer, åtskillnad av åtkomst för externa och interna användare (till exempel för att arbeta med att eliminera sårbarheter under ett embargo mot att avslöja information om problemet) , förtrogenhetsgränssnitt, enande av delsystem för att arbeta med problemrapporter, kod, dokumentation och planering av nya funktioner, tillgänglighet av verktyg för integration med IDE, stöd för standardarbetsflöden.

Av GitLab-funktionerna som i slutändan påverkade beslutet att välja denna plattform, nämndes stöd för undergrupper med selektiv åtkomst till arkiv, möjligheten att använda en bot för automatiska sammanslagningar (CentOS Stream krävs för att underhålla paket med kärnan), närvaro av inbyggda verktyg för planering av utveckling, möjligheten att använda en färdig SAAS-tjänst med en garanterad tillgänglighetsnivå (kommer att frigöra resurser för att underhålla serverinfrastrukturen).

Beslutet är redan orsakade kritik bland utvecklare på grund av att beslutet togs utan omfattande förhandsdiskussion. Det väcktes också oro för att tjänsten inte skulle använda den kostnadsfria Comminity-utgåvan av GitLab. Speciellt de funktioner som krävs för att implementera kraven för Git Forge som beskrivs i tillkännagivandet är endast tillgängliga i den proprietära versionen GitLab Ultimate.

Avsikten att använda SAAS-tjänsten (application as a service) tillhandahållen av GitLab, istället för att distribuera GitLab på sina servrar, kritiserades också, vilket tar tjänsten utom kontroll (det är till exempel omöjligt att vara säker på att alla sårbarheter i systemet elimineras omedelbart, ordentligt infrastruktur upprätthålls, en dag kommer det att finnas nr telemetri påtvingad och sabotage av personal från ett tredjepartsföretag är uteslutet). Lösningen fungerar inte heller med Fedoras grundprinciper, som anger att projektet måste ge företräde åt gratisalternativ.

Under tiden, GitLab tillkännagav om upptäckten av implementeringar av 18 funktioner som tidigare endast erbjudits i proprietära utgåvor av GitLab. Förmågan täcker olika områden för att hantera hela mjukvaruutvecklingscykeln, inklusive utvecklingsplanering, projektskapande, verifiering, pakethantering, releasegenerering, konfiguration och säkerhet.

Följande funktioner har överförts till det fria utbudet:

  • Bifogar relaterad fråga;
  • Exportproblem från GitLab till CSV;
  • Ett sätt att planera, organisera och visualisera utvecklingsprocessen för individuella funktioner eller releaser;
  • Inbyggd tjänst för att koppla projektdeltagare med tredje part via e-post.
  • Webbterminal för webb-IDE;
  • Möjlighet att synkronisera filer för att testa ändringar i kod i webbterminalen;
  • Designkontroller som låter dig ladda upp mockups och tillgångar till utfärdandet, genom att använda problemet som en enda åtkomstpunkt till allt du behöver för att utveckla en ny funktion;
  • Kodkvalitetsrapporter;
  • Stöd för pakethanterare Conan (C/C++), Maven (Java), NPM (node.js) och NuGet (.NET);
  • Stöd för kanariefågelinstallationer, så att du kan installera en ny version av programmet på en liten del av systemen;
  • Inkrementella distributioner, som gör att nya versioner kan levereras till endast ett litet antal system först, vilket gradvis ökar täckningen till 100 %;
  • Funktionsaktiveringsflaggor, som gör det möjligt att leverera projektet i olika upplagor, dynamiskt aktivera vissa funktioner;
  • Översiktsläge för distribution, som låter dig bedöma tillståndet för varje kontinuerlig integrationsmiljö baserat på Kubernetes;
  • Stöd för att definiera flera Kubernetes-kluster i konfiguratorn (du kan till exempel använda separata Kubernetes-kluster för testimplementeringar och arbetsbelastningar);
  • Stöd för att definiera säkerhetspolicyer för containernätverk som gör att du kan begränsa åtkomst mellan Kubernetes-poddar.

Dessutom kan det noteras offentliggörande GitLab uppdaterar 12.9.1, 12.8.8 och 12.7.8 (Community Edition och Enterprise Edition), som fixar sårbarheten. Problemet har funnits sedan lanseringen av GitLab EE/CE 8.5 och gör att innehållet i alla lokala filer kan läsas när ett problem flyttas mellan projekt.
Detaljer om sårbarheten kommer att avslöjas efter 30 dagar.

Källa: opennet.ru

Lägg en kommentar