GitLab 11.10 med instrumentpanelspipelines, sammanslagna resultatpipelines och flerradsförslag i sammanslagningsförfrågningar.
Bekväm information om prestanda för pipelines i olika projekt
GitLab fortsätter att öka insynen i DevOps livscykel. I detta nummer på панель управления lagt till en översikt över pipelinestatus.
Detta är praktiskt även om du studerar pipeline för ett enskilt projekt, men är särskilt användbart om flera projekt, - och detta händer vanligtvis om du använder mikrotjänster och vill köra en pipeline för att testa och leverera kod från olika projektförråd. Nu kan du direkt se föreställningen rörledningar på kontrollpanelen, var de än utförs.
Kör pipelines för sammanslagna resultat
Med tiden divergerar käll- och målgrenarna och det kan uppstå en situation där de klarar sig var för sig, men inte fungerar tillsammans. Nu kan du kör pipelines för sammanslagna resultat innan sammanslagning. På så sätt kommer du snabbt att märka fel som bara skulle dyka upp om ändringar ofta flyttades mellan grenar, vilket innebär att du kommer att korrigera pipelinefel mycket snabbare och kommer att använda GitLab Runner.
Optimera samarbetet ytterligare
GitLab 11.10 lägger till ännu fler funktioner för sömlöst samarbete och förenklade arbetsflöden. I föregående nummer vi introducerade förslag på sammanslagningsförfrågningar, där en granskare kunde föreslå en ändring av en rad i en kommentar till en sammanslagningsförfrågan, och den kunde omedelbart committeras direkt från kommentarstråden. Våra användare gillade det och bad att få utöka den här funktionen. Nu kan du erbjuda ändringar för flera rader, som anger vilka rader som ska tas bort och vilka som ska läggas till.
Månadens mest värdefulla medarbetare (MVP) — Takuya Noguchi
Månadens mest värdefulla medarbetare är Takuya Noguchi (Takuya Noguchi). Takuya gjorde ett bra jobb för GitLabs ära: fixade buggar, slutförda brister i backend och frontend och förbättrat användargränssnittet. Tack!
Huvudfunktioner i GitLab 11.10
Rörledningar på kontrollpanelen
PREMIUM, ULTIMAT, SILVER, GULD
Instrumentpanelen i GitLab visar information om projekt över hela din GitLab-instans. Du lägger till enskilda projekt ett i taget och kan välja vilket projekt som intresserar dig.
I den här utgåvan har vi lagt till information om pipelinestatus till instrumentpanelen. Nu ser utvecklare funktionaliteten hos pipelines i alla nödvändiga projekt - i ett gränssnitt.
Pipelines för sammanslagna resultat
PREMIUM, ULTIMAT, SILVER, GULD
Det är vanligt att källgrenen avviker från målgrenen med tiden om du inte kontinuerligt trycker på ändringar mellan dem. Som ett resultat är käll- och målgrenrörledningarna "gröna" och det finns inga sammanslagningskonflikter, men sammanslagningen misslyckas på grund av inkompatibla ändringar.
När pipelinen för sammanslagningsförfrågan automatiskt skapar en ny länk som innehåller det kombinerade resultatet av sammanslagning av käll- och målgrenarna, kan vi köra pipelinen på den länken och säkerställa att det övergripande resultatet fungerar.
Om du använder merge request pipelines (i valfri kapacitet) och använder privata GitLab runners version 11.8 eller äldre, måste du uppdatera dem för att undvika detta problem gitlab-ee#11122. Detta påverkar inte användare av offentliga GitLab-löpare.
När ni arbetar tillsammans med sammanslagningsförfrågningar upptäcker ni ofta problem och föreslår lösningar. Sedan GitLab 11.6 stöder vi förslag till ändringar för en rad.
I version 11.10 kan kommentarer om sammanslagningsförfrågan föreslå ändringar på flera rader, och sedan kan alla med skrivbehörighet till den ursprungliga grenen acceptera dem med ett klick. Tack vare den nya funktionen kan du undvika copy-paste, som i tidigare versioner.
Genvägar i ett område
PREMIUM, ULTIMAT, SILVER, GULD
Med etiketter i samma omfattning kan team tillämpa ömsesidigt uteslutande etiketter (i samma omfattning) på ett problem, sammanslagningsförfrågan eller episk i scenarier med anpassade fält eller anpassade arbetsflödestillstånd. De konfigureras med en speciell kolonsyntax i etiketttiteln.
Låt oss säga att du behöver ett anpassat fält i uppgifter för att spåra operativsystemet för den plattform som dina funktioner riktar sig till. Varje uppgift måste relatera till endast en plattform. Du kan skapa genvägar platform::iOS, platform::Android, platform::Linux och andra efter behov. Om du använder en sådan genväg till en uppgift kommer den automatiskt att ta bort en annan befintlig genväg som börjar med platform::.
Låt oss säga att du har genvägar workflow::development, workflow::review и workflow::deployed, som indikerar tillståndet för ditt teams arbetsflöde. Om uppgiften redan har en genväg workflow::development, och utvecklaren vill flytta uppgiften till scenen workflow::review, den tillämpar bara den nya genvägen och den gamla (workflow::development) raderas automatiskt. Det här beteendet finns redan när du flyttar uppgifter mellan listor med genvägar på aktivitetstavlan som representerar ditt teams arbetsflöde. Nu kan gruppmedlemmar som inte arbetar med uppgiftspanelen direkt ändra arbetsflödestillståndet i själva uppgifterna.
När du vanligtvis använder ett containerregister med CI-pipelines, skickar du flera separata ändringar till en enda tagg. På grund av Dockers distributionsimplementering är standardbeteendet att spara alla ändringar i systemet, men det slutar med att de tar upp mycket minne. Om du använder parametern -m с registry-garbage-collect, kan du snabbt ta bort alla tidigare ändringar och frigöra värdefullt utrymme.
Köper ytterligare CI Runner-minuter
BRONS, SILVER, GULD
Användare med betalda GitLab.com-planer (guld, silver, brons) kan nu köpa ytterligare CI Runner-minuter. Tidigare var det nödvändigt att klara den kvot som planen angav. Med denna förbättring kan du förköpa överkvoterade minuter för att undvika avbrott på grund av pipelineavstängningar.
Nu kostar 1000 minuter $8, och du kan köpa så många av dem du vill. Ytterligare minuter kommer att börja förbrukas när du har spenderat hela din månatliga kvot, och resten av de extra minuterna kommer att rullas över till nästa månad. I framtida release vi vill lägga till den här funktionen till gratisplaner också.
Med Auto DevOps går team över till moderna DevOps-metoder nästan utan ansträngning. Från och med GitLab 11.10 tillhandahålls varje jobb i Auto DevOps som oberoende mall. Användare kan använda функцию includes i GitLab CI för att aktivera individuella steg av Auto DevOps och samtidigt använda din anpassade fil gitlab-ci.yml. På så sätt kan du bara aktivera de jobb du behöver och dra nytta av uppströmsuppdateringar.
Hantera gruppmedlemmar automatiskt på GitLab.com med hjälp av SCIM
SILVER GULD
Tidigare var du tvungen att manuellt hantera gruppmedlemskap på GitLab.com. Du kan nu använda SAML SSO och hantera medlemskap med SCIM för att skapa, ta bort och uppdatera användare på GitLab.com.
Detta är särskilt användbart för företag med ett stort antal användare och centraliserade identitetsleverantörer. Nu kan du ha en enda källa till sanning, som Azure Active Directory, och användare skapas och tas bort automatiskt via identitetsleverantören snarare än manuellt.
Logga in på GitLab.com via SAML-leverantör
SILVER GULD
Tidigare, när man använde SAML SSO för grupper, krävdes användaren att logga in med GitLab-uppgifter och en identitetsleverantör. Du kan nu logga in direkt via SSO som en GitLab-användare kopplad till en konfigurerad grupp.
Användare behöver inte logga in två gånger, vilket gör det lättare för företag att använda SAML SSO för GitLab.com.
Andra förbättringar i GitLab 11.10
Episkt schema för barn
ULTIMAT, GULD
I den tidigare utgåvan lade vi till underordnade epos (epos av epos) för att hjälpa dig hantera din jobbfördelningsstruktur. Underordnade epos visas på föräldraepikens sida.
I den här utgåvan visar den överordnade epossidan en kontur av underordnade epos så att team kan se tidslinjen för underordnade epos och kan hantera tidsberoende.
I den här versionen introducerar vi informativa skärmar som dyker upp när du håller muspekaren över en länk för sammanfogningsförfrågan. Tidigare visade vi bara rubriken för sammanslagningsförfrågan, men nu visar vi även status för sammanslagningsförfrågan, CI-pipelinestatus och kort URL.
Git-arbetsflöden för att släppa eller skicka programvara involverar ofta flera långsiktiga grenar – för att fixa tidigare versioner (t.ex. stable-11-9) eller att gå från kvalitetstestning till produktion (t.ex. integration), men det är inte lätt att hitta sammanslagningsförfrågningar för dessa grenar bland de många öppna sammanslagningsförfrågningarna.
Listan över sammanslagningsförfrågningar för projekt och grupper kan nu filtreras av målgrenen för sammanslagningsförfrågan för att göra det lättare att hitta den du behöver.
Om vi använder den stambaserade utvecklingsmetoden bör vi undvika långlivade grenar till förmån för små, tillfälliga grenar med en enda ägare. Små förändringar skjuts ofta direkt till målgrenen, men om man gör det riskerar man att bryta bygget.
I den här utgåvan stöder GitLab nya Git-push-alternativ för att automatiskt öppna sammanslagningsförfrågningar, ställa in målgrenen och genomdriva en sammanslagning på framgångsrik pipeline från kommandoraden vid tidpunkten för push till grenen.
Förbättrad integration med externa instrumentpaneler
GitLab kan komma åt flera Prometheus-servrar (miljö, projekt och grupper (förväntat)), men att ha flera slutpunkter kan öka komplexiteten eller kanske inte stöds av standardinstrumentpaneler. Med den här utgåvan kan team använda ett enda Prometheus API, vilket gör integrationen med tjänster som Grafana mycket enklare.
I en projekt Wiki kan team dela dokumentation och annan viktig information tillsammans med källkod och uppgifter. Med den här utgåvan kan du sortera listan över Wiki-sidor efter skapandedatum och titel för att snabbt hitta nyligen skapat innehåll.
Övervakningsresurser som efterfrågas av klustret
ULTIMAT, GULD
GitLab hjälper dig att övervaka ditt Kubernetes-kluster för utvecklings- och produktionsapplikationer. Från och med den här versionen, övervaka CPU- och minnesförfrågningar från ditt kluster för att upptäcka potentiella problem innan de blir problem.
Se Load Balancer Metrics i Grafana Dashboard
CORE, STARTER, PREMIUM, ULTIMATE
Det är mycket viktigt att övervaka hälsan hos din GitLab-instans. Tidigare tillhandahöll vi standardinstrumentpaneler genom en inbäddad Grafana-instans. Från och med den här utgåvan har vi inkluderat ytterligare instrumentpaneler för övervakning av NGINX-lastbalanserare.
SAST för Elixir
ULTIMAT, GULD
Vi fortsätter att utöka språkstödet och fördjupa säkerhetskontrollerna. I den här versionen har vi aktiverat säkerhetskontroller för projekt på Elixir och projekt skapade på Phoenix plattform.
Flera frågor i ett diagram
PREMIUM, ULTIMAT, SILVER, GULD
I GitLab kan du skapa diagram för att visualisera de mätvärden du samlar in. Ofta, till exempel, om du behöver titta på det maximala eller genomsnittliga värdet för ett mått, vill du visa flera värden på ett diagram. Från och med den här versionen har du denna möjlighet.
Vi har lagt till resultat från Dynamic Application Security Testing (DAST) till teamets säkerhetsinstrumentpanel förutom SAST, containerskanning och beroendeskanning.
Lägga till metadata i en containerskanningsrapport
ULTIMAT, GULD
I den här versionen innehåller containerskanningsrapporten mer metadata – vi har lagt till påverkad komponent (en Clair-funktion) till befintlig metadata: prioritet, ID (med hänvisning till mitre.org) och nivå som påverkas (t.ex. debian:8).
Lägga till en statistikrapporttyp för att slå samman förfrågningar
PREMIUM, ULTIMAT, SILVER, GULD
GitLab tillhandahåller redan flera typer av rapporter som kan inkluderas direkt i sammanslagningsförfrågningar: från rapporter till kodkvalitet и enhetstestning på verifieringsstadiet fram till SAST и DAST på skyddsstadiet.
Även om detta är viktiga rapporter behövs också grundläggande information som passar olika scenarier. I GitLab 11.10 tillhandahåller vi statistikrapportering direkt i sammanslagningsbegäran, som förväntar sig ett enkelt nyckel-värdepar. På så sätt spårar användare förändringar över tid, inklusive anpassade mätvärden, och förändringar i mätvärden för en specifik sammanslagningsbegäran. Minnesanvändning, specialiserade arbetsbelastningstester och hälsostatus kan konverteras till enkla mätvärden som kan ses direkt i sammanslagningsförfrågningar tillsammans med andra inbyggda rapporter.
Stöd för flermoduls Maven-projekt för beroendeskanning
ULTIMAT, GULD
Med den här utgåvan stöder Maven-projekt med flera moduler GitLab-beroendeskanning. Tidigare, om en undermodul hade ett beroende av en annan undermodul på samma nivå, kunde den inte tillåta laddning från det centrala Maven-förvaret. Nu skapas ett Maven-projekt med flera moduler med två moduler och ett beroende mellan de två modulerna. Beroenden mellan syskonmoduler är nu tillgängliga i det lokala Maven-förrådet så att bygget kan fortsätta.
Som standard klonar GitLab Runner projektet till en unik undersökväg i $CI_BUILDS_DIR. Men för vissa projekt, som Golang, måste koden klonas in i en specifik katalog för att den ska kunna byggas.
I GitLab 11.10 introducerade vi variabeln GIT_CLONE_PATH, som låter dig specificera en specifik sökväg där GitLab Runner klonar projektet innan uppgiften utförs.
GitLab erbjuder flera sätt att skydda и begränsa området variabler i GitLab CI/CD. Men variabler kan fortfarande hamna i byggloggar, avsiktligt eller av misstag.
GitLab tar riskhantering och revision på allvar och fortsätter att lägga till efterlevnadsfunktioner. I GitLab 11.10 introducerade vi möjligheten att maskera vissa typer av variabler i jobbspårningsloggar, vilket lägger till en nivå av skydd mot att innehållet i dessa variabler av misstag inkluderas i loggarna. Och nu GitLab maskerar automatiskt många inbyggda tokenvariabler.
Distributionspaneler visar information om alla Kubernetes-distributioner.
I den här versionen har vi ändrat hur vi mappar genvägar till distributioner. Matcher finns nu tillgängliga kl app.example.com/app и app.example.com/env eller app. Detta undviker filtreringskonflikter och risken för felaktiga distributioner i samband med projektet.
Kubernetes-integrering med GitLab låter dig använda RBAC-funktionen med ett tjänstkonto och en dedikerad namnrymd för varje GitLab-projekt. Från och med den här versionen, för maximal effektivitet, kommer dessa resurser endast att skapas när de behövs för distribution.
När du distribuerar Kubernetes kommer GitLab CI att skapa dessa resurser före distribution.
Gruppnivåkluster stöder nu installation av GitLab Runner. Kubernetes-löpare på gruppnivå visas för underordnade projekt som grupplöpare märkta cluster и kubernetes.
Funktioner utplacerade med GitLab Serverlös, visar nu antalet mottagna samtal för en viss funktion. För att göra detta måste du installera Prometheus på klustret där Knative är installerat.
Som standard körs GitLab Runner git clean under processen att ladda upp kod när ett jobb utförs i GitLab CI/CD. Från och med GitLab 11.10 kan användare styra parametrarna som skickas till ett team git clean. Detta är användbart för team med dedikerade löpare, såväl som för team som samlar in projekt från stora monorepositories. Nu kan de kontrollera urladdningsprocessen innan de kör skript. Ny variabel GIT_CLEAN_FLAGS standardvärdet är -ffdx och accepterar alla möjliga kommandoparametrar [git clean](https://git-scm.com/docs/git-clean).
Säkra miljöer kan kräva ytterligare en extern auktoriseringsresurs för att komma åt projektet. Vi har lagt till stöd för en ytterligare nivå av åtkomstkontroll i 10.6 och fick många förfrågningar om att öppna den här funktionen i Core. Vi är glada över att kunna introducera extern auktorisering och ett extra lager av säkerhet för Core-instanser, eftersom denna funktion behövs av enskilda deltagare.
Utvecklarrollen kan skapa projekt i grupper sedan version 10.5, och nu är detta möjligt i Core. Att skapa projekt är en nyckelfunktion för produktivitet i GitLab, och genom att inkludera den här funktionen i Core är det nu lättare för till exempel medlemmar att göra något nytt.
Idag släppte vi GitLab Runner 11.10! GitLab Runner är ett projekt med öppen källkod som används för att köra CI/CD-jobb och skicka tillbaka resultaten till GitLab.
Den fullständiga listan över ändringar finns i GitLab Runner-ändringsloggen: ÄNDRING.
Rättelse av det returnerade project_id i blob search API i Elasticsearch
STARTA, PREMIUM, ULTIMAT
Vi fixade en bugg i Elasticsearch blob search API som felaktigt returnerade 0 för project_id. Det kommer att bli nödvändigt reindexera Elasticsearchför att få rätt värden project_id efter installation av den här versionen av GitLab.
Omnibus-förbättringar
CORE, STARTER, PREMIUM, ULTIMATE
Vi har gjort följande förbättringar av Omnibus i GitLab 11.10:
GitLab 11.10 inkluderar Nästan 5.9.0, öppen källkod Slack alternativ, vars senaste utgåva inkluderar en ny integrationskatalog för att enkelt migrera data från Hipchat och mycket mer. Denna version inkluderar säkerhetsuppdateringar, och vi rekommenderar att du uppdaterar.
GitLab Geo kommer att tillhandahålla hashad lagring i GitLab 12.0
GitLab Geo krävs hashat lager för att minska konkurrensen på sekundära noder. Detta noterades i gitlab-ce#40970.
I GitLab 11.5 vi har lagt till detta krav i Geo-dokumentationen: gitlab-ee#8053.
I GitLab 11.6sudo gitlab-rake gitlab:geo:check kontrollerar om hashad lagring är aktiverad och alla projekt migreras. Centimeter. gitlab-ee#8289. Om du använder Geo, kör den här kontrollen och migrera så snart som möjligt.
I GitLab 11.8 permanent inaktiverad varning gitlab-ee!8433 kommer att visas på sidan Admin område > Geo > Nodes, om ovanstående kontroller inte är tillåtna.
I GitLab 12.0 Geo kommer att använda hashade lagringskrav. Centimeter. gitlab-ee#8690.
Raderingsdatum: 22 2019 juni
Ubuntu 14.04-stöd
GitLab 11.10 kommer att vara den sista utgåvan med Ubuntu 14.04-stöd.
Canonical meddelade slutet på standardstödet för Ubuntu 14.04 april 2019. Vi rekommenderar användare att uppgradera till en LTS-version som stöds: Ubuntu 16.04 eller Ubuntu 18.04.
Raderingsdatum: 22 maj 2019 stad
Begränsning av det maximala antalet pipelines som skapas per inlämning
Tidigare skapade GitLab pipelines för HEAD varje gren i inlämningen. Detta är praktiskt för utvecklare som driver flera ändringar på en gång (till exempel till en funktionsgren och till en gren develop).
Men när du trycker på ett stort förråd med många aktiva grenar (till exempel flyttar, speglar eller grenar) behöver du inte skapa en pipeline för varje gren. Från och med GitLab 11.10 skapar vi maximalt 4 rörledningar vid sändning.
Raderingsdatum: 22 maj 2019 stad
Föråldrade GitLab Runner-kodsökvägar
Från och med Gitlab 11.9 använder GitLab Runner ny metod kloning/anrop av förvaret. För närvarande kommer GitLab Runner att använda den gamla metoden om den nya inte stöds. Se mer detaljer i denna uppgift.
I GitLab 11.0 ändrade vi utseendet på metric-serverkonfigurationen för GitLab Runner. metrics_server kommer att tas bort till förmån listen_address i GitLab 12.0. Se mer detaljer i denna uppgift.
Dessa sökvägar kommer inte att vara tillgängliga i GitLab 12.0. Som användare behöver du inte ändra något annat än att se till att din GitLab-instans kör version 11.9+ när du uppgraderar till GitLab Runner 12.0.
Raderingsdatum: 22 2019 juni
Utfasad parameter för ingångspunktsfunktion för GitLab Runner
I GitLab 12.0 kommer vi att byta till korrekt beteende som om funktionsinställningen var inaktiverad. Se mer detaljer i denna uppgift.
Raderingsdatum: 22 2019 juni
Utfasat stöd för Linux-distribution som når EOL för GitLab Runner
Vissa Linux-distributioner som GitLab Runner kan installeras på har tjänat sitt syfte.
I GitLab 12.0 kommer GitLab Runner inte längre att distribuera paket till sådana Linux-distributioner. En komplett lista över distributioner som inte längre stöds finns i vår dokumentation. Tack till Javier Ardo (Javier Jardon) per hans bidrag!
Raderingsdatum: 22 2019 juni
Ta bort gamla GitLab Runner Helper-kommandon
Som en del av våra ansträngningar att stödja Windows Docker exekutor var tvungen att överge några gamla kommandon som används för hjälparbild.
I GitLab 12.0 lanseras GitLab Runner med hjälp av nya kommandon. Detta gäller endast användare som åsidosätt hjälpbild. Se mer detaljer i denna uppgift.
Raderingsdatum: 22 2019 juni
Ta bort den äldre git clean-mekanismen från GitLab Runner
I GitLab Runner 11.10 vi ger möjligheten konfigurera hur Runner kör ett kommando git clean. Dessutom tar den nya rensningsstrategin bort användningen git reset och lägger kommandot git clean efter lossningssteget.
Eftersom denna beteendeförändring kan påverka vissa användare har vi förberett en parameter FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Om du ställer in värdet true, kommer det att återställa den äldre saneringsstrategin. Mer om att använda funktionsparametrar i GitLab Runner kan hittas i dokumentation.
I GitLab Runner 12.0 kommer vi att ta bort stödet för den äldre rensningsstrategin och möjligheten att återställa den med en funktionsparameter. Se mer detaljer i denna uppgift.
Raderingsdatum: 22 2019 juni
Systeminformationssektionen i adminpanelen
GitLab presenterar information om din GitLab-instans i admin/system_info, men denna information kanske inte är korrekt.
Fri: Obegränsade privata arkiv och obegränsat antal projektbidragsgivare. Slutna projekt har tillgång till nivåfunktioner Fri, y öppna projekt har tillgång till nivåfunktioner Gold.
Bronze: För team som behöver tillgång till avancerade arbetsflödesfunktioner.
Silver: För team som behöver mer robusta DevOps-funktioner, efterlevnad och snabbare support.
Gold: Lämplig för många CI/CD-jobb. Alla öppna projekt kan använda Gold-funktioner gratis, oavsett plan.