Udgivelse 13.4 udgivet med HashiCorp-lager til CI-variabler, Kubernetes Agent og sikkerhedscenter og omskiftelige funktioner i Starter
Hos GitLab tænker vi altid på, hvordan du kan hjælpe brugere med at mindske risici, forbedre effektiviteten og levere hurtigere på din yndlingsplatform. Denne måned har vi tilføjet en masse fantastiske nye funktioner, der forbedrer sikkerheden, reducerer sårbarheder, forbedrer effektiviteten, gør GitLab nemmere at bruge og hjælper dit team med at levere funktioner endnu hurtigere. Vi håber, at du vil finde udgivelsens hovedfunktioner nyttige, såvel som 53 andre nye funktionertilføjet i denne udgivelse.
Avancerede sikkerhedsfunktioner
Vi forsøger at tilføje et par nye funktioner til GitLab DevSecOps hver måned, og denne udgivelse er ingen undtagelse. under montering og ibrugtagning. Derudover kan organisationer, der ønsker at støtte adskillelse af kodeimplementeringsopgaver nu . Denne rolle svarer og vil give dig mulighed for at bekræfte fusionsanmodninger (i den russiske lokalisering af GitLab, "fletanmodninger") og implementere kode i sikre miljøer uden at give adgang til at ændre selve koden.
En anden måde at reducere risikoen på er at bruge nye . Driftsprofessionelle kan implementere Kubernetes-klynger fra GitLab uden at skulle udsætte deres klynge for hele internettet. Vi introducerer også automatisk versionskontrolstøtte til nye Terraform-tilstandsfiler med for at understøtte overholdelse og nem fejlfinding. Endelig har instansens sikkerhedskontrolpanel udviklet sig til med sårbarhedsrapporter og sikkerhedsindstillinger.
Mere bekvemt og effektivt arbejde med GitLab
Vi har forbedret vores globale søgning ved at tilføje , som giver dig mulighed for nemt at navigere til de seneste billetter, grupper, projekter, indstillinger og hjælpeemner. Det er vi glade for at kunne meddele i GitLab Pages at omdirigere individuelle sider og mapper på et websted, hvilket giver brugerne mulighed for at implementere deres websteder mere effektivt. Og for dem, der gerne vil modtage udvidet information om implementeringen, tillader denne udgivelse !
Open source bidrag
Vi repræsenterer , som tilføjede . Enhedstestdækningsmærker for kodeændringer giver udviklere en visuel repræsentation af kodedækning under anmeldelser; disse oplysninger hjælper med at fremskynde anmeldelser og reducere tiden til at flette og implementere ny kode. Og også vi og planlægge .
Og dette er kun begyndelsen!
Som altid er der for lidt plads i det generelle overblik, og der er en masse fede funktioner i release 13.4. Her er nogle flere:
- .
Hvis du vil vide på forhånd, hvad der venter dig i næste frigive, se .
.
denne måned -
Fabio har bidraget væsentligt в - en funktion, der har ventet meget længe i GitLab-fællesskabet. Dette er et virkelig vigtigt bidrag med ikke-trivielle ændringer, der krævede konstant samarbejde med medlemmer af GitLab-teamet og påvirkede mange områder af projektet, såsom UX, front-end og back-end.
Hovedtræk i GitLab 13.4-udgivelsen
Brug HashiCorp Vault Keys i CI-job
(PREMIUM, ULTIMATE, SØLV, GULD)
I release 12.10 introducerede GitLab muligheden for at modtage og videregive nøgler til CI-job ved hjælp af GitLab-jobhandleren (GitLab runner). Nu udvider vi , tilføjer ny syntaks secrets at arkivere .gitlab-ci.yml. Dette vil gøre det lettere at opsætte og bruge HashiCorp-depotet med GitLab.
и .
Introduktion til GitLab Kubernetes Agent
(PREMIUM, ULTIMAT)
GitLabs integration med Kubernetes har længe tilladt udrulning på Kubernetes-klynger uden behov for manuel konfiguration. Mange brugere kunne lide denne pakkes brugervenlighed, mens andre stødte på nogle vanskeligheder. For løbende integration skal din klynge være tilgængelig fra internettet, så GitLab kan få adgang til den. For mange organisationer er dette ikke muligt, fordi de begrænser adgangen til klynger af sikkerheds-, overholdelses- eller lovgivningsmæssige årsager. For at komme uden om disse begrænsninger var brugerne nødt til at bygge deres værktøjer oven på GitLab, ellers ville de ikke være i stand til at bruge denne funktion.
I dag introducerer vi GitLab Kubernetes Agent, en ny måde at implementere til Kubernetes-klynger. Agenten kører inde i din klynge, så du behøver ikke at udsætte den for hele internettet. Agenten koordinerer implementeringen ved at anmode om nye ændringer fra GitLab i stedet for at GitLab skubber opdateringer til klyngen. Uanset hvilken GitOps-metode du bruger, er GitLab det rigtige for dig.
Bemærk venligst, at dette er den første udgivelse af agenten. I øjeblikket har vi fokuseret GitLab Kubernetes Agent på konfiguration og styring af udrulning gennem kode. Nogle eksisterende Kubernetes-integrationsfunktioner såsom implementeringstavler og GitLab-administrerede apps er endnu ikke understøttet. at disse muligheder vil blive tilføjet til agenten i fremtidige udgivelser, samt nye integrationer med fokus på sikkerhed og compliance.
и .
Giv brugerne tilladelse til at implementere uden kodeadgang
(PREMIUM, ULTIMATE, SØLV, GULD)
Tidligere tillod tilladelsessystemet i GitLab dig ikke at opdele ansvar i dit team korrekt mellem dem, der er ansvarlige for udvikling, og dem, der er ansvarlige for implementering. Med udgivelsen af GitLab 13.4 kan du give tilladelse til at bekræfte fletningsanmodninger om implementering, såvel som til rent faktisk at implementere koden til folk, der ikke skriver kode, uden at give dem vedligeholderadgang (i den russiske lokalisering af GitLab, "maintainer ”).
и .
Sikkerhedscenter
(ULTIMAT, GULD)
Tidligere var sårbarhedshåndtering på instansniveau begrænset i både funktionalitet og fleksibilitet. Grænsefladen var en enkelt side, der kombinerer sårbarhedsdetaljer, metriske grafer og indstillinger. Der er ikke meget plads til at udvikle disse funktioner eller bruge andre sikkerhedsfunktioner.
Vi har foretaget grundlæggende ændringer til sikkerhedsstyring og gennemsigtighed i GitLab. Instanssikkerhedspanelet er blevet omdannet til en hel sikkerhedshub. Den største ændring er introduktionen af en ny menustruktur: I stedet for én side ser du nu sikkerhedskontrolpanelet, sårbarhedsrapporten og indstillingsafsnittet separat. Selvom funktionaliteten ikke har ændret sig, vil en opdeling af den tillade forbedringer af dette afsnit, som ellers ville være vanskelige. Det sætter også scenen for, at andre sikkerhedsrelaterede funktioner tilføjes i fremtiden.
Den dedikerede sårbarhedsrapporteringssektion har nu mere plads til at vise vigtige detaljer. De sårbarheder, der i øjeblikket er på projektets sårbarhedsliste, er samlet her. Flytning af widgets med sårbarhedsmålinger til en separat sektion skaber et praktisk sikkerhedskontrolpanel. Det er nu et lærred til fremtidige visualiseringer – ikke kun til sårbarhedshåndtering, men for alle sikkerhedsrelaterede målinger. Endelig skaber et dedikeret indstillingsområde et fælles rum for alle sikkerhedsindstillinger på instansniveau, ikke kun sårbarhedsstyring.
и .
Skiftbare funktioner er nu i GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SØLV, GULD)
GitLab 11.4 er blevet frigivet . I 12.2 introducerede vi strategier for dem и , og i 13.1 tilføjet и til forskellige miljøer.
Tidligere i år forpligtede GitLab sig til ind i open source. I denne udgivelse har vi gennemført overførslen af omskiftelige funktioner til startplanen og vil fortsætte med at overføre dem til Core med . Vi er glade for at bringe denne funktion til flere brugere og vil gerne vide, hvordan du vil bruge den.
и .
Hurtig navigation fra søgelinjen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Nogle gange, når du navigerer gennem GitLab, vil du gå direkte til et specifikt projekt i stedet for søgeresultatsiden.
Med den globale søgelinje kan du hurtigt navigere til de seneste billetter, grupper, projekter, indstillinger og hjælpeemner. Du kan endda bruge genvejstaster /at flytte markøren til søgelinjen for at navigere GitLab endnu mere effektivt!
и .
Vis kodedækning i fletteanmodningsforskelle
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Ved gennemgang af en sammenlægningsanmodning kan det være svært at afgøre, om den ændrede kode er omfattet af enhedstest. I stedet kan anmeldere stole på den overordnede dækning og kræve, at den øges, før de godkender fletteanmodningen. Dette kan føre til en tilfældig tilgang til at skrive test, der ikke rigtig forbedrer kodekvaliteten eller testdækningen.
Nu, når du ser en fletteanmodningsforskel, vil du se en visuel visning af kodedækning. De nye mærker giver dig mulighed for hurtigt at forstå, om den ændrede kode er dækket af en enhedstest, hvilket vil hjælpe med at fremskynde kodegennemgange og tiden til at flette og implementere ny kode.
Tak og Siemens for denne funktion!
и .
Flere miljøer og projekter i miljøpanelet
(PREMIUM, ULTIMATE, SØLV, GULD)
Siden udgivelsen af GitLab 12.5 med du kunne spore status for miljøer, men ikke mere end syv miljøer i tre projekter. Vi forbedrede dette panel i version 13.4 ved at paginere det for at hjælpe dig med at vedligeholde og administrere dine miljøer i skala. Nu kan du se flere miljøer i flere projekter.
и .
GitLab tager kontrol over GitLab Terraform Provider
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
For nylig vi og planlægge . I løbet af den seneste måned har vi accepteret 21 fusionsanmodninger og lukket 31 billetter, inklusive nogle langvarige fejl og manglende funktioner, som f.eks. ... Du kan i Terraform-dokumentationen.
и .
Fuzz API-test med OpenAPI-specifikationer eller HAR-fil
(ULTIMAT, GULD)
API fuzz-test er en fantastisk måde at finde fejl og sårbarheder i dine webapplikationer og API'er, som andre scannere og testmetoder måske går glip af.
Fuzzing API-test i GitLab giver dig mulighed for at levere eller din applikation og genererer derefter automatisk tilfældige input til edge case test og fejljagt. Resultaterne vises straks i din pipeline.
Dette er vores første udgivelse af fuzzing API-test, og vi vil meget gerne høre, hvad du synes. Til fuzzing test har vi flere på lager , som vi vil basere på udgivelsen af denne funktion.
и .
Se forhåndsvisning af nye grafer i metrikpanelet
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Tidligere var det en skræmmende opgave at oprette en graf i et metric-dashboard i GitLab. Efter du har oprettet metrikken i panelets YAML-fil, har du lavet ændringer til masteruden at kunne verificere, at den graf, du lige har oprettet, fungerer præcis, som du ønskede. Fra og med denne udgivelse kan du forhåndsvise ændringer, mens du opretter en graf, og få en idé om resultatet, før du indsender ændringer til panelets .yaml-fil.
и .
Data om kodedækning ved test for alle projekter i gruppen
(PREMIUM, ULTIMATE, SØLV, GULD)
Når du administrerer et stort antal projekter i GitLab, har du brug for en enkelt kilde til information om, hvordan kodedækning ændrer sig på tværs af projekter over tid. Tidligere krævede visning af disse oplysninger kedeligt og tidskrævende manuelt arbejde: du skulle downloade kodedækningsdata fra hvert projekt og kombinere dem i en tabel.
I release 13.4 blev det muligt nemt og hurtigt at kompilere til .csv indberette alle data om kodedækning for alle projekter i gruppen eller for et udvalg af projekter. Denne funktion er MVC, den vil blive efterfulgt af muligheden .
и .
Understøttelse af nye sprog til fuld fuzz-test
(ULTIMAT, GULD)
Denne udgivelse introducerer understøttelse af flere nye sprog til fuzz-test med henblik på fuld dækning.
Nu kan du udforske alle mulighederne for fuzz-test i dine Java-, Rust- og Swift-applikationer og finde fejl og sårbarheder, som andre scannere og testmetoder måske går glip af.
и .
Meddelelser på hovedsiden af miljøer
(PREMIUM, ULTIMATE, SØLV, GULD)
Miljøsiden viser den generelle tilstand af dine miljøer. I denne udgivelse har vi forbedret denne side ved at tilføje visning af advarsler. Udløste advarsler sammen med status for dine miljøer vil hjælpe dig med at træffe korrigerende handlinger hurtigere.
и .
Indlejrede rørledninger kan nu køre deres egne indlejrede rørledninger
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Ved brug af indlejrede rørledninger blev det muligt at køre nye rørledninger inde i underordnede rørledninger. Det ekstra dybdeniveau kan være nyttigt, hvis du har brug for fleksibiliteten til at generere et variabelt antal rørledninger.
Tidligere, når der blev brugt indlejrede pipelines, krævede hver underordnede pipeline et triggerjob, der blev defineret manuelt i den overordnede pipeline. Nu kan du oprette indlejrede pipelines, der dynamisk starter et hvilket som helst antal nye indlejrede pipelines. For eksempel, hvis du har en monorepo, kan du dynamisk generere den første indlejrede pipeline, som selv vil skabe det nødvendige antal nye pipelines baseret på ændringer i grenen.
и .
Forbedret navigation mellem overordnede og indlejrede pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
At flytte mellem overordnede og indlejrede pipelines var tidligere ikke særlig bekvemt - det tog mange klik at komme til den ønskede pipeline. Det var heller ikke nemt at finde ud af præcist, hvilket job der startede denne pipeline. Nu bliver det meget nemmere at se forholdet mellem overordnede og indlejrede pipelines.
и .
Parallel Matrix-job viser relevante variabler i stillingsbetegnelsen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Hvis du brugte , har du måske bemærket, at det var svært at afgøre, hvilken matrixvariabel, der blev brugt til hvilket job, da jobnavnene så ud matrix 1/4. I version 13.4 vil du se de relevante værdier for de variabler, der blev brugt i dette job, i stedet for jobbets generiske navn. For eksempel, hvis dit mål er at debugge for x86-arkitekturen, så vil opgaven blive kaldt matrix: debug x86.
и .
Andre forbedringer i GitLab 13.4
Tilslutning af en Atlassian-konto
(CORE, STARTER, PREMIUM, ULTIMATE)
GitLab-brugere vil nu være i stand til at forbinde deres GitLab-konti til en Atlassian Cloud-konto. Dette vil give dig mulighed for at logge ind på GitLab med dine Atlassian-legitimationsoplysninger, samt lægge grundlaget for fremtidige integrationsforbedringer. og med andre produkter fra Atlassian-linjen.
и .
Eksporter en liste over alle sammenfletningsforpligtelser
(ULTIMAT, GULD)
Compliance-organisationer har brug for en måde at vise revisorer et holistisk syn på de komponenter, der er forbundet med en given produktionsændring. Inden for GitLab betyder det at samle alt på ét sted: fletteanmodninger, billetter, pipelines, sikkerhedsscanninger og andre commit-data. Indtil nu skulle du enten manuelt indsamle dette i GitLab, eller sætte dine værktøjer op til at indsamle information, hvilket ikke var særlig effektivt.
Nu kan du programmatisk fange og eksportere disse data for at opfylde dine revisions- eller andre behov. For at eksportere en liste over alle sammenfletninger for den aktuelle gruppe, skal du navigere til og klik på knappen Liste over alle sammenfletningsforpligtelser. Den resulterende fil vil indeholde alle sammenfletningsanmodningsforpligtelser, deres forfatter, tilknyttede fletteanmodnings-id, gruppe, projekt, forpligtere og andre oplysninger.
и .
Liste og administrere personlige adgangstokens via API
(ULTIMAT, GULD)
Håndtering af adgang til GitLab-navneområdet er en vigtig del af compliance-indsatsen. Fra principper om mindste privilegium til at deaktivere tidsbestemt adgang, kan der være flere krav relateret til personlige adgangstokens i GitLab. For at gøre det nemmere at vedligeholde og administrere alle disse brugerlegitimationsoplysninger i dit navneområde, har vi givet mulighed for at liste alle private adgangstokens og evt. gennem API'et.
Disse forbedringer af GitLab API'en giver brugerne mulighed for at angive og tilbagekalde deres egne personlige adgangstokens, og administratorer kan angive og tilbagekalde deres brugeres tokens. Det bliver nu nemmere for administratorer at se, hvem der har adgang til deres navneområde, træffe adgangsbeslutninger baseret på brugerdata og tilbagekalde personlige adgangstokens, der kan være blevet kompromitteret, eller som falder uden for virksomhedens adgangskontrolpolitikker.
и .
Relaterede billetter og andre funktioner er nu i GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
For et par måneder siden annoncerede vi en plan til . Vi arbejder på at opfylde dette løfte, vi har givet , и (i den russiske lokalisering af GitLab "diskussionstavle") tilgængelig i kerneplanen. Dette gælder kun for relationer af typen "associeret med", relationer af typen "blokke" og "blokke" forbliver i betalte planer.
и .
Viser navnet på kildegrenen i sidebjælken for fletanmodning
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Når du gennemgår kodeændringer, diskussioner og commits af fletteanmodninger, er det ofte ønskeligt at tjekke filialen lokalt for en dybere gennemgang. Men at finde filialnavnet bliver mere og mere vanskeligt, efterhånden som mere indhold føjes til beskrivelsen af fletteanmodningen, og siden skal rulles længere og længere.
Vi har tilføjet filialnavnet til sidebjælken i fletteanmodningen, hvilket gør det tilgængeligt til enhver tid og eliminerer behovet for at rulle gennem hele siden. Ligesom fletteanmodningslinket indeholder kildegrenafsnittet en praktisk "kopi"-knap.
Tak for det enorme bidrag til udviklingen af denne funktion!
и .
Indikation af tilstedeværelsen af kollapsede filer i fletteanmodningsforskelle
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Sammenfletningsanmodninger, der tilføjer ændringer til flere filer, kollapser nogle gange store filforskelle for at forbedre skærmydeevnen. Når dette sker, er det muligt ved et uheld at springe en fil over ved gennemgang, især ved fletningsanmodninger med et stort antal filer. Fra og med version 13.4 vil fletteanmodninger markere diffs, der indeholder foldede filer, så du ikke går glip af disse filer under kodegennemgangsprocessen. For endnu større klarhed planlægger vi at tilføje fremhævelse af disse filer i en fremtidig udgivelse. Følg med for opdateringer kl .
и .
Advarsel om tilstedeværelsen af skjulte filer i en fletteanmodningsdiff
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
I fletteanmodningsdiff-sektionen er store filer foldet sammen for at forbedre ydeevnen. Men når du gennemgår koden, kan nogle filer springes over, når korrekturlæseren ruller gennem listen over filer, da alle store filer er foldet sammen.
Vi har tilføjet en synlig advarsel øverst på fletteanmodningsdiff-siden for at informere brugerne om, at der er en flettet fil i den sektion. På denne måde går du ikke glip af nogen ændringer i fletteanmodningen under gennemgangen.
и .
Automatisk gendannelse af Gitaly-klyngelageret
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Tidligere, da den primære node i en Gitaly-klynge gik ned, blev lagrene på den node markeret som skrivebeskyttet. Dette forhindrede datatab i situationer, hvor der var ændringer på noden, som endnu ikke var blevet replikeret. Da noden blev tilsluttet igen, genoprettede GitLab sig ikke automatisk, og administratorer måtte manuelt starte synkroniseringsprocessen eller finde sig i datatab. Andre situationer kan også føre til forældede eller skrivebeskyttede lagre, såsom fejl i et replikeringsjob på en sekundær node. I dette tilfælde forblev lageret forældet, indtil den næste skriveoperation blev udført, hvilket ville starte replikeringsjobbet.
For at løse dette problem planlægger nu et replikeringsjob, når det registrerer et forældet lager på én node og den seneste version af et lager på et andet. Dette replikeringsjob holder automatisk lageret opdateret, hvilket eliminerer behovet for manuelt at gendanne data. Automatisk gendannelse sikrer også, at sekundære noder hurtigt opdateres, hvis et replikeringsjob mislykkes, i stedet for at vente på den næste skriveoperation. Da mange Gilaly-klynger gemmer et stort antal repositories, reducerer dette markant den tid, som administratorer og pålidelighedsingeniører bruger på datagendannelse efter en fejl.
Derudover starter autofix at replikere repositories på enhver ny Gitaly-knude tilføjet til klyngen, hvilket eliminerer det manuelle arbejde med at tilføje nye noder.
и .
Marker opgaven som udført på designsiden
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Effektiv kommunikation i GitLab er baseret på to-do-lister. Hvis du er blevet nævnt i en kommentar, er det afgørende at kunne navigere til en opgave og enten begynde at gøre noget eller markere det som udført. Det er også vigtigt at kunne tildele en opgave til dig selv, når du skal arbejde på noget eller vende tilbage til det senere.
Tidligere kunne du ikke tilføje opgaver eller markere dem som afsluttede, mens du arbejdede med designs. Dette forstyrrede alvorligt effektiviteten af kommunikationen mellem produktteams, da to-do-opgaver er et kritisk element i arbejdsgangen i GitLab.
I release 13.4 indhenter designs billetkommentarer i brugen af opgaver, hvilket gør dem mere konsistente og effektive.
и .
Forbedret fejlfindingsvejledning til CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Vi har forbedret GitLab CI/CD-fejlfindingsvejledningen ved at tilføje yderligere oplysninger om almindelige problemer, du kan støde på. Vi håber, at den forbedrede dokumentation vil være en værdifuld ressource til at hjælpe dig med hurtigt og nemt at opsætte og køre GitLab CI/CD.
и .
Fletningsanmodninger slettes ikke længere fra fletningskøen
(PREMIUM, ULTIMATE, SØLV, GULD)
Tidligere kunne fusionsanmodninger falde ud af fletningskøen ved et uheld på grund af sene kommentarer. Hvis en fletningsanmodning allerede var i køen, og nogen tilføjede en kommentar til den, der skabte en ny uafklaret diskussion, blev fletteanmodningen anset for uegnet til fletning og faldt ud af køen. Nu, efter en fletningsanmodning er tilføjet til fletningskøen, kan nye kommentarer tilføjes uden frygt for at bryde fletningsprocessen.
и .
Viser kodedækningsværdien for et job i en fletningsanmodning
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Udviklere bør være i stand til at se kodedækningsværdien, efter at pipelinen er fuldført – selv i komplekse scenarier, såsom at køre en pipeline med flere job, der skal analyseres for at beregne dækningsværdien. Tidligere viste fletteanmodningswidgetten kun gennemsnittet af disse værdier, hvilket betød, at du skulle gå til jobsiden og tilbage til fletteanmodningen for at få mellemliggende dækningsværdier. For at spare dig for tid og disse unødvendige trin, har vi fået widgetten til at vise den gennemsnitlige dækningsværdi, dens ændringer mellem mål- og kildegrenene og et værktøjstip, der viser dækningsværdien for hver opgave, på grundlag af hvilken gennemsnittet blev beregnet .
и .
Fjernelse af pakker fra pakkeregistret, når du ser en gruppe
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
GitLab Package Registry er et sted at gemme og distribuere pakker i forskellige formater. Når dit projekt eller din gruppe har mange pakker, skal du hurtigt identificere ubrugte pakker og fjerne dem, så folk ikke downloader dem. Du kan fjerne pakker fra dit register via eller gennem pakkeregistrets brugergrænseflade. Indtil nu har du dog ikke kunne slette pakker, når du ser en gruppe gennem brugergrænsefladen. Som et resultat var du nødt til at fjerne overflødige pakker på projektbasis, hvilket var ineffektivt.
Du kan nu fjerne pakker, når du ser en gruppes pakkeregister. Bare gå til gruppens pakkeregistreringsside, filtrer pakker efter navn og fjern dem, du ikke har brug for.
и .
Skalering af Conan-pakker til projektniveau
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Du kan bruge GitLab Conan repository til at publicere og distribuere C/C++ afhængigheder. Tidligere pakker kunne dog kun skaleres til instansniveau, da Conan-pakkenavnet maksimalt kunne være på 51 tegn. Hvis du ville udgive en pakke fra en undergruppe som gitlab-org/ci-cd/package-stage/feature-testing/conan, det var næsten umuligt at gøre.
Du kan nu skalere Conan-pakker til projektniveau, hvilket gør det nemt at publicere og distribuere dit projekts afhængigheder.
и .
Support til nye pakkeadministratorer og sprog til afhængighedsscanning
(ULTIMAT, GULD)
Vi er glade for at tilføje afhængighedsscanning for projekter med C-, C++-, C#- og .Net-kode, der bruger NuGet 4.9+ eller Conan-pakkeadministratorerne til vores liste. . Du kan nu aktivere afhængighedsscanning som en del af Sikker-stadiet for at kontrollere afhængigheder tilføjet via pakkeadministratorer for kendte sårbarheder. Fundne sårbarheder vil blive vist i din fusionsanmodning sammen med deres sværhedsgrad, så du inden fusionen ved, hvilke risici en ny afhængighed indebærer. Du kan også tilpasse dit projekt efter behov for afhængigheder med kritiske (Kritiske), høje (Høj) eller ukendte (Ukendt) sårbarheder.
и .
Meddelelser ved ændring af indstillingen af fletteanmodning til 'Flet ved vellykket gennemførelse af pipelinen'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Tidligere, ved indstilling af fletteanmodningsindstillingen Flet sammen, når rørledningen er færdig (Merge When Pipeline Succeeds, MWPS) ingen e-mail-meddelelse blev sendt. Du skulle manuelt kontrollere status eller vente på, at fusionen blev underrettet. I denne udgivelse er vi glade for at kunne præsentere brugerens bidrag , som løste dette problem ved at tilføje automatiske meddelelser til alle, der abonnerede på fletteanmodningen, når korrekturlæseren ændrer fletteindstillingen til MWPS.
и .
Oprettelse af EKS-klynger med brugerdefineret Kubernetes-version
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
GitLab-brugere kan nu vælge den version af Kubernetes, der vil blive leveret af EKS; du kan vælge mellem version 1.14-1.17.
и .
Oprettelse af hændelser som billettyper
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Ikke alle problemer, der opstår med det samme, udløser advarsler: Brugere rapporterer udfald, og teammedlemmer undersøger præstationsproblemer. Hændelser er nu en form for en billet, så dine teams hurtigt kan oprette dem som en del af en velkendt arbejdsgang. Klik Ny opgave fra hvor som helst i GitLab og i marken Type Vælg Utilsigtet hændelse.
и .
Omtale GitLab Alerts i Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Vi har forbedret GitLab-advarsler ved at tilføje en ny omtaletype specifikt til dem i GitLab-versionen af Markdown, hvilket gør det nemmere at dele og omtale alarmer. Brug ^alert#1234at nævne advarslen i ethvert Markdown-felt: i hændelser, billetter eller fletningsanmodninger. Det vil også hjælpe dig med at definere problemer, der er oprettet fra advarsler, ikke fra billetter eller fletningsanmodninger.
и .
Se belastning af hændelsesalarm
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Advarselsbeskrivelsen indeholder oplysninger, der er kritiske for fejldiagnose og retablering, og disse oplysninger bør være let tilgængelige, så du ikke behøver at skifte værktøjer eller faner, mens du arbejder på at løse en hændelse. Hændelser oprettet fra advarsler viser den fulde beskrivelse af advarslen i en fane Advarselsdetaljer.
75 % hurtigere avanceret søgning
(STARTER, PREMIUM, ULTIMATE, BRONZE, SØLV, GULD)
GitLab, som en enkelt applikation, har den unikke evne til at gøre indholdsopdagelse på tværs af hele DevOps-workflowet hurtigt. I GitLab 13.4 returnerer avanceret søgning resultater 75 % hurtigere, når det , som på GitLab.com.
и .
Visning af fjernprojekter for administratorer
(CORE, STARTER, PREMIUM, ULTIMATE)
Evnen til at forsinke sletning af et projekt var . Tidligere var det dog ikke muligt at se alle projekter, der ventede på at blive slettet på ét sted. GitLab brugerdefinerede instansadministratorer kan nu se alle afventende sletteprojekter på ét sted sammen med knapper til nemt at gendanne disse projekter.
Denne funktion giver administratorer større kontrol over sletning af projekter ved at samle alle relevante oplysninger ét sted og give mulighed for at fortryde uønskede sletninger.
Tak for denne funktion!
и .
Tilføjet understøttelse af gruppe push-regler til API
(STARTER, PREMIUM, ULTIMATE, BRONZE, SØLV, GULD)
Tidligere kunne gruppe push-regler kun konfigureres ved at besøge hver gruppe individuelt gennem GitLab UI og anvende disse regler. Du kan nu administrere disse regler via en API for at understøtte dine tilpassede værktøjer og GitLab-automatisering.
и .
Tilbagekald personlige adgangstokens til selvadministreret legitimationsopbevaring
(ULTIMAT)
giver administratorer de oplysninger, de har brug for til at administrere brugerlegitimationsoplysninger for deres GitLab-instans. Fordi overholdelsesorienterede organisationer varierer i strengheden af deres legitimationsstyringspolitikker, har vi tilføjet en knap, der giver administratorer mulighed for at tilbagekalde en brugers personlige adgangstoken (PAT), hvis det ønskes. Administratorer kan nu nemt tilbagekalde potentielt kompromitterede PAT'er. Denne funktion er nyttig for organisationer, der har brug for mere fleksible håndhævelsesmuligheder for at minimere distraktioner for deres brugere.
и .
Konfigurationsfil til den statiske webstedseditor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
I GitLab 13.4 introducerer vi en ny måde at tilpasse den statiske webstedseditor. Selvom konfigurationsfilen ikke gemmer eller henter nogen indstillinger i denne udgivelse, lægger vi grundlaget for fremtidig tilpasning af editorens adfærd. I de næste udgivelser vil vi tilføje til filen .gitlab/static-site-editor.yml parametre, der skal installeres , hvor , der tilsidesætter Markdown-syntaksindstillinger og andre redigeringsindstillinger.
и .
Redigering af den indledende del af en fil ved hjælp af den statiske webstedseditor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Front matter er en fleksibel og bekvem måde at definere sidevariabler i datafiler, der skal behandles af den statiske site-generator. Det bruges typisk til at indstille sidens titel, layoutskabelon eller forfatter, men kan bruges til at videregive enhver type metadata til generatoren, når siden gengives til HTML. Inkluderet i toppen af hver datafil, er præamblen normalt formateret som YAML eller JSON og kræver en konsekvent og præcis syntaks. Brugere, der ikke er bekendt med specifikke syntaksregler, kan utilsigtet indtaste ugyldig markup, hvilket igen kan forårsage formateringsproblemer eller endda byggefejl.
WYSIWYG-redigeringstilstanden for den statiske webstedseditor fjerner allerede introen fra editoren for at forhindre disse formateringsfejl. Dette forhindrer dig dog i at ændre værdierne, der er gemt i den del, uden at vende tilbage til redigering i kildetilstand. I GitLab 13.4 kan du få adgang til ethvert felt og redigere dets værdi i en velkendt formularbaseret grænseflade. Når du trykker på en knap Indstillinger (Indstillinger) åbner et panel, der viser et formularfelt for hver nøgle, der er defineret i begyndelsen. Felterne er udfyldt med den aktuelle værdi, og for at redigere nogen af dem skal du blot indtaste den i webformularen. Denne forordsredigering undgår syntakskompleksitet og giver dig fuld kontrol over indholdet, samtidig med at det sikres, at det endelige output formateres konsekvent.
и .
GitLab til Jira og DVCS Connector nu i Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
For Jira-brugere i GitLab: и giver dig mulighed for at vise information om GitLab commits og flette anmodninger direkte i Jira. Kombineret med vores indbyggede Jira-integration kan du nemt flytte mellem de to apps, mens du arbejder.
Disse funktioner var tidligere kun tilgængelige i vores Premium-abonnement, men nu er de tilgængelige for alle brugere!
и .
Flertalsafstemning for Gitaly-klyngetransaktioner (beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
En Gitaly-klynge giver dig mulighed for at replikere Git-lagre til flere varme Gitaly-noder. Dette forbedrer fejltolerancen ved at eliminere enkelte fejlpunkter. , introduceret i GitLab 13.3, forårsager, at ændringer udsendes til alle Gitaly-noder i klyngen, men kun Gitaly-noder, der stemmer i overensstemmelse med den primære knude, gemmer ændringerne på disken. Hvis alle replika-noder ikke er enige, vil kun én kopi af ændringen blive gemt på disken, hvilket skaber et enkelt fejlpunkt, indtil asynkron replikering er fuldført.
Flertalsafstemning forbedrer fejltolerancen ved at kræve samtykke fra et flertal (i stedet for alle) af noderne, før ændringerne gemmes på disken. Hvis denne omskiftelige funktion er aktiveret, skal skrivningen lykkes på flere noder. Uenige noder synkroniseres automatisk ved hjælp af asynkron replikering fra de noder, der dannede et kvorum.
и .
Understøttelse af brugerdefineret skema til JSON-validering i Web IDE
(PREMIUM, ULTIMATE, SØLV, GULD)
Projekter, hvor folk skriver konfigurationer i JSON- eller YAML-format, er ofte tilbøjelige til problemer, fordi det er nemt at lave en tastefejl og bryde noget. Det er muligt at skrive valideringsværktøjer, der fanger disse problemer i CI-pipelinen, men brug af en JSON-skemafil kan være nyttig til at give dokumentation og tip.
Projektmedlemmer kan i deres lager definere stien til det brugerdefinerede skema i filen .gitlab/.gitlab-webide.yml, som angiver skemaet og stien til de filer, der skal kontrolleres. Når en bestemt fil uploades til web-IDE'en, vil yderligere feedback og validering være synlig for at hjælpe med at oprette filen.
и .
Forgreningsgrænse for Directed Acyclic Graph (DAG) øget til 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Hvis du bruger rørledninger (Directed Acyclic Graph (DAG)), kan du opleve, at der er en grænse på 10 job, som et job kan specificere i needs:, for hårdt. I 13.4 er standardgrænsen blevet øget fra 10 til 50 for at give mulighed for mere komplekse netværk af relationer mellem job i dine pipelines.
Hvis du er administrator af en tilpasset GitLab-instans, kan du hæve denne grænse endnu højere ved at opsætte en funktion, der kan skiftes, selvom vi ikke tilbyder officiel support til dette.
и .
Forbedret adfærd needs for manglende opgaver
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
I nogle tilfælde kan et oversprunget job i en pipeline fejlagtigt blive betragtet som vellykket for de afhængigheder, der er angivet i needs, hvilket får efterfølgende job til at køre, når de ikke burde. Denne adfærd er blevet rettet i version 13.4, og needs håndterer nu sager om overspringede opgaver korrekt.
и .
Fastgør den sidste jobartefakt for at forhindre den i at blive slettet
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
GitLab låser nu automatisk den sidste artefakt af et vellykket job og pipeline på enhver aktiv gren, fletteanmodning eller tag for at forhindre det i at blive slettet efter det udløber. Det bliver nemmere at sætte mere aggressive udløbsregler for at rydde op i gamle artefakter. Dette hjælper med at reducere diskpladsforbruget og sikrer, at du altid har en kopi af den seneste artefakt fra pipelinen.
и .
CI/CD guide til pipeline optimering
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Optimering af CI/CD-pipeline kan forbedre leveringshastigheden og spare penge. Vi har forbedret vores dokumentation med en hurtig guide til at få mest muligt ud af at optimere dine pipelines.
и .
Testrapport sorteret efter teststatus
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
er en nem måde at se resultaterne af alle testene i pipelinen. Men med et stort antal tests kan det tage lang tid at finde fejlbeståede tests. Andre problemer, der kan gøre rapporten svær at bruge, omfatter problemer med at rulle gennem lange sporingsoutput og afrundingstid til nul for test, der kører på mindre end 1 sekund. Nu sætter sorteringstestrapporten som standard først mislykkede test øverst i rapporten og sorterer derefter testene efter varighed. Dette gør det nemmere at finde nedbrud og lange tests. Derudover vises testvarigheder nu i millisekunder eller sekunder, hvilket gør dem meget hurtigere at læse, og tidligere rulleproblemer er også blevet løst.
и .
Filstørrelsesgrænser uploadet til pakkeregistret
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Der er nu begrænsninger på størrelsen af pakkefiler, der kan uploades til GitLab Package Registry. Begrænsninger er blevet tilføjet for at optimere pakkeregistrets ydeevne og forhindre misbrug. Begrænsninger afhænger af pakkeformatet. For GitLab.com er de maksimale filstørrelser:
- Conan: 250 MB
- Maven: 3GB
- NPM: 300 MB
- NuGet: 250 MB
- PyPI: 3GB
For tilpassede GitLab-instanser er standardindstillingerne de samme. Dog kan administratoren opdatere begrænsningerne med .
и .
Brug CI_JOB_TOKEN til at udgive PyPI-pakker
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Du kan bruge GitLab PyPI-lageret til at oprette, udgive og dele Python-pakker sammen med kildekode og CI/CD-pipelines. Men tidligere kunne du ikke godkende mod et lager med en foruddefineret miljøvariabel CI_JOB_TOKEN. Som et resultat var du nødt til at bruge dine personlige legitimationsoplysninger til at opdatere PyPI-lageret, eller du har måske besluttet slet ikke at bruge lageret.
Det er nu nemmere at bruge GitLab CI/CD til at publicere og installere PyPI-pakker ved hjælp af en foruddefineret miljøvariabel CI_JOB_TOKEN.
и .
DAST scannerprofiler på forespørgsel
(ULTIMAT, GULD)
Til on-demand DAST-scanningen, der var , DAST scannerprofiler er blevet tilføjet. De udvider konfigurationsmulighederne for denne scanning ved at give dig mulighed for hurtigt at oprette flere profiler, der dækker flere scanningstyper. I 13.4 indeholder webcrawlerprofilen til at begynde med en crawler-timeoutindstilling, der angiver, hvor længe DAST-crawleren skal køre, når den forsøger at opdage alle siderne på et crawlet websted. Profilen indeholder også en timeout-indstilling for målwebsted for at indstille, hvor længe crawleren skal vente på, at et websted bliver tilgængeligt, før det afbrydes crawlet, hvis webstedet ikke svarer med en statuskode på 200 eller 300. Efterhånden som vi forbedrer denne funktion igen og igen i fremtidige udgivelser vil yderligere konfigurationsmuligheder blive tilføjet til scannerprofilen.
и .
En simpel omdirigeringskonfigurationsfil til GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Hvis du bruger GitLab Pages og ønsker at administrere URL-ændringer bedre, så har du måske bemærket, at det ikke var muligt at administrere omdirigeringer på dit GitLab Pages-websted. GitLab giver dig nu mulighed for at opsætte regler for omdirigering af en URL til en anden for dit Pages-websted ved at tilføje en konfigurationsfil til depotet. Denne funktion blev muliggjort af bidrag fra Kevin Barnett (), vores Eric Eastwood () og GitLab-kommandoer. Tak til alle for jeres input.
и .
Terraform-stat administreret af GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Adgang til tidligere versioner af Terraforms tilstand er nødvendig for både overholdelse og fejlretning efter behov. Support til GitLab-administreret Terraform-tilstandsversionering er blevet leveret siden GitLab 13.4. Versionering aktiveres automatisk for nye Terraform-tilstandsfiler. Eksisterende Terraform-tilstandsfiler vil være i en senere udgivelse.
и .
Vigtige detaljer om hændelsesrapportering
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Når du håndterer hændelser, skal du nemt kunne bestemme, hvor længe en alarm har været åben, og hvor mange gange en hændelse har udløst. Disse detaljer er ofte kritiske til at bestemme kundepåvirkning, og hvad dit team skal gøre først. I det nye panel med hændelsesdetaljer viser vi starttidspunktet for advarslen, antallet af hændelser og et link til den oprindelige advarsel. Disse oplysninger er tilgængelige for hændelser, der genereres fra advarsler.
и .
Indstilling og redigering af hændelsens alvorlighedsparameter
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Hændelsesalvorlighedsdimensionen gør det muligt for respondenter og interessenter at bestemme virkningen af et afbrydelse, samt metoderne og det haster med reaktionen. Da dit team deler resultater under hændelsesløsning og genopretning, kan de ændre denne indstilling. Du kan nu redigere alvoren af en hændelse i højre sidebjælke på siden Incident Details, og alvoren vises på listen over hændelser.
и .
Opret, rediger og slet containernetværkssikkerhedsregler
(ULTIMAT, GULD)
Denne forbedring af Container Network Security Rule Editor giver brugerne mulighed for nemt at oprette, redigere og slette deres egne regler direkte fra GitLab UI. Editor-funktioner inkluderer tilstand .yaml for avancerede brugere og en regeleditor med en intuitiv grænseflade til de nye netværksregler. Du kan finde nye regelstyringsfunktioner i afsnittet Sikkerhed og overholdelse > Trusselshåndtering > Regler (Sikkerhed og overholdelse > Trusselsstyring > Politikker).
и .
Azure blob-lagringsunderstøttelse
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SØLV, GULD)
Både GitLab og GitLab Runner understøtter nu , hvilket gør det nemt at køre GitLab-tjenester på Azure.
GitLab-instanser understøtter Azure til alle typer objektlagring, inklusive LFS-filer, CI-artefakter og . Følg installationsinstruktionerne for at konfigurere Azure blob-lagring eller .
GitLab-jobprocessorer understøtter også Azure til opbevaring . Azure-lagring kan konfigureres ved hjælp af afsnittet .
и .
Omnibus ARM64-pakker til Ubuntu og OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
Som svar på den stigende efterspørgsel efter GitLab-understøttelse af 64-bit ARM-arkitektur, er vi glade for at kunne annoncere tilgængeligheden af den officielle ARM64 Ubuntu 20.04 Omnibus-pakke. Kæmpe tak til Zitai Chen og Guillaume Gardet for det enorme bidrag, de har ydet - deres fusionsanmodninger har været en central del af dette!
For at downloade og installere pakken til Ubuntu 20.04 skal du gå til vores og vælg Ubuntu.
и .
Understøttelse af smart card-godkendelse til GitLab Helm-diagram
(PREMIUM, ULTIMAT)
Smartkort, såsom Shared Access Cards (CAC'er), kan nu bruges til at godkende til en GitLab-instans, der er implementeret via Helm-diagram. Smartcards godkendes mod en lokal database ved hjælp af X.509-certifikater. Med dette er understøttelse af chipkort med Helm-diagram nu på linje med understøttelse af chipkort, der er tilgængelig i Omnibus-implementeringer.
и .
Detaljerede udgivelsesbemærkninger og opgraderings-/installationsvejledninger kan findes i det originale engelske indlæg: .
Arbejdede på oversættelse fra engelsk , , и .
Kilde: www.habr.com