Versjon 13.4 har blitt utgitt med HashiCorp-lagring for CI-variabler, Kubernetes Agent og sikkerhetssenter, samt byttbare funksjoner i Starter
Hos GitLab tenker vi alltid på hvordan vi kan hjelpe brukere med å redusere risiko, forbedre effektiviteten og forbedre leveringshastigheten på din favorittplattform. Denne måneden har vi lagt til mange nyttige nye funksjoner som utvider sikkerhetsfunksjonene, reduserer antall sårbarheter, øker effektiviteten, forenkler arbeidet med GitLab og hjelper teamet ditt med å levere funksjoner enda raskere. Vi håper at du vil finne hovedfunksjonene i utgivelsen nyttige, så vel som 53 andre nye funksjoner, lagt til i denne utgivelsen.
Avanserte sikkerhetsfunksjoner
Vi prøver å legge til flere nye funksjoner til GitLab DevSecOps hver måned, og denne utgivelsen er intet unntak. innenfor rammen av montering og utplassering. I tillegg kan organisasjoner som ønsker å støtte separasjon av kodedistribusjonsansvar nå . Denne rollen samsvarer og vil tillate deg å bekrefte sammenslåingsforespørsler (i den russiske lokaliseringen av GitLab "sammenslåingsforespørsler") og distribuere kode i beskyttede miljøer, uten å gi tilgang til å endre selve koden.
En annen måte å redusere risiko på er å bruke nye . Driftsteam kan distribuere Kubernetes-klynger fra GitLab uten å måtte eksponere klyngen deres for hele internett. Vi introduserer også automatisk versjonskontrollstøtte for nye Terraform-tilstandsfiler med for å støtte samsvar og enkel feilsøking. Til slutt ble forekomstens sikkerhetsdashbord med sårbarhetsrapporter og sikkerhetsinnstillinger.
Mer praktisk og effektivt arbeid med GitLab
Vi har forbedret vårt globale søk til å inkludere , slik at du enkelt kan navigere til de nyeste billettene, gruppene, prosjektene, innstillingene og hjelpeemnene. Vi er glade for å kunngjøre at GitLab Pages å omdirigere individuelle sider og kataloger på nettstedet, noe som vil tillate brukere å distribuere nettstedene sine mer effektivt. Og for de som ønsker å motta utvidet informasjon om distribusjonen, tillater denne utgivelsen !
Bidrag med åpen kildekode
Var tilstede som jeg la til . Merker på enhetstestdekning av endret kode gir utviklere en klar idé om kodedekning under gjennomgang; denne informasjonen hjelper til med å fremskynde vurderinger og redusere tiden for sammenslåing og distribusjon av ny kode. Og vi også og planlegge .
Og dette er bare begynnelsen!
Som alltid er det for lite plass i den generelle oversikten, men det er mange kule funksjoner i 13.4-utgivelsen. Her er noen flere:
- .
Hvis du vil vite på forhånd hva som venter deg i neste slipp, ta en titt .
.
denne måneden -
Fabio bidro betydelig в - en funksjon som har vært etterlengtet i veldig lang tid i GitLab-fellesskapet. Dette er et virkelig viktig bidrag med ikke-trivielle endringer som krevde konstant samarbeid med GitLab-teammedlemmer og påvirket mange områder av prosjektet som UX, front-end og back-end.
Hovedtrekkene til GitLab 13.4-utgivelsen
Bruk HashiCorp Vault-nøkler i CI-jobber
(PREMIUM, ULTIMATE, SØLV, GULL)
I utgivelse 12.10 introduserte GitLab muligheten til å motta og overføre nøkler til CI-jobber ved å bruke GitLab-jobbbehandleren (GitLab runner). Nå utvider vi , legger til ny syntaks secrets å lagre .gitlab-ci.yml. Dette vil gjøre det enklere å sette opp og bruke HashiCorp-depotet med GitLab.
и .
Vi introduserer GitLab Kubernetes Agent
(PREMIUM, ULTIMAT)
GitLabs integrasjon med Kubernetes har lenge gjort det mulig å distribuere til Kubernetes-klynger uten behov for manuell konfigurasjon. Mange brukere likte brukervennligheten til denne pakken, mens andre møtte noen vanskeligheter. For den nåværende integrasjonen må klyngen din være tilgjengelig fra Internett for at GitLab skal få tilgang til den. For mange organisasjoner er dette ikke mulig fordi de begrenser tilgangen til klynger av sikkerhets-, samsvars- eller regulatoriske årsaker. For å omgå disse begrensningene, måtte brukere bygge verktøyene sine på toppen av GitLab, ellers ville de ikke kunne bruke denne funksjonen.
I dag introduserer vi GitLab Kubernetes Agent, en ny måte å distribuere til Kubernetes-klynger. Agenten kjører inne i klyngen din, så du trenger ikke å eksponere den for hele Internett. Agenten koordinerer distribusjonen ved å be om nye endringer fra GitLab, i stedet for at GitLab pusher oppdateringer til klyngen. Uansett hvilken GitOps-metode du bruker, har GitLab deg dekket.
Vær oppmerksom på at dette er den første utgivelsen av agenten. Vårt nåværende fokus for GitLab Kubernetes Agent er å konfigurere og administrere distribusjoner gjennom kode. Noen eksisterende Kubernetes-integrasjonsfunksjoner, for eksempel distribusjonstavler og GitLab-administrerte applikasjoner, støttes ennå ikke. at disse egenskapene vil bli lagt til agenten i fremtidige utgivelser, samt nye integrasjoner fokusert på sikkerhet og compliance.
и .
Gi brukere distribusjonstillatelser uten kodetilgang
(PREMIUM, ULTIMATE, SØLV, GULL)
Tidligere har GitLabs tillatelsessystem gjort det vanskelig å dele ansvar i teamet ditt mellom de ansvarlige for utvikling og de som er ansvarlige for distribusjon. Med utgivelsen av GitLab 13.4 kan du gi tillatelse til å godkjenne sammenslåingsforespørsler for distribusjon, samt å faktisk distribuere kode til personer som ikke skriver koden, uten å gi dem tilgangsrettigheter for vedlikeholder (i den russiske lokaliseringen av GitLab "maintainer" ).
и .
Sikkerhetssenter
(ULTIMAT, GULL)
Tidligere var sårbarhetshåndtering på instansnivå begrenset både i funksjonalitet og fleksibilitet. Grensesnittet var en enkelt side som kombinerer detaljer om sårbarheter, metrikkgrafer og innstillinger. Det er ikke mye plass til å utvikle disse funksjonene eller bruke andre sikkerhetsfunksjoner.
Vi har gjort grunnleggende endringer i hvordan vi administrerer sikkerhet og åpenhet i GitLab. Forekomstens sikkerhetspanel har blitt omgjort til et helt sikkerhetssenter. Den største endringen er introduksjonen av en ny menystruktur: i stedet for én side ser du nå sikkerhetsoversikten, sårbarhetsrapporten og innstillingene separat. Selv om funksjonaliteten ikke har endret seg, vil å dele den opp i deler tillate forbedringer av denne delen som ellers ville vært vanskelig. Dette legger også grunnlaget for å legge til andre sikkerhetsrelaterte funksjoner i fremtiden.
Den dedikerte sårbarhetsrapportdelen har nå mer plass til å vise viktige detaljer. Her er sårbarhetene som for øyeblikket står på prosjektets sårbarhetsliste. Flytting av widgets med sårbarhetsmålinger til en egen seksjon skaper et praktisk sikkerhetskontrollpanel. Det er nå et lerret for fremtidige visualiseringer – ikke bare for sårbarhetshåndtering, men for alle sikkerhetsrelaterte beregninger. Til slutt skaper et eget innstillingsområde et felles område for alle sikkerhetsinnstillinger på forekomstnivå, ikke bare sårbarhetsadministrasjon.
и .
Byttbare funksjoner er nå i GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONSE, SØLV, GULL)
GitLab 11.4 ble utgitt . I 12.2 introduserte vi strategier for dem и , og i 13.1 la de til и for ulike miljøer.
Tidligere i år forpliktet GitLab seg inn i åpen kildekode. I denne utgivelsen har vi fullført migreringen av byttbare funksjoner til startplanen og vil fortsette å migrere dem til Core fra . Vi er glade for å bringe denne funksjonen til flere brukere og ønsker å høre hvordan du bruker den.
и .
Rask navigering fra søkefeltet
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Noen ganger når du navigerer i GitLab vil du gå rett til et spesifikt prosjekt i stedet for søkeresultatsiden.
Ved å bruke den globale søkelinjen kan du raskt navigere til de nyeste billettene, gruppene, prosjektene, innstillingene og hjelpeemnene. Du kan til og med bruke en hurtigtast /for å flytte markøren til søkefeltet for å navigere i GitLab enda mer effektivt!
и .
Viser kodedekning i sammenslåingsforespørselsforskjeller
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Ved gjennomgang av en sammenslåingsforespørsel kan det være vanskelig å avgjøre om den endrede koden dekkes av enhetstester. I stedet kan anmeldere stole på den generelle dekningen og be om at den økes før de godkjenner en sammenslåingsforespørsel. Dette kan føre til en tilfeldig tilnærming til å skrive tester, som faktisk ikke vil forbedre kodekvaliteten eller testdekningen.
Nå, når du ser på en sammenslåingsforespørselsforskjell, vil du se en visuell visning av kodedekning. Nye merker vil tillate deg raskt å forstå om den endrede koden dekkes av en enhetstest, noe som vil bidra til å fremskynde kodegjennomgangen og tidspunktet for sammenslåing og distribusjon av ny kode.
Takk og Siemens for denne funksjonen!
и .
Flere miljøer og prosjekter i Miljøpanelet
(PREMIUM, ULTIMATE, SØLV, GULL)
Siden utgivelsen av GitLab 12.5 bruker du kunne overvåke tilstanden til miljøer, men ikke mer enn syv miljøer i tre prosjekter. Vi har forbedret dette panelet i versjon 13.4 ved å paginere det for å hjelpe deg å vedlikeholde og administrere miljøene dine i stor skala. Nå kan du se flere miljøer i flere prosjekter.
и .
GitLab tar kontroll over GitLab Terraform-leverandøren
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Nylig vi og planlegge . I løpet av den siste måneden har vi akseptert 21 sammenslåingsforespørsler og stengt 31 billetter, inkludert noen langvarige feil og manglende funksjoner som f.eks. ... Du kan i Terraform-dokumentasjonen.
и .
Uklar API-testing med OpenAPI-spesifikasjoner eller HAR-fil
(ULTIMAT, GULL)
API fuzzing-testing er en fin måte å finne feil og sårbarheter i nettapplikasjonene og APIene dine som andre skannere og testmetoder kan gå glipp av.
API fuzzing-testing i GitLab lar deg tilby eller applikasjonen din og genererer deretter automatisk tilfeldige inputdata designet for å teste kantsaker og finne feil. Resultatene er umiddelbart synlige i rørledningen din.
Dette er vår første API fuzz-testutgivelse, og vi vil gjerne høre hva du synes. Vi har mer på lager for fuzz-testing , som vi vil basere på utgivelsen av denne funksjonen.
и .
Forhåndsvis nye grafer i beregningspanelet
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Tidligere var det ikke en lett oppgave å lage en graf i metrikk-dashbordet i GitLab. Etter at du opprettet beregningen i dashbord YAML-filen, gjorde du endringer i master, uten å kunne verifisere at den nyopprettede grafen fungerer akkurat slik du trenger. Fra og med denne utgivelsen kan du forhåndsvise endringer mens du lager grafen, få en ide om resultatet før du sender endringene til dashbordet YAML-filen.
и .
Data om kodedekning ved tester for alle prosjekter i gruppen
(PREMIUM, ULTIMATE, SØLV, GULL)
Når du administrerer et stort antall prosjekter i GitLab, trenger du én enkelt informasjonskilde om hvordan kodedekningen endrer seg over tid på tvers av alle prosjekter. Tidligere krevde visning av denne informasjonen kjedelig og tidkrevende manuelt arbeid: du måtte laste ned kodedekningsdata fra hvert prosjekt og kombinere det i en tabell.
I utgivelse 13.4 ble det mulig å enkelt og raskt montere .csv fil med alle data om kodedekning for alle prosjekter i gruppen eller for et utvalg prosjekter. Denne funksjonen er MVC, den vil bli fulgt av evnen .
и .
Støtte for nye språk for full fuzz-testing
(ULTIMAT, GULL)
Denne utgivelsen introduserer støtte for flere nye språk for fuzz-testing rettet mot full dekning.
Nå kan du evaluere alle funksjonene til uklar testing i Java-, Rust- og Swift-applikasjonene dine og finne feil og sårbarheter som andre skannere og testmetoder kan gå glipp av.
и .
Varsler på hovedmiljøsiden
(PREMIUM, ULTIMATE, SØLV, GULL)
Miljøsiden viser den generelle tilstanden til miljøene dine. I denne utgivelsen har vi forbedret denne siden ved å legge til varslingsvisning. Utløste varsler sammen med statusen til miljøene dine vil hjelpe deg raskt å iverksette tiltak for å rette opp situasjoner som oppstår.
и .
Nestede rørledninger kan nå kjøre sine egne nestede rørledninger
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Ved å bruke nestede rørledninger er det nå mulig å kjøre nye rørledninger inne i underordnede rørledninger. Det ekstra dybdenivået kan være nyttig hvis du trenger fleksibiliteten til å generere et variabelt antall rørledninger.
Tidligere, når du brukte nestede rørledninger, krevde hver underordnede rørledning at en utløserjobb ble definert manuelt i den overordnede rørledningen. Nå kan du lage nestede rørledninger som dynamisk vil starte et hvilket som helst antall nye nestede rørledninger. For eksempel, hvis du har et monorepository, kan du dynamisk generere den første underrørledningen, som i seg selv vil opprette det nødvendige antallet nye rørledninger basert på endringer i grenen.
и .
Forbedret navigering mellom overordnede og nestede rørledninger
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Tidligere var det ikke særlig praktisk å navigere mellom overordnede og nestede rørledninger – du trengte mange klikk for å komme til ønsket rørledning. Det var heller ikke lett å finne ut hvilken jobb som startet rørledningen. Nå blir det mye lettere å se sammenhengene mellom overordnede og nestede rørledninger.
и .
Parallelle matrisejobber viser relevante variabler i stillingstittel
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Hvis du brukte , du har kanskje lagt merke til at det var vanskelig å bestemme hvilken matrisevariabel som ble brukt for en bestemt jobb, siden jobbnavnene så ut som matrix 1/4. I versjon 13.4 vil du se de relevante variabelverdiene som ble brukt i den jobben i stedet for det generiske jobbnavnet. For eksempel, hvis målet ditt er å feilsøke x86-arkitekturen, vil jobben bli kalt matrix: debug x86.
и .
Andre forbedringer i GitLab 13.4
Koble til en Atlassian-konto
(KJERNE, STARTER, PREMIUM, ULTIMAT)
GitLab-brukere vil nå kunne koble sine GitLab-kontoer til deres Atlassian Cloud-konto. Dette vil tillate deg å logge på GitLab med Atlassian-legitimasjonen din, og vil også legge grunnlaget for fremtidige integrasjonsforbedringer. og med andre produkter fra Atlassian-linjen.
и .
Eksporterer en liste over alle sammenslåingsforpliktelser
(ULTIMAT, GULL)
Compliance-fokuserte organisasjoner trenger en måte å vise revisorer et helhetlig syn på komponentene knyttet til en gitt endring i produksjonen. I GitLab betyr dette å samle alt på ett sted: sammenslåingsforespørsler, billetter, rørledninger, sikkerhetsskanninger og andre forpliktelsesdata. Inntil nå måtte du enten manuelt samle det inn i GitLab eller konfigurere verktøyene dine for å samle informasjonen, noe som ikke var veldig effektivt.
Du kan nå programmatisk samle inn og eksportere disse dataene for å oppfylle revisjonskravene eller utføre andre analyser. For å eksportere en liste over alle sammenslåingsforpliktelser for gjeldende gruppe, må du gå til og klikk på knappen Liste over alle sammenslåingsforpliktelser. Den resulterende filen vil inneholde alle forpliktelsene til sammenslåingsforespørselen, deres forfatter, ID for den tilknyttede sammenslåingsforespørselen, gruppe, prosjekt, bekreftere og annen informasjon.
и .
List opp og administrer personlige tilgangstokener via API
(ULTIMAT, GULL)
Å administrere tilgang til GitLab-navneområdet er en viktig del av compliance-arbeidet. Fra prinsipper om minste privilegium til å deaktivere tidsbestemt tilgang, kan det være flere krav knyttet til personlige tilgangstokener i GitLab. For å gjøre det enklere å vedlikeholde og administrere alle disse brukerlegitimasjonene i navneområdet ditt, har vi gitt muligheten til å liste opp alle personlige tilgangstokener og eventuelt via API.
Disse forbedringene til GitLab API lar brukere liste opp og tilbakekalle sine egne personlige tilgangstokener, og administratorer kan liste opp og tilbakekalle brukernes tokens. Det blir nå enklere for administratorer å se hvem som har tilgang til navneområdet deres, ta tilgangsbeslutninger basert på brukerdata og tilbakekalle personlige tilgangstokener som kan ha blitt kompromittert eller som faller utenfor selskapets retningslinjer for tilgangsadministrasjon.
и .
Relaterte problemer og andre funksjoner er nå i GitLab Core
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
For noen måneder siden annonserte vi en plan for å . Ved å jobbe for å holde dette løftet har vi gitt , и (i den russiske lokaliseringen av GitLab "diskusjonstavle") tilgjengelig i kjerneplanen. Dette gjelder bare for "koblet til" relasjoner; "blokkerte" og "blokkerte" relasjoner forblir i betalte planer.
и .
Viser opprinnelsesgrennavnet i sidefeltet for sammenslåingsforespørsel
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Ved gjennomgang av kodeendringer, diskusjoner og sammenslåingsforespørsel, er det ofte ønskelig å gjøre en lokal utsjekking av filialen for en dypere gjennomgang. Imidlertid blir det stadig vanskeligere å finne trådnavnet ettersom mer innhold legges til i beskrivelsen av sammenslåingsforespørselen og du må bla lenger ned på siden.
Vi har lagt til filialnavnet i sidefeltet for sammenslåingsforespørsel, noe som gjør det tilgjengelig når som helst og eliminerer behovet for å bla gjennom hele siden. Akkurat som lenken til sammenslåingsforespørselen, inneholder kildegrendelen en praktisk "kopi"-knapp.
Takk for ditt enorme bidrag til utviklingen av denne funksjonen!
и .
Indikasjon på tilstedeværelsen av kollapsede filer i fletteforespørselsforskjeller
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Sammenslåingsforespørsler som legger til endringer i flere filer, kollapser noen ganger forskjellene til store filer for å forbedre gjengivelsesytelsen. Når dette skjer, er det mulig å hoppe over en fil ved et uhell under gjennomgang, spesielt ved sammenslåingsforespørsler med et stort antall filer. Fra og med versjon 13.4 vil sammenslåingsforespørsler flagge diff som inneholder foldede filer, slik at du ikke vil gå glipp av disse filene under kodegjennomgang. For enda større klarhet planlegger vi å legge til utheving av disse filene i en fremtidig utgivelse. Følg med for oppdateringer på .
и .
Advarsel om tilstedeværelsen av skjulte filer i diff-en til en sammenslåingsforespørsel
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
I delen for forskjeller i sammenslåingsforespørsel blir store filer slått sammen for å forbedre ytelsen. Men når du ser gjennom koden, kan noen filer gå glipp av når kontrolløren ruller gjennom listen over filer, siden alle store filer er skjult.
Vi har lagt til en synlig advarsel øverst på diff-siden for sammenslåingsforespørsel for å informere brukere om at det er en sammenslått fil i denne delen. På denne måten går du ikke glipp av endringer i sammenslåingsforespørselen under gjennomgangen.
и .
Automatisk gjenoppretting av Gitaly-klyngelageret
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Tidligere, når primærnoden til en Gitaly-klynge gikk offline, ble depotene på den noden merket som skrivebeskyttet. Dette forhindret tap av data i situasjoner der det var endringer på noden som ennå ikke var replikert. Da noden kom online igjen, ble ikke GitLab automatisk gjenopprettet, og administratorer måtte manuelt starte synkroniseringsprosessen eller akseptere tap av data. Andre situasjoner, for eksempel svikt i en replikeringsjobb på en sekundær node, kan også føre til foreldede eller skrivebeskyttede arkiver. I dette tilfellet forble depotet foreldet til neste skriveoperasjon skjedde, som ville starte replikeringsjobben.
For å løse dette problemet planlegger nå en replikeringsjobb når den oppdager et utdatert depot på en node og den nyeste versjonen av depotet på en annen. Denne replikeringsjobben holder depotet oppdatert automatisk, og eliminerer behovet for å gjenopprette data manuelt. Automatisk gjenoppretting sikrer også at sekundære noder raskt blir oppdatert hvis en replikeringsjobb mislykkes, i stedet for å vente på neste skriveoperasjon. Siden mange Gilaly-klynger lagrer et stort antall depoter, reduserer dette betydelig tiden administratorer og pålitelighetsingeniører bruker på å gjenopprette data etter en feil.
I tillegg starter automatisk reparasjon replikering av repositories på enhver ny Gitaly-node som er lagt til klyngen, og eliminerer manuelt arbeid når du legger til nye noder.
и .
Merk en gjøremålsoppgave som fullført på designsiden
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Effektiv kommunikasjon i GitLab er basert på gjøremålslister. Hvis du blir nevnt i en kommentar, er det avgjørende å kunne hoppe til en oppgave og enten begynne å gjøre noe eller merke den som fullført. Det er også viktig å kunne tildele en oppgave til deg selv når du skal jobbe med noe eller komme tilbake til det senere.
Tidligere kunne du ikke legge til oppgaver eller merke dem som fullførte når du jobbet med design. Dette forstyrret effektiviteten av kommunikasjonen mellom produktteam alvorlig, siden gjøremål er et kritisk element i GitLab-arbeidsflyten.
I versjon 13.4 fanger design opp billettkommentarer ved bruk av oppgaver, noe som gjør arbeidet med dem mer konsekvent og effektivt.
и .
Forbedret feilsøkingsveiledning for CI/CD
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Vi har forbedret feilsøkingsveiledningen for GitLab CI/CD med mer informasjon om vanlige problemer du kan støte på. Vi håper at den forbedrede dokumentasjonen vil være en verdifull ressurs for å hjelpe deg med å komme i gang med GitLab CI/CD raskt og enkelt.
и .
Sammenslåingsforespørsler faller ikke lenger ut av sammenslåingskøen
(PREMIUM, ULTIMATE, SØLV, GULL)
Tidligere kunne sammenslåingsforespørsler falle ut av sammenslåingskøen ved et uhell på grunn av sene kommentarer. Hvis en sammenslåingsforespørsel allerede var i køen og noen la til en kommentar til den som skapte en ny uløst diskusjon, ble sammenslåingsforespørselen ansett som ikke kvalifisert for en sammenslåing og ville falle ut av køen. Nå, etter at en sammenslåingsforespørsel er lagt til i sammenslåingskøen, kan nye kommentarer legges til uten frykt for å forstyrre sammenslåingsprosessen.
и .
Viser kodedekningsverdien for en jobb i en sammenslåingsforespørsel
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Utviklere bør kunne se kodedekningsverdien etter at pipelinen er fullført - selv i komplekse scenarier som å kjøre en pipeline med flere jobber som må analyseres for å beregne dekningsverdien. Tidligere viste widgeten for sammenslåingsforespørsel kun gjennomsnittet av disse verdiene, noe som betydde at du måtte navigere til jobbsiden og tilbake til sammenslåingsforespørselen for å få mellomliggende dekningsverdier. For å spare deg for tid og disse ekstra trinnene, fikk vi widgeten til å vise den gjennomsnittlige dekningsverdien, dens endringer mellom mål- og kildegrenene, og et verktøytips som viser dekningsverdien for hver jobb basert på som gjennomsnittet ble beregnet på.
и .
Fjerne pakker fra pakkeregisteret når du viser en gruppe
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
GitLab-pakkeregisteret er et sted å lagre og distribuere pakker i forskjellige formater. Når du har mange pakker i prosjektet eller gruppen, må du raskt identifisere ubrukte pakker og fjerne dem for å hindre folk i å laste dem ned. Du kan fjerne pakker fra registeret ditt via eller gjennom pakkeregisterets brukergrensesnitt. Men til nå kunne du ikke fjerne pakker når du ser på en gruppe gjennom brukergrensesnittet. Som et resultat måtte du fjerne unødvendige pakker på prosjektbasis, noe som var ineffektivt.
Du kan nå fjerne pakker når du ser på en gruppes pakkeregister. Bare gå til gruppens pakkeregisterside, filtrer pakkene etter navn og fjern alle du ikke trenger.
и .
Skalering av Conan-pakker til prosjektnivå
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Du kan bruke Conan-depotet i GitLab til å publisere og distribuere C/C++-avhengigheter. Imidlertid kunne tidligere pakker bare skaleres til forekomstnivå, da Conan-pakkenavnet kun kunne være på maksimalt 51 tegn. Hvis du ønsker å publisere en pakke fra en undergruppe, for eksempel gitlab-org/ci-cd/package-stage/feature-testing/conan, det var nesten umulig å gjøre.
Du kan nå skalere Conan-pakker ned til prosjektnivå, noe som gjør det enkelt å publisere og distribuere prosjektenes avhengigheter.
и .
Støtte for nye pakkeadministratorer og språk for avhengighetsskanning
(ULTIMAT, GULL)
Vi er glade for å legge til avhengighetsskanninger for C-, C++-, C#- og .Net-kodeprosjekter som bruker NuGet 4.9+ eller Conan-pakkeadministratorer til listen vår . Du kan nå aktivere avhengighetsskanning som en del av det sikre stadiet for å se etter kjente sårbarheter i avhengigheter lagt til gjennom pakkeadministratorer. Svakhetene som ble funnet vil vises i sammenslåingsforespørselen din sammen med alvorlighetsgraden, slik at du vet før du utfører sammenslåingen hvilke risikoer den nye avhengigheten medfører. Du kan også konfigurere prosjektet etter behov for avhengigheter med sårbarheter med kritisk (Kritisk), høy (Høy) eller ukjent (Ukjent) alvorlighetsgrad.
и .
Varsler når du endrer innstillingen for sammenslåingsforespørsel til "Slå sammen når rørledningen er fullført"
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Tidligere, når du anga innstillingene for sammenslåingsforespørsel Slå sammen når rørledningen er ferdig (Merge When Pipeline Succeeds, MWPS) ingen e-postvarsling ble sendt. Du måtte kontrollere statusen manuelt eller vente på et sammenslåingsvarsel. Med denne utgivelsen er vi glade for å presentere brukerbidrag , som løste dette problemet ved å legge til automatiske varsler til alle som abonnerer på en sammenslåingsforespørsel når en anmelder endrer sammenslåingsinnstillingen til MWPS.
и .
Opprette EKS-klynger med en brukerspesifisert versjon av Kubernetes
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
GitLab-brukere kan nå velge versjonen av Kubernetes som vil bli levert av EKS; du kan velge mellom versjon 1.14–1.17.
и .
Opprette hendelser som billetttyper
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Ikke alle problemer som oppstår umiddelbart utløser varsler: brukere rapporterer strømbrudd og teammedlemmer undersøker ytelsesproblemer. Hendelser er nå en type billett, så teamene dine kan raskt opprette dem som en del av deres normale arbeidsflyt. Klikk Ny oppgave fra hvor som helst i GitLab, og i felten Type velg hendelse.
и .
Omtale GitLab-varsler i Markdown
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Vi har forbedret GitLab-varsler ved å legge til en ny omtaletype spesifikt for dem i GitLab Markdown, noe som gjør det enklere å dele og nevne varsler. Bruk ^alert#1234å nevne varselet i et hvilket som helst Markdown-felt: i hendelser, billetter eller sammenslåingsforespørsler. Dette vil også hjelpe deg med å identifisere jobber som er opprettet fra varsler i stedet for billetter eller sammenslåingsforespørsler.
и .
Viser varslingsbelastningen etter hendelse
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Varslingsbeskrivelsen inneholder informasjon som er kritisk for feilsøking og gjenoppretting, og denne informasjonen skal være lett tilgjengelig slik at du ikke trenger å bytte verktøy eller faner mens du jobber med å løse en hendelse. Hendelser opprettet fra varsler viser hele varslingsbeskrivelsen i fanen Varslingsdetaljer.
75 % raskere avansert søk
(STARTER, PREMIUM, ULTIMATE, BRONSE, SØLV, GULL)
GitLab, som en enkelt applikasjon, har den unike muligheten til å gjøre innholdsoppdagelse på tvers av hele DevOps-arbeidsflyten din raskt. I GitLab 13.4 gir avansert søk resultater 75 % raskere når det , som på GitLab.com.
и .
Viser slettede prosjekter for administratorer
(KJERNE, STARTER, PREMIUM, ULTIMAT)
Det var en mulighet for å utsette sletting av prosjekt . Tidligere var det imidlertid ikke mulig å se alle prosjekter som ventet på sletting på ett sted. GitLab-brukerforekomstadministratorer kan nå se alle ventende sletteprosjekter på ett sted, sammen med knapper for enkelt å gjenopprette disse prosjektene.
Denne funksjonen gir administratorer større kontroll over prosjektsletting ved å samle all relevant informasjon på ett sted og gi muligheten til å angre uønskede slettingshandlinger.
Takk for denne funksjonen!
и .
Lagt til støtte for gruppe-push-regler til API
(STARTER, PREMIUM, ULTIMATE, BRONSE, SØLV, GULL)
Tidligere kunne gruppe-push-regler bare konfigureres ved å besøke hver gruppe individuelt gjennom GitLab-grensesnittet og bruke disse reglene. Du kan nå administrere disse reglene via et API for å støtte dine tilpassede verktøy og GitLab-automatisering.
и .
Oppheve personlige tilgangstokener for selvadministrert legitimasjonslagring
(ULTIMAT)
Gir administratorer informasjonen de trenger for å administrere brukerlegitimasjon for deres GitLab-forekomst. Fordi samsvarsfokuserte organisasjoner varierer i strengheten til retningslinjer for legitimasjonsadministrasjon, har vi lagt til en knapp som lar administratorer eventuelt tilbakekalle en brukers personlige tilgangstoken (PAT). Administratorer kan nå enkelt tilbakekalle potensielt kompromitterte PAT-er. Denne funksjonen er nyttig for organisasjoner som ønsker mer fleksible samsvarsalternativer for å minimere forstyrrelser for brukerne.
и .
Konfigurasjonsfil for den statiske nettstedredigereren
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
I GitLab 13.4 introduserer vi en ny måte å tilpasse den statiske nettstedredigereren. Selv om konfigurasjonsfilen ikke lagrer eller mottar noen innstillinger i denne utgivelsen, legger vi grunnlaget for fremtidig tilpasning av redigeringsadferd. I fremtidige utgivelser vil vi legge til filen .gitlab/static-site-editor.yml parametere for installasjon på hvilken , overstyrer Markdown-syntaksinnstillinger og andre redigeringsinnstillinger.
и .
Redigere den innledende delen av en fil ved hjelp av et statisk nettstedsredigeringsprogram
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Frontmaterie er en fleksibel og praktisk måte å definere sidevariabler i datafiler for behandling av den statiske nettstedsgeneratoren. Den brukes vanligvis til å angi sidetittel, layoutmal eller forfatter, men kan brukes til å sende alle typer metadata til generatoren når siden gjengis i HTML. Inkludert på toppen av hver datafil, er innledningen typisk formatert som YAML eller JSON og krever konsistent og presis syntaks. Brukere som ikke er kjent med spesifikke syntaksregler kan utilsiktet skrive inn ugyldig markering, som igjen kan forårsake formateringsproblemer eller til og med byggefeil.
WYSIWYG-redigeringsmodusen til den statiske nettstedredigereren fjerner allerede introen fra editoren for å forhindre disse formateringsfeilene. Dette forhindrer deg imidlertid i å endre verdiene som er lagret i denne delen uten å gå tilbake til redigering i kildemodus. I GitLab 13.4 kan du få tilgang til ethvert felt og redigere verdien i et kjent skjemabasert grensesnitt. Når knappen trykkes Innstillinger (innstillinger) åpnes et panel som viser et skjemafelt for hver nøkkel definert i begynnelsen. Feltene er fylt ut med gjeldende verdi, og å redigere noen av dem er like enkelt som å skrive det inn i nettskjemaet. Redigering av introduksjonen på denne måten unngår kompleks syntaks og gir deg full kontroll over innholdet samtidig som du sikrer at det endelige resultatet formateres konsekvent.
и .
GitLab for Jira og DVCS Connector er nå i Core
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
For Jira-brukere på GitLab: и lar deg vise informasjon om GitLab-forpliktelser og slå sammen forespørsler direkte i Jira. Kombinert med vår innebygde Jira-integrasjon kan du enkelt flytte mellom de to appene mens du jobber.
Disse funksjonene var tidligere bare tilgjengelig i vår Premium-plan, men er nå tilgjengelig for alle brukere!
и .
Flertallsstemmegivning for Gitaly-klyngetransaksjoner (beta)
(KJERNE, STARTER, PREMIUM, ULTIMAT)
En Gitaly-klynge lar deg replikere Git-lagre til flere "varme" Gitaly-noder. Dette øker feiltoleransen ved å eliminere enkeltpunkter for feil. , introdusert i GitLab 13.3, fører til at endringer blir kringkastet til alle Gitaly-noder i klyngen, men bare Gitaly-noder som stemmer i samsvar med primærnoden lagrer endringene til disken. Hvis alle replika-nodene ikke er enige, vil bare én kopi av endringen bli lagret på disken, noe som skaper et enkelt feilpunkt inntil asynkron replikering er fullført.
Flertallsstemmegivning forbedrer feiltoleransen ved å kreve samtykke fra et flertall av noder (ikke alle) før endringene lagres på disken. Hvis denne vekslingsfunksjonen er aktivert, skal skrivingen lykkes på flere noder. Dissensende noder synkroniseres automatisk ved å bruke asynkron replikering fra de nodene som har dannet et quorum.
и .
Tilpasset skjemastøtte for JSON-validering i Web IDE
(PREMIUM, ULTIMATE, SØLV, GULL)
Prosjekter der folk skriver konfigurasjoner i JSON eller YAML er ofte utsatt for problemer fordi det er lett å skrive feil og ødelegge noe. Det er mulig å skrive inspeksjonsverktøy for å fange opp disse problemene i CI-pipelinen, men å bruke en JSON-skjemafil kan være nyttig for å gi dokumentasjon og hint.
Prosjektdeltakere kan definere banen til et tilpasset skjema i en fil i depotet sitt .gitlab/.gitlab-webide.yml, som spesifiserer skjemaet og banen til filene som skal sjekkes. Når du laster inn en bestemt fil i web-IDE, vil du se ytterligere tilbakemeldinger og validering for å hjelpe deg med å lage filen.
и .
Forgreningsgrense for Directed Acyclic Graph (DAG) økt til 50
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Hvis du bruker transportbånd (Directed Acyclic Graph (DAG)), kan det hende du finner ut at det er en grense på 10 jobber som en jobb kan spesifisere i needs:, for hardt. I 13.4 ble standardgrensen økt fra 10 til 50 for å tillate mer komplekse nettverk av relasjoner mellom jobber i rørledningene dine.
Hvis du er administrator for en tilpasset GitLab-forekomst, kan du øke denne grensen enda høyere ved å sette opp en vekslefunksjon, selv om vi ikke tilbyr offisiell støtte for dette.
и .
Forbedret oppførsel needs for tapte oppgaver
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
I noen tilfeller kan en tapt jobb i en pipeline feilaktig anses som vellykket for avhengigheter spesifisert i needs, som førte til at påfølgende jobber kjørte, noe som ikke skulle ha skjedd. Denne oppførselen er fikset i versjon 13.4, og needs håndterer nå saker med tapte oppgaver.
и .
Fest den siste quest-artefakten for å forhindre at den blir slettet
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
GitLab låser nå automatisk den siste vellykkede jobben og pipeline-artefakten på enhver aktiv gren, sammenslåingsforespørsel eller tag for å forhindre at den slettes etter utløp. Det blir lettere å sette mer aggressive utløpsregler for å rydde opp i gamle gjenstander. Dette bidrar til å redusere diskplassforbruket og sikrer at du alltid har en kopi av den siste artefakten fra pipelinen.
и .
CI/CD-veiledning til rørledningsoptimalisering
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Optimalisering av CI/CD-pipeline kan forbedre leveringshastigheten og spare penger. Vi har forbedret dokumentasjonen vår til å inkludere en hurtigveiledning for å få mest mulig ut av å optimalisere rørledningene dine.
и .
Testrapport sortert etter teststatus
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
er en enkel måte å se resultatene av alle testene i en pipeline. Men med et stort antall tester kan det ta lang tid å finne mislykkede tester. Andre problemer som kan gjøre rapporten vanskelig å bruke inkluderer problemer med å rulle gjennom lange sporutdata og tidsavrunding til null for tester som kjører på mindre enn 1 sekund. Nå, som standard, når du sorterer en testrapport, plasserer den først mislykkede tester i begynnelsen av rapporten, og deretter sorterer testene etter varighet. Dette gjør det lettere å finne feil og lange tester. I tillegg vises testvarighetene nå i millisekunder eller sekunder, noe som gjør dem mye raskere å lese, og tidligere rulleproblemer er også løst.
и .
Begrensninger for størrelsen på filer som lastes opp til pakkeregisteret
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Det er nå begrensninger på størrelsen på pakkefiler som kan lastes opp til GitLab-pakkeregisteret. Restriksjoner er lagt til for å optimalisere pakkeregisterytelsen og forhindre misbruk. Grensene varierer avhengig av pakkeformatet. For GitLab.com er maksimale filstørrelser:
- Conan: 250 MB
- Maven: 3GB
- NPM: 300 MB
- NuGet: 250MB
- PyPI: 3 GB
For tilpassede GitLab-forekomster er standardinnstillingene de samme. Administratoren kan imidlertid oppdatere begrensningene ved hjelp av .
и .
Bruk CI_JOB_TOKEN til å publisere PyPI-pakker
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Du kan bruke GitLab PyPI-depotet til å opprette, publisere og dele Python-pakker sammen med kildekode og CI/CD-pipelines. Tidligere kunne du imidlertid ikke autentisere deg til depotet ved å bruke en forhåndsdefinert miljøvariabel CI_JOB_TOKEN. Som et resultat måtte du bruke din personlige legitimasjon for å oppdatere PyPI-depotet, eller du kan ha bestemt deg for ikke å bruke depotet i det hele tatt.
Det er nå enklere å bruke GitLab CI/CD til å publisere og installere PyPI-pakker ved å bruke en forhåndsdefinert miljøvariabel CI_JOB_TOKEN.
и .
DAST skannerprofiler på forespørsel
(ULTIMAT, GULL)
Til DAST-skanningen på forespørsel som var , DAST-skannerprofiler er lagt til. De utvider konfigurasjonsmulighetene til disse skanningene, slik at du raskt kan opprette flere profiler for å dekke flere skanningstyper. I 13.4 inkluderer robotsøkerobotprofilen en innstilling for tidsavbrudd for søkerobot som angir hvor lenge DAST-søkeroboten skal kjøre når den prøver å oppdage alle sidene på et gjennomsøkt nettsted. Profilen inkluderer også en tidsavbruddsinnstilling for målnettstedet for å angi hvor lenge søkeroboten skal vente på at et nettsted blir tilgjengelig før den avbryter gjennomsøkingen hvis nettstedet ikke svarer med en statuskode på 200 eller 300. Ettersom vi fortsetter å forbedre denne funksjonen vil denne funksjonen bli lagt til skannerprofilen i fremtidige utgivelser; ytterligere konfigurasjonsparametere vil bli lagt til.
и .
En enkel omdirigeringskonfigurasjonsfil for GitLab-sider
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Hvis du bruker GitLab-sider og ønsker å administrere URL-endringer bedre, har du kanskje lagt merke til at det ikke var mulig å administrere omdirigeringer på GitLab-sidene dine. GitLab lar deg nå konfigurere regler for å omdirigere en URL til en annen for ditt Pages-nettsted ved å legge til en konfigurasjonsfil til depotet. Denne funksjonen er gjort mulig takket være bidraget fra Kevin Barnett (), vår Eric Eastwood () og GitLab-team. Takk alle sammen for deres innspill.
и .
Terraform-stat administrert av GitLab
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Tilgang til tidligere versjoner av Terraform state er nødvendig både for samsvar og for feilsøking om nødvendig. Støtte for versjonering av Terraform-tilstand administrert av GitLab er gitt fra og med GitLab 13.4. Versjonsstyring aktiveres automatisk for nye Terraform-tilstandsfiler. Eksisterende Terraform-tilstandsfiler vil være i en senere utgivelse.
и .
Viktig informasjon om hendelsesvarsling
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Når du behandler hendelser, må du enkelt kunne fastslå hvor lenge et varsel var åpent og hvor mange ganger hendelsen ble utløst. Disse detaljene er ofte avgjørende for å bestemme innvirkningen på kunden og hva teamet ditt bør ta opp først. I det nye panelet med hendelsesdetaljer viser vi starttidspunktet for varselet, antall hendelser og en lenke til det opprinnelige varselet. Denne informasjonen er tilgjengelig for hendelser som genereres fra varsler.
и .
Innstilling og redigering av alvorlighetsgradsparameteren for hendelsen
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Hendelsesalvorlighetsdimensjonen lar respondere og interessenter bestemme virkningen av et strømbrudd, samt metoden og det haster med responsen. Ettersom teamet ditt deler resultater under hendelsesløsning og gjenoppretting, kan de endre denne innstillingen. Du kan nå redigere alvorlighetsgraden av en hendelse i høyre sidefelt på siden med hendelsesdetaljer, og alvorlighetsgraden vises i listen over hendelser.
и .
Opprette, redigere og slette sikkerhetsregler for containernettverk
(ULTIMAT, GULL)
Denne forbedringen av Container Network Security Rule Editor lar brukere enkelt opprette, redigere og slette reglene sine direkte fra GitLab-brukergrensesnittet. Editor funksjoner inkluderer .yaml for erfarne brukere og en regeleditor med et intuitivt grensesnitt for de som er nye til nettverksregler. Du finner alternativer for administrasjon av nye regler i delen Sikkerhet og samsvar > Trusselhåndtering > Regler (Sikkerhet og samsvar > Trusselhåndtering > Retningslinjer).
и .
Støtte for Azure blob-lagring
(KJERNE, STARTER, PREMIUM, ULTIMAT, GRATIS, BRONSE, SØLV, GULL)
Både GitLab og GitLab Runner støtter nå , noe som gjør det enklere å kjøre GitLab-tjenester på Azure.
GitLab-forekomster støtter Azure for alle typer objektlagre, inkludert LFS-filer, CI-artefakter og . Følg installasjonsinstruksjonene for å konfigurere Azure Blob-lagring eller .
GitLab jobbprosessorer støtter også Azure for lagring . Azure-lagring kan konfigureres ved hjelp av delen .
и .
Omnibus ARM64-pakker for Ubuntu og OpenSUSE
(KJERNE, STARTER, PREMIUM, ULTIMAT)
Som svar på økende etterspørsel etter støtte for å kjøre GitLab på 64-biters ARM-arkitektur, er vi glade for å kunngjøre tilgjengeligheten av den offisielle ARM64 Ubuntu 20.04 Omnibus-pakken. Stor takk til Zitai Chen og Guillaume Gardet for de enorme bidragene de ga – deres sammenslåingsforespørsler spilte en nøkkelrolle i dette!
For å laste ned og installere pakken for Ubuntu 20.04, gå til vår og velg Ubuntu.
и .
Smartkortautentiseringsstøtte for GitLab Helm-diagram
(PREMIUM, ULTIMAT)
Smartkort, for eksempel Common Access Cards (CAC), kan nå brukes til å autentisere til en GitLab-forekomst distribuert via Helm-diagram. Smartkort autentiseres mot en lokal database ved hjelp av X.509-sertifikater. Med dette er smartkortstøtte med Helm-diagram nå i tråd med smartkortstøtten som er tilgjengelig i Omnibus-distribusjoner.
и .
Detaljerte utgivelsesnotater og oppdaterings-/installasjonsinstruksjoner kan leses i det originale engelske innlegget: .
Vi jobbet med oversettelse fra engelsk , , и .
Kilde: www.habr.com