ProHoster > blogg > administration > GitLab 11.11: flera ansvarsområden för sammanslagningsförfrågningar och förbättringar för behållare
GitLab 11.11: flera ansvarsområden för sammanslagningsförfrågningar och förbättringar för behållare
Fler samarbetsalternativ och ytterligare aviseringar
På GitLab letar vi ständigt efter nya sätt att förbättra samarbetet över DevOps livscykel. Vi är glada att kunna meddela att vi stödjer den här versionen flera ansvariga personer för en sammanslagningsförfrågan! Den här funktionen är tillgänglig från GitLab Starter-nivå och förkroppsligar verkligen vårt motto: "Alla kan bidra". Vi vet att en enstaka sammanslagningsförfrågan kan ha många personer som arbetar med den för att se till att allt är i sin ordning, och nu har du möjlighet att tilldela flera sammanslagningsförfrågan ägare!
Minska kostnaderna med stöd för Docker-behållare på Windows och provisionering på instansnivå av Kubernetes-kluster
Vi älskar containrar! Behållare förbrukar mindre systemresurser jämfört med virtuella maskiner och förbättrar applikationsportabilitet. Sedan lanseringen av GitLab 11.11 stöder vi Windows Container Executor för GitLab Runner, så att du nu kan använda Docker-behållare på Windows och njuta av avancerad pipeline-orkestrering och hanteringsfunktioner.
GitLab Premium (endast självhanterade instanser) erbjuder nu cachingberoende proxy för Docker-bilder. Detta tillägg kommer att påskynda leveransen eftersom du nu kommer att ha en caching-proxy för ofta använda Docker-bilder.
Användare av självhanterade GitLab-instanser kan nu tillhandahålla Kubernetes-kluster på instansnivå, och alla team och projekt i instansen kommer att använda det för sina distributioner. Denna GitLab-integrering med Kubernetes kommer automatiskt att skapa projektspecifika resurser för ökad säkerhet.
Månadens mest värdefulla medarbetare (MVP) — Kia Mae Somabes (Kia Mei Somabes)
I den här utgåvan har vi lagt till möjligheten att ladda ner enskilda mappar från arkiv, snarare än allt innehåll. Nu kan du bara ladda ner några av de filer du behöver. Tack, Kia Mae Somabes!
I GitLab 11.11 lade vi till en ny löpare till GitLab Runner för att göra Docker-behållare användbara på Windows. Tidigare var du tvungen att använda ett skal för att orkestrera Docker-behållare på Windows, men nu kan du arbeta direkt med Docker-behållare på Windows, ungefär på samma sätt som på Linux. Microsoft-plattformsanvändare har nu fler alternativ för pipeline-orkestrering och hantering.
Den här uppdateringen inkluderar förbättrat PowerShell-stöd i GitLab CI/CD, såväl som nya supportbilder för olika versioner av Windows-behållare. Dina egna Windows-runners kan givetvis användas med GitLab.com, men de är ännu inte allmänt tillgängliga verktyg.
Cachingberoende proxy för behållarregistret
PREMIUM, ULTIMAT
Team använder ofta behållare i byggpipelines, och cachelagring av en proxy för ofta använda bilder och paket från uppströms är ett utmärkt sätt att snabba upp pipelines. Med en lokal kopia av de lager du behöver, tillgänglig via den nya cachingproxyn, kan du arbeta mer effektivt med vanliga bilder i din miljö.
För närvarande är containerproxy endast tillgänglig för självhanterade instanser på webbservern Puma (i experimentläge).
Flera personer ansvariga för sammanslagningsförfrågningar
STARTER, PREMIUM, ULTIMATE, BRONS, SILVER, GULD
Det är ganska vanligt att flera personer arbetar med en funktion i en delad gren och sammanfogar begäran, till exempel när front-end- och back-end-utvecklare arbetar nära tillsammans eller när utvecklare arbetar i par, som i Extreme Programming.
I GitLab 11.11 kan du tilldela flera personer att sammanfoga förfrågningar. Som med flera uppgiftsägare kan du använda listor, filter, meddelanden och API:er.
Kubernetes-klusterkonfiguration på instansnivå
CORE, STARTER, PREMIUM, ULTIMATE
Säkerhets- och provisioneringsmodellen i Kubernetes utvecklas för att tillåta ett stort antal klienter att betjänas genom ett delat kluster.
I GitLab 11.11 kan användare av självhanterade instanser nu tillhandahålla ett kluster på instansnivå, och alla team och projekt i instansen kommer att använda det för sina distributioner. Denna GitLab-integrering med Kubernetes kommer automatiskt att skapa projektspecifika resurser för ökad säkerhet.
Du kan nu ställa in automatiska aviseringar om implementeringshändelser i teamkanalen tack vare integration med chattar Slak и Mattermost, och ditt team kommer att vara medvetet om alla viktiga händelser.
Gästanvändare av dina projekt kan nu se releaser som publicerats på sidan Releases. De kommer att kunna ladda ner publicerade artefakter, men kommer inte att kunna ladda ner källkod eller se förvarsdetaljer som taggar eller commits.
Andra förbättringar i GitLab 11.11
Serialiserade commit-grafer för förbättrad prestanda
Många Git-operationer kräver att man korsar commit-grafen, som att beräkna sammanslagningsbasen eller lista grenar som innehåller en commit. Ju fler commits, desto långsammare är dessa operationer eftersom traversering kräver att varje objekt laddas från disk för att läsa dess pekare.
I GitLab 11.11 aktiverade vi den serialiserade commit-graffunktionen som introducerades i de senaste Git-släppen för att proaktivt beräkna och lagra denna information. Genomsökningar i stora förråd är nu mycket snabbare. Commit-grafen skapas automatiskt under nästa sophämtning av förvaret.
Läs om hur den serialiserade commit-grafen skapades i serie artiklar från en av författarna till detta inslag.
Ytterligare CI Runner-minuter: nu tillgänglig för gratisplaner
GRATIS, BRONS, SILVER, GULD
Förra månaden lade vi till möjligheten att köpa ytterligare CI Runner-minuter, men bara för betalda GitLab.com-planer. I den här utgåvan kan minuter också köpas i gratisplaner.
Beroende på typen och storleken på projektet kan arkivet för hela projektet ta lång tid att ladda ner och är inte alltid nödvändigt, särskilt när det gäller stora monorepositories. I GitLab 11.11 kan du ladda ner ett arkiv med innehållet i den aktuella katalogen, inklusive underkataloger, för att bara välja de mappar du behöver.
Att föreslå ändringar gör det lättare att samarbeta om sammanslagningsförfrågningar genom att eliminera behovet av copy-paste för att acceptera en föreslagen ändring. I GitLab 11.11 har vi gjort den här processen ännu enklare genom att tillåta diskussioner att lösas automatiskt när ett förslag tillämpas.
Aktivitetsfälten i sidofältet ska se likadana ut i vyerna Board och Task. Det är därför GitLab nu har en tidsspårare i sidofältet i frågebordet. Gå helt enkelt till din aktivitetstavla, klicka på en uppgift så öppnas en sidofält med en tidsräknare.
Vi har lagt till möjligheten att fråga Environments API för specifik miljöinformation för att veta vilken commit som distribueras till miljön just nu. Detta kommer att göra automatisering och rapportering enklare för miljöanvändare i GitLab.
Du kan nu kontrollera negativ likhet eller mönstermatchning (!= и !~) i filen .gitlab-ci.yml när man kontrollerar värdena för miljövariabler, så har kontrollen av rörledningarnas beteende blivit mer flexibel.
I GitLab 11.11 kan användare som har många manuella jobb i sina stadier nu slutföra alla sådana jobb i ett steg genom att klicka på en knapp "Spela alla" ("Kör alla") till höger om scennamnet i vyn Pipelines.
Miljövariabler används ofta för att skapa filer, särskilt för hemligheter som behöver skyddas och endast är tillgängliga i en specifik miljöpipeline. För att göra detta ställer du in variabelns innehåll till innehållet i filen och skapar en fil i jobbet som innehåller värdet. Med en ny miljövariabel som file detta kan göras i ett steg även utan modifiering .gitlab-ci.yml.
API-slutpunkt för sårbarhetsinformation
ULTIMAT, GULD
Du kan nu fråga GitLab API för alla sårbarheter som identifierats i ett projekt. Med detta API kan du skapa maskinläsbara listor över sårbarheter, filtrerade efter typ, konfidens och svårighetsgrad.
Fullständig dynamisk skanningskapacitet för DAST
ULTIMAT, GULD
I GitLab kan du dynamiskt testa applikationssäkerhet (Dynamic Application Security Testing, DAST) som en del av CI-pipeline. Från och med den här versionen kan du välja full dynamisk skanning istället för vanlig passiv skanning. Full dynamisk skanning skyddar mot fler sårbarheter.
Denna version av GitLab introducerar möjligheten att koppla ett Kubernetes-kluster till en hel grupp. Vi har också lagt till möjligheten att installera en Prometheus-instans per kluster för att göra det lättare att övervaka alla projekt i klustret.
Läs mer om att ignorera sårbarheter i säkerhetsöversikten
ULTIMAT, GULD
GitLab säkerhetsinstrumentpaneler tillåter administratörer att se ignorerade sårbarheter. För att effektivisera ditt arbetsflöde har vi lagt till möjligheten att visa ignoreringsdetaljer direkt i din säkerhetsinstrumentpanel.
Skapa anpassade statistikdiagram i din instrumentpanel
PREMIUM, ULTIMAT, SILVER, GULD
Skapa nya diagram med anpassade prestandastatistik direkt från instrumentpanelen i din mätinstrumentpanel. Användare kan nu skapa, uppdatera och ta bort statistikvisualiseringar i instrumentpanelen genom att klicka på "Lägg till statistik" ("Lägg till statistik") i det övre högra hörnet av instrumentpanelens verktygsfält.
Aviseringsproblem öppnas nu som GitLab Alert Bot
PREMIUM, ULTIMAT, SILVER, GULD
Nu kommer problem som öppnas från aviseringar att ha författaren inställd på GitLab Alert Bot, så att du omedelbart kan se att problemet skapades automatiskt från en viktig avisering.
Spara episka beskrivningar automatiskt till lokal lagring
ULTIMAT, GULD
Episka beskrivningar sparades inte i lokal lagring, så ändringar gick förlorade om du inte uttryckligen sparade dem när du ändrade den episka beskrivningen. GitLab 11.11 introducerade möjligheten att spara episka beskrivningar till lokal lagring. Det betyder att du nu enkelt kan återgå till att ändra din episka beskrivning om ett fel inträffar, du blir distraherad eller om du av misstag avslutar webbläsaren.
GitLab-speglingsstöd för Git LFS
STARTER, PREMIUM, ULTIMATE, BRONS, SILVER, GULD
Med hjälp av spegling kan du replikera Git-förråd från en plats till en annan. Detta gör det enkelt att lagra en replik av ett arkiv som finns någon annanstans på GitLab-servern. GitLab stöder nu spegling av repositories med Git LFS, så den här funktionen är tillgänglig även för repos med stora filer, såsom speltexturer eller vetenskaplig data.
Repository läs- och skrivbehörigheter för personliga åtkomsttokens
Många personliga åtkomsttokens har behörighet att ändra på nivån api, men full API-åtkomst kan ge för många rättigheter till vissa användare eller organisationer.
Tack vare indata från gemenskapen kan personliga åtkomsttokens nu bara ha läs- och skrivbehörigheter på projektförråd, snarare än djupare åtkomst på API-nivå till GitLab-känsliga områden som inställningar och medlemskap.
Med GraphQL API kan användare specificera exakt vilken data de behöver och få all data de behöver i några få frågor. Från och med den här utgåvan stöder GitLab att lägga till grundläggande gruppinformation till GraphQL API.
GitLab älskar Salesforce-utvecklare, och för att stödja denna gemenskap tillåter vi användare att logga in på GitLab med Salesforce.com-uppgifter. Instanser kan nu konfigurera GitLab som en Salesforce-ansluten app för att använda Salesforce.com för att logga in på GitLab med ett klick.
SAML SSO krävs nu för webbåtkomst
PREMIUM, ULTIMAT, SILVER, GULD
Vi utöka kravet på enkel inloggning (SSO). på gruppnivå, som introducerades i 11.8-versionen, med strikt validering av grupp- och projektresurser för att säkerställa att användare endast kan få åtkomst när de är inloggade med SAML. Detta är ett extra lager av åtkomstkontroll för organisationer som värdesätter säkerhet och använder GitLab.com via SAML SSO. Nu kan du göra SSO till ett krav, i vetskap om att användarna i din grupp använder SSO.
Filtrera efter nyligen skapade eller modifierade data för epics API
ULTIMAT, GULD
Tidigare var det inte lätt att fråga nyligen skapad eller ändrad data med hjälp av GitLab epics API. I release 11.11 lade vi till ytterligare filter created_after, created_before, updated_after и updated_beforeför att säkerställa överensstämmelse med uppgiftens API och snabbt hitta modifierade eller nyskapade epos.
Idag släppte vi GitLab Runner 11.11! 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.
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 en permanent inaktiverad varning kommer att visas på sidan Administratörsområde › Geo › Noder, om ovanstående kontroller inte är tillåtna. gitlab-ee!8433.
I GitLab 12.0 Geo kommer att använda hashade lagringskrav. Centimeter. gitlab-ee#8690.
Raderingsdatum: 22 2019 juni
GitLab Geo kommer att ta PG FDW till GitLab 12.0
Detta är nödvändigt för Geo Log Cursor eftersom det avsevärt förbättrar prestandan för vissa synkroniseringsoperationer. Prestandan för Geo-nodstatusfrågor förbättras också. Tidigare frågor hade mycket dålig prestanda på stora projekt. Se hur du ställer in detta Geo databas replikering. I GitLab 12.0 Geo kommer att kräva PG FDW. Centimeter. gitlab-ee#11006.
Raderingsdatum: 22 2019 juni
Vaktpostalternativ för felrapportering och loggning kommer att tas bort från användargränssnittet i GitLab 12.0
Dessa alternativ kommer att tas bort från användargränssnittet i GitLab 12.0 och kommer att vara tillgängliga i filen gitlab.yml. Dessutom kan du definiera en Sentry-miljö för att skilja mellan flera distributioner. Till exempel utveckling, iscensättning och produktion. Centimeter. gitlab-ce#49771.
Raderingsdatum: 22 2019 juni
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_serverkommer 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, Javier Ardo (Javier Jardon), för din bidrag!
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 gav en möjlighet konfigurera hur Runner kör ett kommando git clean. Dessutom tar den nya städstrategin 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 i denna uppgift.
När vi introducerade projektmallar på teamnivå i 11.6 gjorde vi av misstag denna Premium/Silver-funktion tillgänglig för alla planer.
Vi fixar denna bugg i versionen 11.11 och ger ytterligare 3 månader till alla användare och instanser under Silver/Premium-nivån.
Från och med den 22 augusti 2019 kommer gruppprojektmallar endast att finnas tillgängliga för Silver/Premium-planer och högre, enligt beskrivningen i dokumentationen.
Raderingsdatum: 22 2019 av augusti
Support för Windows batch-jobb har upphört
I GitLab 13.0 (22 juni 2020) planerar vi att ta bort stöd för Windows kommandorads batchjobb i GitLab Runner (t.ex. cmd.exe) till förmån för utökat stöd för Windows PowerShell. Mer detaljer i denna uppgift.
Vår vision för Enterprise DevOps kommer nu att överensstämma med Microsofts ståndpunkt att PowerShell är det bästa alternativet för att automatisera företagsapplikationer i Windows-miljöer. Om du vill fortsätta använda cmd.exe, dessa kommandon kan anropas från PowerShell, men vi kommer inte direkt att stödja Windows batchjobb på grund av flera inkonsekvenser som resulterar i höga underhålls- och utvecklingskostnader.
Raderingsdatum: 22 2019 September, den
Kräver Git 2.21.0 eller högre
Från och med GitLab 11.11 krävs Git 2.21.0 för att köras. Omnibus GitLab levereras redan med Git 2.21.0, men användare av originalinstallationer med tidigare versioner av Git måste uppgradera.
Raderingsdatum: 22 maj 2019 stad
Äldre Kubernetes tjänstemall
I GitLab 12.0 planerar vi att gå bort från Kubernetes-tjänstmallen på instansnivå till förmån för klusterkonfigurationen på instansnivå som introducerades i GitLab 11.11.
Alla självhanterade instanser som använder tjänstmallen kommer att migreras till ett kluster på instansnivå vid uppgradering till GitLab 12.0.
Raderingsdatum: 22 2019 juni
Välja bort etikettmatchning app på Kubernetes distributionspaneler
I GitLab 12.0 planerar vi att gå bort från matchning efter appetikett i Kubernetes-utbyggnadsväljaren. I GitLab 11.10 introducerade vi ny matchningsmekanism, som söker efter matchningar av app.example.com/app и app.example.com/envför att visa distributioner på panelen.
För att dessa distributioner ska visas i dina implementeringsinstrumentpaneler skickar du helt enkelt en ny implementering och GitLab kommer att tillämpa de nya etiketterna.
Raderingsdatum: 22 2019 juni
GitLab 12.0-paket kommer att signeras med en utökad signatur