Version 13.4 har släppts med HashiCorp-lagring för CI-variabler, Kubernetes Agent och en säkerhetscenter, samt växlande funktioner i Starter.
På GitLab tänker vi alltid på hur vi kan hjälpa användare att minska riskerna, öka effektiviteten och hastigheten på leveransen på din favoritplattform. Den här månaden har vi lagt till en mängd användbara nyheter som utökar säkerhetsmöjligheterna, minskar antalet sårbarheter, ökar effektiviteten, förenklar arbetet med GitLab och hjälper ditt team att leverera nya funktioner ännu snabbare. Vi hoppas att du har nytta av de viktigaste funktionerna i releasen samt 53 andra nya funktioner, som har lagts till i denna release.
Utökade säkerhetsmöjligheter
Vi strävar efter att lägga till flera nya funktioner i GitLab DevSecOps varje månad, och denna release är inget undantag. under bygg- och distributionsprocessen. Dessutom kan organisationer som vill upprätthålla uppdelning av ansvar för koddistribuering nu . Denna roll överensstämmer med och möjliggör godkännande av merge-förfrågningar (i den ryska lokaliserade versionen av GitLab ‘merge-förfrågningar’) och distribution av kod i skyddade miljöer utan att ge tillgång till att ändra själva koden.
Ett annat sätt att minska riskerna är att använda den nya . Driftspersonal kan distribuera Kubernetes-kluster från GitLab utan att behöva öppna tillgång till sitt kluster för hela internet. Vi introducerar också automatisk versionskontroll för nya Terraform-tillståndsfiler med för att stödja efterlevnad och underlätta felsökning. Slutligen har säkerhetspanelen i instansen förvandlats till med rapporter om sårbarheter och säkerhetsinställningar.
Mer bekväm och effektiv arbete med GitLab
Vi har förbättrat vår globala sökning genom att lägga till , vilket gör att du enkelt kan gå till de senaste ärendena, grupperna, projekten, inställningarna och avsnitten i hjälpen. Vi är glada att meddela att GitLab Pages för att omdirigera enskilda sidor och kataloger inom webbplatsen, vilket gör att användarna kan utveckla sina webbplatser mer effektivt. För dem som vill ha mer information om implementering erbjuder denna version !
Öppna källkodsprojekt
Vi presenterar , som lades till av . Anteckningar om kodtäckning för den ändrade koden ger utvecklarna en visuell översikt över kodtäckningen vid granskning; denna information hjälper till att påskynda granskningen och minska tiden för att slå samman och implementera ny kod. Dessutom har vi och planerar .
Och detta är bara början!
Som vanligt finns det för lite utrymme i den allmänna översikten, men det finns många fantastiska funktioner i version 13.4. Här är några fler:
- .
Om du vill veta vad som väntar i nästa version, kolla in .
.
denna månad —
Fabio gjorde ett betydande på — en funktion som har varit länge efterlängtad i GitLab-gemenskapen. Detta är verkligen ett viktigt bidrag med icke-triviala förändringar som krävde konstant samarbete med medlemmarna i GitLab-teamet och berörde många områden av projektet, såsom UX, frontend och backend.
Huvudfunktioner i GitLab-version 13.4
Använd HashiCorp Vault-nycklar i CI-jobb
(PREMIUM, ULTIMATE, SILVER, GOLD)
I version 12.10 presenterade GitLab möjligheten att hämta och överföra nycklar i CI-jobb med GitLab-jobbhanteraren (GitLab runner). Nu utvidgar vi , och lägger till ny syntax secrets till filen .gitlab-ci.yml. Det här kommer att underlätta konfigurationen och användningen av HashiCorp-lagringen med GitLab.
och .
Vi presenterar GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
Integration of GitLab with Kubernetes has long allowed deployments on Kubernetes clusters without the need for manual configuration. Many users have enjoyed the simplicity of using this combination, while others have faced some difficulties. For the current integration, your cluster must be accessible from the internet so that GitLab can access it. For many organizations, this is not feasible as they restrict access to clusters for security, compliance, or regulatory reasons. To bypass these restrictions, users had to create their own tools on top of GitLab; otherwise, they would not be able to use this feature.
Today, we introduce the GitLab Kubernetes Agent – a new way to deploy on Kubernetes clusters. The agent operates inside your cluster, so you won’t need to expose it to the entire internet. The agent coordinates the deployment by requesting new changes from GitLab, instead of GitLab pushing updates to the cluster. Regardless of the GitOps method you are using, GitLab will suit your needs.
Please note that this is the first release of the agent. Currently, we have focused the GitLab Kubernetes Agent on setting up and managing deployment through code. Some existing Kubernetes integration features, such as deployment boards and applications managed by GitLab, are not yet supported. , that these capabilities will be added to the agent in future releases, along with new integrations focused on security and compliance.
och .
Grant users deployment permissions without code access
(PREMIUM, ULTIMATE, SILVER, GOLD)
Previously, the permission system in GitLab did not allow for a clear division of responsibilities within your team between those who are responsible for development and those who handle deployment. With the release of GitLab 13.4, you can grant permission to approve merge requests for deployment, as well as the actual deployment of code to individuals who do not write code, without giving them maintainer access.
och .
Security Center
(ULTIMATE, GOLD)
Tidigare var hanteringen av sårbarheter på instansnivå begränsad både i funktionalitet och flexibilitet. Gränssnittet bestod av en sida som sammanfattade detaljer om sårbarheter, grafiska mätningar och inställningar. Det fanns inte mycket utrymme för att utveckla dessa funktioner eller använda andra säkerhetsverktyg.
Vi har gjort grundläggande förändringar i hanteringen av säkerhet och dess transparens i GitLab. Säkerhetspanelen för instansen har omvandlats till ett helt säkerhetscentrum. Den största förändringen är införandet av en ny menystruktur: istället för en sida ser du nu separata paneler för säkerhetshantering, sårbarhetsrapport och inställningar. Även om funktionaliteten inte har förändrats, möjliggör uppdelningen till förbättringar av denna del, vilket annars skulle vara svårt. Detta skapar också en grund för att lägga till framtida säkerhetsrelaterade funktioner.
Den särskilda delen för sårbarhetsrapporten har nu mer utrymme för att visa viktiga detaljer. Här samlas sårbarheter som för närvarande finns i projektets sårbarhetslista. Flytten av sårbarhetsmetrikwidgets till en separat del skapar en användarvänlig säkerhetspanel. Det här är nu en plattform för framtida visualiseringar — inte bara för att hantera sårbarheter, utan även för alla säkerhetsrelaterade mätningar. Slutligen skapar ett separat inställningsområde ett gemensamt utrymme för alla säkerhetsinställningar på instansnivå, inte bara för hantering av sårbarheter.
och .
Aktiveringsbara funktioner är nu i GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab 11.4 släpptes . I 12.2 introducerade vi strategier för dem och , och i 13.1 lade vi till och för olika miljöer.
Tidigare i år åtagit sig GitLab till öppen källkod. I den här versionen har vi fullföljt flytten av aktiveringsbara funktioner till Starter-planen och kommer att fortsätta överföra dem till Core med . Vi är glada att kunna erbjuda denna möjlighet till fler användare och vill veta hur ni kommer att använda dem.
och .
Snabb navigering från sökfältet
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ibland, när du navigerar i GitLab, vill du direkt gå till ett specifikt projekt istället för till sidan med sökresultat.
Med hjälp av den globala sökpanelen kan du snabbt gå till senaste ärenden, grupper, projekt, inställningar och hjälpavsnitt. Du kan även använda en snabbkommando /, för att flytta markören till sökpanelen, för att navigera ännu effektivare i GitLab!
och .
Visning av kodtäckning i merge requests-diffar
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vid granskning av en merge request kan det vara svårt att avgöra om den ändrade koden täcks av enhetstester. Istället kan granskare förlita sig på den totala täckningen och kräva att den ökar innan de godkänner merge requesten. Detta kan leda till en oorganiserad strategi för att skriva tester, vilket faktiskt inte förbättrar kvaliteten på koden eller dess testtäckning.
Nu, när du granskar diffen av en merge request, kommer du att se en tydlig visning av kodtäckning. Nya markeringar gör det snabbt möjligt att förstå om den ändrade koden täcks av en enhetstest, vilket hjälper till att påskynda kodgranskning och tiden för att sammanfoga och distribuera ny kod.
Tack och Siemens för denna funktion!
och .
Fler miljöer och projekt i miljöpanelen
(PREMIUM, ULTIMATE, SILVER, GOLD)
Sedan GitLab 12.5, med hjälp av , kunde du spåra tillståndet av miljöer, men inte mer än sju miljöer i tre projekt. Vi har förbättrat denna panel i version 13.4, genom att dela upp den i sidor för att hjälpa dig att underhålla och hantera dina miljöer i större skala. Nu kan du se fler miljöer i fler projekt.
och .
GitLab har tagit över hanteringen av GitLab Terraform-leverantören
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nyligen skrev vi och planerar . Under den senaste månaden har vi godkänt 21 merge requests och stängt 31 ärenden, inklusive vissa långvariga buggar och saknade funktioner, som . Du kan i dokumentationen om Terraform.
och .
Fuzzing av API-testning med OpenAPI-specifikationer eller HAR-fil
(ULTIMATE, GOLD)
Fuzzing-testning av API är ett utmärkt sätt att hitta fel och sårbarheter i dina webbapplikationer och API:er som andra skannrar och testmetoder kan missa.
API-fuzzingtestning i GitLab möjliggör att leverera eller för din applikation, och genererar automatiskt slumpmässiga indata som är avsedda för att testa gränsfall och upptäcka fel. Resultaten visas omedelbart inom din pipeline.
Detta är vår första release av API-fuzzingtestning, och vi ser fram emot att höra vad du tycker. Vi har många fler , som vi kommer att basera på denna funktionalitet.
och .
Förhandsvisning av nya diagram på metrics-panelen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Tidigare var det en utmaning att skapa ett diagram på metrics-panelen i GitLab. När du hade skapat en metric i YAML-filen för panelen kunde du göra ändringar i master, utan att kunna kontrollera att det nyss skapade diagrammet fungerade som du behövde. Från och med denna release kan du förhandsgranska ändringar medan du skapar diagrammet, och få insyn i resultatet innan du skickar ändringar till YAML-filen för panelen.
och .
Data om kodtäckning av tester över alla projekt i gruppen
(PREMIUM, ULTIMATE, SILVER, GOLD)
När du hanterar ett stort antal projekt i GitLab behöver du en enhetlig informationskälla om hur kodtäckningen förändras över tid för alla projekt. Tidigare krävde visandet av denna information en tråkig och tidskrävande manuell insats: du var tvungen att ladda ner data om kodtäckning av tester från varje projekt och sammanfoga dem i en tabell.
I release 13.4 kom möjligheten att enkelt och snabbt sammanställa all .csv data om kodtäckning från alla projekt i gruppen eller från en urval av projekt. Denna funktion är en MVC, och en kommande funktionalitet .
och .
Stöd för nya språk för fullständig fuzzingtestning
(ULTIMATE, GOLD)
Denna release introducerar stöd för flera nya språk för fuzzingtestning som syftar till fullständig täckning.
Nu kan du utvärdera alla möjligheter för fuzzingtester i dina applikationer på Java, Rust och Swift och hitta fel och sårbarheter som andra skannrar och testmetoder kanske missar.
och .
Aviseringar på startsidan av miljöer
(PREMIUM, ULTIMATE, SILVER, GOLD)
Miljösidan visar det övergripande tillståndet för dina miljöer. I denna release har vi förbättrat denna sida genom att lägga till visning av aviseringar. Utlösta aviseringar tillsammans med statusen för dina miljöer hjälper dig att snabbare vidta åtgärder för att åtgärda eventuella problem.
och .
Inbäddade pipelines kan nu köra sina inbäddade pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Med inbäddade pipelines har det blivit möjligt att köra nya pipelines inom barnpipelines. En ytterligare nivå av djup kan vara användbar om du behöver flexibilitet för att generera ett varierande antal pipelines.
Tidigare, när du använde inbäddade pipelines, krävde varje barnpipeline en trigger-uppgift, manuellt angiven i föräldrapipelinen. Nu kan du skapa inbäddade pipelines som dynamiskt startar ett godtyckligt antal nya inbäddade pipelines. Till exempel, om du har ett monorepo kan du dynamiskt generera den första inbäddade pipelinen, som själv skapar det nödvändiga antalet nya pipelines baserat på ändringar i grenen.
och .
Förbättrad navigering mellan föräldra- och inbäddade pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Det var tidigare inte särskilt bekvämt att navigera mellan föräldra- och inbäddade pipelines — det krävdes många klick för att nå den önskade pipelinen. Det var också svårt att förstå vilken specifik uppgift som startade denna pipeline. Nu har det blivit mycket lättare att se sambanden mellan förälder- och inbäddade pipelines.
och .
Parallella matrisuppgifter visar relevanta variabler i uppgiftsnamnet
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Om du har använt , kan du ha märkt att det var svårt att avgöra vilken matrisvariabel som användes för en specifik uppgift, eftersom uppgiftsnamnen såg ut som matrix 1/4. I version 13.4 kommer du att se relevanta värden för variabler som har använts i denna uppgift istället för den generella uppgiftsnamnet. Om ditt mål är att debugga för x86-arkitekturen kommer uppgiften att kallas matrix: debug x86.
och .
Andra förbättringar i GitLab 13.4
Ansluta Atlassian-konto
(CORE, STARTER, PREMIUM, ULTIMATE)
GitLab-användare kan nu koppla sina GitLab-konton till sitt Atlassian Cloud-konto. Detta möjliggör inloggning till GitLab med Atlassian-uppgifter och lägger grunden för framtida förbättringar i integrationen och andra produkter från Atlassian-serien.
och .
Exportera lista över alla merge-commits
(ULTIMATE, GOLD)
Organisationer som strävar efter efterlevnad behöver ett sätt att visa revisorer en helhetsbild av komponenter relaterade till varje specifik ändring i produktion. Inom GitLab innebär detta att allt: merge-förfrågningar, biljetter, pipeliner, säkerhetsskanningar och annan commit-information behöver samlas på ett ställe. Tidigare har du varit tvungen att antingen manuellt samla detta i GitLab eller ställa in dina verktyg för att samla information, vilket inte var särskilt effektivt.
Nu kan du programmässigt samla och exportera dessa data för att uppfylla revisionskrav eller utföra andra analyser. För att exportera lista över alla merge-commits för den aktuella gruppen behöver du gå till och klicka på knappen Lista över alla merge-commits. Den resulterande filen kommer att innehålla alla commits för merge-förfrågan, deras författare, ID för den relaterade merge-förfrågan, grupp, projekt, bekräftande och annan information.
och .
Visa lista och hantera personliga åtkomsttoken via API
(ULTIMATE, GOLD)
Hantera åtkomst till GitLab-namnrymden är en viktig del av efterlevnad. Från principer om minimi-behörigheter till att inaktivera åtkomst med tidsinställningar – det kan finnas olika krav relaterade till personliga åtkomsttoken i GitLab. För att underlätta hanteringen av dessa användardata inom din namnrymden har vi tillhandahållit möjligheten att visa en lista över alla personliga åtkomsttoken och valfritt via API.
Dessa förbättringar i GitLab API gör det möjligt för användare att lista och återkalla sina egna personliga åtkomsttoken, och för administratörer att lista och återkalla sina användares token. Nu blir det enklare för administratörer att se vilka som har åtkomst till deras namnrymder, fatta beslut om att ge åtkomst baserat på användardata samt återkalla personliga åtkomsttoken som kan ha blivit komprometterade eller som överskrider företagets åtkomsthanteringsregler.
och .
Relaterade ärenden och andra funktioner nu i GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
För några månader sedan tillkännagav vi en plan för . När vi arbetar med att uppfylla detta löfte har vi gjort , och (i den ryska lokalisationen av GitLab "diskussionskort") tillgängliga i Core-planen. Detta gäller endast relationer av typen "relaterad till", relationer av typen "blockerar" och "blockeras" förblir i betalda planer.
och .
Visar namnet på den ursprungliga grenen i sidofältet för merge-förfrågan
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vid granskning av kodändringar, diskussioner och commits i merge-förfrågan är det ofta önskvärt att göra en lokal checkout av grenen för en djupare granskning. Men att hitta grenens namn blir allt svårare ju mer innehåll som läggs till i beskrivningen av merge-förfrågan, och man måste scrolla längre ner på sidan.
Vi har lagt till grenens namn på sidofältet för merge-förfrågan, vilket gör det tillgängligt när som helst och slipper behovet av att bläddra igenom hela sidan. Precis som länken till merge-förfrågan innehåller avsnittet med den ursprungliga grenen en praktisk "kopiera"-knapp.
Tack för det stora bidraget i utvecklingen av denna funktion!
och .
Ange förekomsten av dolda filer i diffs av merge-förfrågan
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Merge-förfrågningar som lägger till ändringar till flera filer döljer ibland differenser i stora filer för att förbättra prestandan. När detta händer kan man av misstag missa en fil under granskningen, särskilt i merge-förfrågningar med ett stort antal filer. Från och med version 13.4 kommer merge-förfrågningar att markera differenser som innehåller dolda filer, vilket gör att du inte missar dessa filer i granskningen av koden. För ännu större tydlighet planerar vi att lägga till belysning av dessa filer i en framtida release. Håll utkik efter uppdateringar i .
och .
Varning för dolda filer i differensen av merge-förfrågan
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
I sektionen med differenser i merge-förfrågningar döljs stora filer för att öka prestandan. Men vid granskning av koden kan vissa filer missas när granskaren bläddrar igenom filerna, eftersom alla stora filer är dolda.
Vi har lagt till en synlig varning högst upp på sidan med merge-förfrågans differens för att informera användarna om att det finns en dold fil i denna sektion. På så sätt missar du inga ändringar i merge-förfrågan under granskningen.
och .
Automatisk återställning av Gitaly-klusterarkivet
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Tidigare, när den primära noden i Gitaly-klustret stängdes av, markerades arkiven på denna nod som skrivskyddade. Detta förhindrade dataförlust i situationer där det fanns ändringar på noden som ännu inte var replikerade. När noden återanslöts återställdes inte GitLab automatiskt, och administratörer var tvungna att manuellt starta synkroniseringsprocessen eller acceptera dataförlust. Detta kunde även leda till föråldrade eller skrivskyddade arkiv under andra situationer, såsom avbrott i replikationsuppdrag på den sekundära noden. I sådana fall förblev arkivet föråldrat tills nästa skrivoperation utfördes som startade replikationsuppdraget.
För att lösa detta problem Nu planerar den en replikationsuppgift när den upptäcker ett föråldrat repository på en nod och den senaste versionen av repositoryt på en annan. Denna replikationsuppgift gör repositoryt aktuellt automatiskt, vilket eliminerar behovet av att återställa data manuellt. Automatisk återställning möjliggör också en snabb uppdatering av sekundära noder om replikationsuppgiften misslyckas, istället för att vänta på nästa skrivoperation. Eftersom många Gitaly-kluster lagrar ett stort antal repositories minskar detta avsevärt den tid administratörer och ingenjörer för driftsäkerhet lägger på att återställa data efter fel.
Dessutom startar automatisk reparation replikationen av repositories på varje ny Gitaly-nod som läggs till i klustret, vilket eliminerar manuell hantering vid tillägg av nya noder.
och .
Markera to-do-uppgiften som genomförd på designsidan
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Effektiv kommunikation i GitLab bygger på to-do-listor. Om du nämns i en kommentar är det avgörande att ha möjlighet att gå till uppgiften och antingen börja arbeta med den eller markera den som redan genomförd. Det är också viktigt att kunna tilldela en uppgift till sig själv när du behöver arbeta med något eller återkomma till det senare.
Tidigare kunde du inte lägga till uppgifter eller markera dem som genomförda när du arbetade med designer. Detta allvarligt störde effektiviteten i kommunikationen mellan produktteam, eftersom to-do-uppgifter är en avgörande del av arbetsflödet i GitLab.
I version 13.4 följer designer kommentarer till biljettuppgifter i användningen av uppgifter, vilket gör arbetet med dem mer konsekvent och effektivt.
och .
Förbättrad felsökningsguide för CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vi har förbättrat felsökningsguiden för GitLab CI/CD genom att lägga till ytterligare information om vanliga problem som du kan stöta på. Vi hoppas att den förbättrade dokumentationen kommer att vara en värdefull resurs som hjälper dig att snabbt och enkelt konfigurera och köra GitLab CI/CD.
och .
Merge-förfrågningar faller inte längre ur köerna för sammanslagning
(PREMIUM, ULTIMATE, SILVER, GOLD)
Tidigare kunde merge-förfrågningar av misstag fallas ur köerna för sammanslagning på grund av sena kommentarer. Om en merge-förfrågan redan var i kön och någon la till en kommentar som skapade en ny olöst diskussion, ansågs merge-förfrågan ogiltig för sammanslagning och föll ur kön. Nu, efter att merge-förfrågan har lagts till i kön för sammanslagning, kan nya kommentarer läggas till utan att riskera att störa sammanslagningsprocessen.
och .
Visar värdet av kodtäckning i merge-förfrågan för uppgiften
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Utvecklare bör kunna se värdet av kodtäckning efter att pipelinen har avslutats — även i komplexa scenario, såsom när pipelinen arbetar med flera uppgifter som måste parsas för att beräkna täckningsvärdet. Tidigare visade widgeten för merge-förfrågan endast medelvärdet av dessa värden, vilket innebar att du var tvungen att navigera till sidan för uppgiften och tillbaka till merge-förfrågan för att få de delade täckningsvärdena. För att spara din tid och eliminera dessa onödiga steg har vi gjort widgeten som visar medelvärdet av täckning, dess förändring mellan mål- och ursprungsgrenarna och en tooltip som visar täckningsvärdet för varje uppgift, baserat på vilket medelvärdet beräknades.
och .
Ta bort paket från paketregistret när du visar en grupp
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab:s paketregister är en plats för lagring och distribution av paket i olika format. När ditt projekt eller din grupp har många paket är det viktigt att snabbt identifiera oanvända paket och ta bort dem så att folk inte laddar ner dem. Du kan ta bort paket från ditt register via eller genom användargränssnittet för paketregistret. Men hittills har du inte kunnat ta bort paket när du visat en grupp via användargränssnittet. Som ett resultat har du varit tvungen att ta bort oönskade paket separat för varje projekt, vilket har varit ineffektivt.
Nu kan du ta bort paket när du visar paketregistret för gruppen. Gå bara till sidan för paketregistret för gruppen, filtrera paketen efter namn och ta bort alla onödiga.
och .
Skalning av Conan-paket till projektnivå
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Du kan använda Conan-repositoriet i GitLab för att publicera och distribuera C/C++-beroenden. Tidigare kunde paket bara skalas upp till instansnivå, eftersom ett Conan-pakets namn kunde bestå av högst 51 tecken. Om du ville publicera ett paket från en undergrupp, till exempel gitlab-org/ci-cd/package-stage/feature-testing/conan, var det nästan omöjligt att göra.
Nu kan du skala Conan-paket till projektnivå, vilket gör det enkelt att publicera och distribuera beroenden för dina projekt.
och .
Stöd för nya pakethanterare och språk för att skanna beroenden
(ULTIMATE, GOLD)
Vi är glada över att lägga till beroendeskanning för projekt med kod i C, C++, C# och .Net, som använder NuGet 4.9+ eller Conan-pakethanterare, till vår lista . Nu kan du inkludera beroendeskanning som en del av säkerhetssteget för att kontrollera kända sårbarheter i beroenden som lagts till via pakethanterare. Upptäckta sårbarheter visas i din merge-begäran tillsammans med deras risknivå, så att du vet vilka risker den nya beroenden innebär innan merget genomförs. Du kan också ställa in ditt projekt så att det kräver för beroenden med sårbarheter med kritisk (Critical), hög (High) eller okänd (Unknown) risknivå.
och .
Notiser vid ändring av merge-begärans inställning till 'Mergas vid lyckad pipeline'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Tidigare skickades det inga e-postmeddelanden vid inställningen av merge-begäran Mergas när pipeline är klar (Merge When Pipeline Succeeds, MWPS). Du var tvungen att manuellt kolla status eller vänta på att få meddelande om avslutat merge. I denna version är vi glada över att presentera användarbidraget , som löste detta problem genom att lägga till automatisk sändning av notifikationer till alla som är prenumererade på merge-begäran när granskaren ändrar merge-inställningen till MWPS.
och .
Skapa EKS-kluster med användardefinierad Kubernetes-version
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab-användare kan nu själva välja vilken version av Kubernetes som ska tillhandahållas av EKS; du kan välja mellan versionerna 1.14–1.17.
och .
Skapa incidenter som tickettyper
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Inte varje problem som uppstår leder omedelbart till att aviseringar skickas: användare rapporterar om driftstopp, och teammedlemmar sorterar ut prestandaproblem. Nu är incidenter en typ av ticket, så dina team kan snabbt skapa dem inom den vanliga arbetsflödet. Klicka Ny uppgift från vilken plats som helst i GitLab, och i fältet Typ välj Incident.
och .
Nämning av GitLab-aviseringar i Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vi har förbättrat GitLab-aviseringar genom att lägga till en ny typ av nämnande speciellt för dem i GitLab-versionen av Markdown, vilket gör det enklare att dela aviseringar och nämna dem. Använd ^alert#1234, för att nämna en avisering i vilket fält som helst med Markdown-format: i incidenter, tickets eller merge-förfrågningar. Detta kommer också att hjälpa dig att identifiera uppgifter som skapas från aviseringar, snarare än från tickets eller merge-förfrågningar.
och .
Visning av belastning för aviseringar av incidenter
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beskrivningen av aviseringen innehåller information som är kritiskt viktig för att diagnostisera driftstopp och återskapa, och denna information bör vara lätt tillgänglig så att du inte behöver växla mellan verktyg eller flikar när du arbetar med att lösa incidenten. Incidenter som skapats från aviseringar visar den fullständiga beskrivningen av aviseringen i fliken Alert Details.
75% snabbare avancerad sökning
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab, som en enhetlig applikation, har en unik möjlighet att göra sökningen av innehåll genom hela DevOps-arbetsflödet snabb. I GitLab 13.4 ger den avancerade sökningen resultat 75% snabbare när den , som på GitLab.com.
och .
Visning av borttagna projekt för administratörer
(CORE, STARTER, PREMIUM, ULTIMATE)
Möjligheten att skjuta upp borttagningen av ett projekt infördes Men tidigare fanns det ingen möjlighet att se alla projekt som väntade på borttagning på ett enda ställe. Nu kan administratörer av användarinstanser i GitLab se alla projekt som väntar på borttagning på ett och samma ställe – tillsammans med knappar för enkel återställning av dessa projekt.
Denna funktion gör det möjligt för administratörer att bättre kontrollera borttagning av projekt genom att samla all nödvändig information på ett ställe och erbjuda möjligheten att ångra oönskade borttagningsåtgärder.
Tack för denna funktion!
och .
API:t har fått stöd för pushregler för grupper
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Tidigare kunde gruppers pushregler endast konfigureras genom att besöka varje grupp individuellt via GitLab:s användargränssnitt och tillämpa dessa regler. Nu kan du hantera dessa regler via API:t för att stödja dina användaranpassade verktyg och automatisera GitLab.
och .
Återkalla personliga åtkomsttoken för egenförvaltade hemlagringslösningar
(ULTIMATE)
ger administratörer den information som behövs för att hantera användardata i deras GitLab-instanser. Eftersom organisationer som är inriktade på efterlevnad varierar i striktheten av sina datastyrningsregler, har vi lagt till en knapp som gör det möjligt för administratörer att återkalla en användares personliga åtkomsttoken (PAT) om så önskas. Nu kan administratörer enkelt återkalla potentiellt komprometterade PAT. Denna funktion är användbar för organisationer som behöver mer flexibla alternativ för att säkerställa efterlevnad och minimera störningar för sina användare.
och .
Konfigurationsfil för statisk webbplatsredigerare
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
I GitLab 13.4 introducerar vi ett nytt sätt att konfigurera statiska webbplatsredigeraren. Även om konfigurationsfilen inte sparar eller hämtar några parametrar i denna version, lägger vi grunden för framtida justeringar av redigerarens beteende. I kommande versioner kommer vi att lägga till i filen .gitlab/static-site-editor.yml parametrar för att ställa in , där , överskrivning av Markdown-syntaxinställningar och andra redigeringsinställningar.
och .
Redigering av inledande del av filen med hjälp av den statiska webbplatsredigeraren
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Inledande del (front matter) är ett flexibelt och praktiskt sätt att definiera sidvariabler i datafiler avsedda för behandling av statiska webbplatsgeneratorer. Den används vanligtvis för att ställa in sidrubrik, mall eller författare, men kan även användas för att överföra all typ av metadata till generatorn vid rendering av sidan i HTML. Inkluderad högst upp i varje datafil, formateras inledande del vanligtvis som YAML eller JSON och kräver en konsekvent och noggrann syntax. Användare som är obekanta med de specifika syntaxreglerna kan oavsiktligt införa ogiltig markup, vilket kan leda till formateringsproblem eller till och med kompileringstopp.
WYSIWYG-redigeringsläget för den statiska webbplatsredigeraren döljer redan den inledande delen i redigeraren för att förhindra dessa formateringsfel. Men det hindrar dig från att ändra värdena som lagras i denna del utan att återgå till redigering i källkods-läge. I GitLab 13.4 kan du få åtkomst till vilket fält som helst och redigera sitt värde i en välbekant formulärbaserad gränssnitt. När du klickar på knappen Inställningar (Inställningar) öppnas en panel som visar formulärfält för varje nyckel som definierades i början. Fälten fylls med det aktuella värdet, och för att redigera något av dem behöver man bara skriva in det i webbformuläret. Sådan redigering av inledande del gör det möjligt att undvika komplicerade syntaxproblem och ger dig full kontroll över innehållet, samtidigt som det säkerställer enhetlig formatering av det slutliga resultatet.
och .
GitLab för Jira och DVCS Connector nu i Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
För Jira-användare i GitLab: och möjliggör visning av information om commits och merge-förfrågningar från GitLab direkt i Jira. Tillsammans med vår inbyggda integration med Jira kan du enkelt navigera mellan de två applikationerna under arbetets gång.
Dessa funktioner var tidigare endast tillgängliga i vår Premium-plan, men nu är de tillgängliga för alla användare!
och .
Röstning med majoritet för Gitaly-klustertransaktioner (beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Gitaly-klustret möjliggör replikering av Git-repositorier till flera "varma" Gitaly-noder. Detta ökar tillgängligheten genom att eliminera enskilda felpunkter. , presenterade i GitLab 13.3, initierar en sändning av ändringar till alla Gitaly-noder i klustret, men endast de Gitaly-noder som röstar för att godkänna förändringar från den primära noden sparar ändringarna på disk. Om inte alla replikanoder når enighet kommer endast en kopia av ändringen att sparas på disk, vilket skapar en enskild felpunkt fram tills den asynkrona replikeringen är fullföljd.
Röstning med majoritet ökar tillgängligheten genom att kräva enighet från majoriteten av noderna (och inte alla) innan ändringar sparas på disk. Om denna växlingsbara funktion är aktiverad måste registreringen lyckas på flera noder. Oeniga noder synkroniseras automatiskt via asynkron replikering med de noder som bildar kvorum.
och .
Stöd för användardefinierad schema för validering av JSON i Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Projekt där människor skriver konfigurationer i JSON- eller YAML-format är ofta utsatta för problem eftersom det är lätt att göra ett skrivfel och bryta något. Det går att skriva valideringsverktyg för att fånga dessa problem i CI-pipelinen, men att använda en JSON-schemasfil kan vara användbart för att tillhandahålla dokumentation och tips.
Projektmedlemmar kan definiera i deras repository sökvägen till användarschemat i filen .gitlab/.gitlab-webide.yml, som anger schemat och sökvägen till filerna för validering. När en specifik fil laddas upp i Web IDE kommer ytterligare återkoppling och validering att visas för att hjälpa till att skapa filen.
och .
Gränsen för förgrening av riktat acykliskt diagram (DAG) har ökat till 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Om du använder pipelines (Directed Acyclic Graph (DAG)), har du kanske märkt att begränsningen på 10 uppgifter som en uppgift kan ange i needs:, alltför strikt. I version 13.4 ökades standardgränsen från 10 till 50 för att möjliggöra mer komplexa nätverk av beroenden mellan uppgifterna i dina pipelines.
Om du är administratör för en användarininstans av GitLab kan du höja denna gräns ytterligare genom att konfigurera en växelfunktion, även om vi inte erbjuder officiellt stöd för detta.
och .
Förbättrat beteende needs för missade uppgifter.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
I vissa fall kunde en missad uppgift i pipelinen felaktigt betraktas som lyckad för de beroenden som angavs i needs, vilket ledde till att efterföljande uppgifter kördes, vilket inte borde ha inträffat. Detta beteende har åtgärdats i version 13.4, och needs hanterar nu korrekt fallen med missade uppgifter.
och .
Säkra den senaste artefakten av uppgiften för att förhindra att den raderas.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab blockerar nu automatiskt den senaste artefakten av en lyckad uppgift och pipeline på vilken aktiv gren, merge-begäran eller tagg som helst för att förhindra att den raderas efter utgång. Det blir enklare att sätta mer aggressiva utgångsregler för att rensa gamla artefakter. Detta hjälper till att minska lagringsutrymmet och säkerställer att du alltid har en kopia av den senaste artefakten från pipelinen.
och .
Guide för CI/CD för att optimera pipelines.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Att optimera CI/CD-pipelinen kan öka leveranshastigheten och spara pengar. Vi har förbättrat vår dokumentation genom att lägga till en kort guide för att få maximal avkastning på att optimera dina pipelines.
och .
Testningsrapport sorterad efter teststatus.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— är ett enkelt sätt att se resultaten av alla tester i kedjan. Men med ett stort antal tester kan det ta mycket tid att hitta misslyckade tester. Andra problem som kan göra det svårt att använda rapporten inkluderar svårigheter med att rulla igenom långa spårningars utdata och avrundning av tiden till noll för tester som tar mindre än 1 sekund. Nu sorterar standardtestrapporten misslyckade tester först i rapporten och sorterar sedan tester efter varaktighet. Detta förenklar sökandet efter fel och långvariga tester. Dessutom visas nu varaktigheten för tester i millisekunder eller sekunder, vilket gör det mycket snabbare att läsa dem, och tidigare problem med rullning har också åtgärdats.
och .
Filstorleksbegränsningar för filer som laddas upp till paketregistret
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Det finns nu begränsningar för filstorlekar på paket som kan laddas upp till GitLabs paketregister. Begränsningarna har lagts till för att optimera prestanda för paketregistret och förhindra missbruk. Begränsningarna beror på paketformatet. För GitLab.com är de maximala filstorlekarna:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
För användarinstanser av GitLab är standardvärdena desamma. Men administratören kan uppdatera begränsningarna via .
och .
Använd CI_JOB_TOKEN för att publicera paket på PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Du kan använda GitLab PyPI-repositoryt för att skapa, publicera och dela Python-paket tillsammans med källkoden och CI/CD-pipelines. Tidigare kunde du dock inte autentisera dig mot repositoryt med en fördefinierad miljövariabel CI_JOB_TOKEN. Som ett resultat var du tvungen att använda dina personliga uppgifter för att uppdatera PyPI-repositoryt, eller så bestämde du dig kanske för att inte använda repositoryt överhuvudtaget.
Det har nu blivit enklare att använda GitLab CI/CD för att publicera och installera paket på PyPI med hjälp av en fördefinierad miljövariabel CI_JOB_TOKEN.
och .
DAST-skannerprofiler på begäran
(ULTIMATE, GOLD)
För DAST-skanning på begäran, som har , profiler av DAST-skanneren har lagts till. De utökar konfigurationsmöjligheterna för denna skanning, vilket gör att du snabbt kan skapa flera profiler för att täcka flera typer av skanning. I version 13.4 inkluderar skannerprofilen ursprungligen en timeoutparameter för sökroboten, som ställer in hur länge DAST-sökroboten ska arbeta när den försöker upptäcka alla sidor på den skannade webbplatsen. Profilen inkluderar också en timeoutparameter för den målsatta webbplatsen, för att ange hur länge skannern ska vänta på att webbplatsen ska bli tillgänglig innan den avbryter skanningen om webbplatsen inte svarar med statuskod 200 eller 300. Allteftersom vi fortsätter att förbättra denna funktion i kommande versioner kommer ytterligare konfigurationsparametrar att läggas till skannerprofilen.
och .
En enkel konfigurationsfil för omdirigeringar för GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Om du använder GitLab Pages och vill hantera URL-förändringar bättre, har du kanske märkt att det har varit omöjligt att hantera omdirigeringar på din GitLab Pages-webbplats. GitLab gör det nu möjligt för dig att konfigurera regler för att omdirigera en URL till en annan för din Pages-webbplats genom att lägga till en konfigurationsfil i ditt repo. Denna funktion blev möjlig tack vare deltagande från Kevin Barnett (), vår Eric Eastwood () och GitLab-teamet. Tack till alla för ert bidrag.
och .
Terraform-status, hanterad av GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Tillgång till tidigare versioner av Terraform-status är nödvändig både för att uppfylla krav och för felsökning vid behov. Stöd för versionshantering av Terraform-status, hanterad av GitLab, tillhandahålls från och med GitLab 13.4. Versionshantering aktiveras automatiskt för nya Terraform-statusfiler. Befintliga Terraform-statusfiler kommer att i en senare version.
och .
Viktiga detaljer om incidentmeddelanden
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
När man hanterar incidenter behöver man enkelt kunna se hur länge en varning har varit öppen och hur många gånger ett händelse har inträffat. Dessa detaljer är ofta avgörande för att bestämma påverkan på kunden och vad ert team bör fokusera på först. På den nya incidentdetaljpanelet visar vi starttid för varningen, antal händelser och en länk till den ursprungliga varningen. Denna information är tillgänglig för incidenter som skapas från varningar.
och .
Inställning och redigering av incidenternas allvarlighetsgrad
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Inställningen för "incidenternas allvarlighetsgrad" gör det möjligt för reaktionsspecialister och intressenter att avgöra konsekvenserna av driftstopp och metoder och brådska för reaktion. När ert team delar sina resultat under incidenthanteringen och återställer driften kan de ändra denna inställning. Nu kan ni redigera allvarlighetsgraden på den högra sidopanelen på sidan "Incidentdetaljer", och allvarlighetsgraden visas i incidentlistan.
och .
Skapa, redigera och ta bort nätverkssäkerhetsregler för containrar
(ULTIMATE, GOLD)
Denna förbättrade redigerare för nätverkssäkerhetsregler för containrar gör det möjligt för användare att enkelt skapa, redigera och ta bort sina regler direkt från GitLab:s användargränssnitt. Redigerarens funktioner inkluderar läget .yaml för erfarna användare och en regelredigerare med ett intuitivt gränssnitt för dem som är mindre bekanta med nätverksregler. Ni kan hitta nya möjligheter för regelhantering i avsnittet Säkerhet och efterlevnad > Hot hantering > Regler (Security & Compliance > Threat Management > Policies).
och .
Stöd för Azure blob-lagring
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Både GitLab och GitLab Runner stöder nu , vilket förenklar körningen av GitLab-tjänster i Azure.
GitLab-instanser stöder Azure för alla typer av objektlagring, inklusive LFS-filer, CI-artiklar och . För att konfigurera Azure blob-lagring, följ installationsanvisningarna för eller .
GitLab-jobbhanterare stöder också Azure för lagring av Azure-lagring kan konfigureras via sektionen .
och .
Omnibus-paket för ARM64 för Ubuntu och OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
Som svar på den växande efterfrågan på stöd för att köra GitLab på 64-bitars ARM-arkitektur är vi glada att kunna meddela tillgången på det officiella ARM64 Ubuntu 20.04 Omnibus-paketet. Stort tack till Zitai Chen och Guillaume Gardet för deras stora bidrag – deras merge-förfrågningar spelade en avgörande roll i detta!
För att ladda ner och installera paketet för Ubuntu 20.04, besök vår och välj Ubuntu.
och .
Stöd för autentisering med smartkort för GitLab Helm-diagram
(PREMIUM, ULTIMATE)
Smartkort, som gemensamma kort (CAC), kan nu användas för autentisering i en GitLab-instans som distribueras via Helm-diagram. Smartkort autentiseras i den lokala databasen med hjälp av X.509-certifikat. Detta gör att stödet för smartkort i Helm-diagram nu överensstämmer med stödet för smartkort som finns i Omnibus-distributioner.
och .
Detaljerade versionsanteckningar och installations-/uppdateringsanvisningar kan läsas i det ursprungliga engelskspråkiga inlägget: .
Översättningen från engelska gjordes av , , och .
Källa: habr.com
