GitLab 11.10

GitLab 11.10 med pipelines i kontrollpanelen, pipelines för sammanslagna resultat och förslag på flera rader i merge requests.

Användarvänlig information om pipelines prestanda i olika projekt

GitLab fortsätter att öka transparensen i DevOps livscykeln. I denna utgåva är kontrollpanel statusöversikten för pipelines tillagd.

Det är praktiskt, även om du studerar en pipelines i ett projekt, men särskilt användbart om det finns flera projekt, — vilket ofta är fallet om du använder mikrotjänster och vill köra en pipeline för testning och distribution av kod från olika projekts repository. Nu ser du omedelbart prestandan för pipelines i kontrollpanelen, oavsett var de körs.

Kör pipelines för sammanslagna resultat

Med tiden avviker käll- och målgrenar från varandra, och det kan uppstå situationer där de fungerar bra individuellt, men inte tillsammans. Nu kan du köra pipelines för sammanslagna resultat före sammanslagningen. Således kommer du snabbt att märka fel som endast skulle visa sig vid frekvent flytt av ändringar mellan grenarna, vilket innebär att du snabbt kan åtgärda pipelinesfel och använda GitLab Runner.

Ytterligare optimering av samarbetet

I GitLab 11.10 finns det ännu fler möjligheter för smidigt samarbete och förenklade arbetsflöden. I den föregående utgåvan införde vi förslag på merge requests där granskaren kunde föreslå en ändring av en rad i kommentaren till merge requesten, och denna kunde omedelbart committas direkt från kommentarsdiskussionen. Våra användare gillade det, och de bad om att utöka denna funktion. Nu kan du föreslå ändringar för flera rader, specificera vilka rader som ska tas bort och vilka som ska läggas till.

Tack för dina återkopplingar och förslag!

Och det är inte allt…

I denna utgåva finns så många fantastiska funktioner, såsom genvägar inom specifika områden, mer noggrant städning av containerregistret, komponerad Auto DevOps och möjligheten att köpa extra CI Runner-minuter. Nedan följer detaljer om varje av dem.

Månadens mest värdefulla anställd (MVP) — Takuya Noguti

Denna månad har Takuya Noguti blivit den mest värdefulla medarbetaren (Takuya Noguchi). Takuya har gjort ett bra jobb för GitLab: åtgärdat buggar, avslutat ofullständigheter i backend och frontend samt förbättrat användargränssnittet. Tack!

Huvudfunktioner i GitLab 11.10

Pipeline på kontrollpanelen

PREMIUM, ULTIMATE, SILVER, GOLD

På kontrollpanelen i GitLab visas information om projekt i hela GitLab-instansen. Du lägger till individuella projekt ett i taget och kan välja vilket projekt du är intresserad av.
I denna version har vi lagt till information om status för pipelines på kontrollpanelen. Nu kan utvecklare se pipeline-status i alla relevanta projekt – i ett och samma gränssnitt.

Pipelines för sammanslagna resultat

PREMIUM, ULTIMATE, SILVER, GOLD

Vanligtvis avviker den ursprungliga grenen från målgrenen över tid, om du inte kontinuerligt flyttar ändringar mellan dem. Som ett resultat är pipelines för både den ursprungliga och målgrenen "gröna" och det finns inga sammanslagningskonflikter, men vid sammanslagning uppstår ett fel på grund av inkompatibilitet i ändringarna.

När en pipeline för merge-begäran automatiskt skapar en ny länk som innehåller det sammanslagna resultatet av den ursprungliga och målgrenen kan vi starta en pipeline för denna länk och garantera att det samlade resultatet fungerar.

Om du använder pipelines för merge-begäran (i något sammanhang) och använder privata GitLab-runner version 11.8 eller äldre, måste de uppgraderas för att undvika problem. gitlab-ee#11122. Detta påverkar inte användare av offentliga GitLab-runner.

Förslag på ändringar i flera rader

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Vid samarbete kring merge-begäran märker du ofta problem och föreslår lösningar. Från och med GitLab 11.6 stöder vi förslag på ändringar för en rad.

I version 11.10 kan man i kommentarer till diffen av en merge-begäran föreslå ändringar för flera rader, och sedan kan alla användare med skrivbehörigheter till den ursprungliga grenen godkänna dem med ett enda klick. Denna nya funktion gör att man kan undvika copy-paste, som i tidigare versioner.

Taggar i ett område

PREMIUM, ULTIMATE, SILVER, GOLD

Med taggar i ett område kan team tillämpa ömsesidigt uteslutande taggar (i samma område) för uppgifter, merge-begäran eller epik i scenarier med anpassade fält eller anpassade arbetsflödesstatusar. De konfigureras med en speciell syntax med kolon i taggens rubrik.

Anta att du behöver ett anpassat fält i uppgifterna för att spåra operativsystemet för plattformen som dina funktioner riktar sig mot. Varje uppgift ska endast relatera till en plattform. Du kan skapa etiketter platform::iOS, platform::Android, platform::Linux och andra vid behov. Om du tillämpar en sådan etikett på en uppgift, tas automatiskt en annan befintlig etikett som börjar med platform::.

Anta att du har etiketter workflow::development, workflow::review och workflow::deployed, som betecknar arbetsflödesstatusen i ditt team. Om en uppgift redan har en etikett workflow::development, och utvecklaren vill flytta uppgiften till steget workflow::review, tillämpar han bara den nya etiketten, och den gamla (workflow::development) tas automatiskt bort. Detta beteende finns redan när du flyttar uppgifter mellan etikettlistor på en uppgiftsbräda som representerar ditt teams arbetsflöde. Nu kan teammedlemmar som inte arbetar med uppgiftsbrädan direkt ändra arbetsflödesstatusen inom själva uppgifterna.

Mer grundlig rengöring av containerregistret

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Vid normal användning av containerregistret med CI-pipelines skickar du flera separata ändringar till en etikett. På grund av hur Docker distribuerar implementeringen är standardbeteendet att spara alla förändringar i systemet, men detta tar mycket minne i slutändan. Om du använder parameter -m med registry-garbage-collect, kan du snabbt ta bort alla tidigare ändringar och få värdefullt utrymme.

Köp av ytterligare CI Runner-minuter

BRONZE, SILVER, GOLD

Användare med betalda planer på GitLab.com (Gold, Silver, Bronze) kan nu köpa ytterligare minuter för CI Runner. Tidigare var man tvungen att hålla sig inom den kvot som planen angav. Tack vare denna förbättring kan du förhandsköpa minuter utöver kvoten för att undvika driftstopp på grund av stopp i pipelines.

Just nu kostar 1000 minuter 8 dollar, och du kan köpa så många som du vill. Ytterligare minuter börjar användas när du har förbrukat hela din månatliga kvot, och resten av de ytterligare minuterna överförs till nästa månad. I en kommande version vill vi lägga till denna funktion även i de kostnadsfria planerna.

Komponerad Auto DevOps

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Med Auto DevOps går teamen över till moderna DevOps-praktiker nästan utan ansträngning. Från och med GitLab 11.10 tillhandahålls varje jobb i Auto DevOps som en oberoende mall. Användare kan använda funktionen includes i GitLab CI för att inkludera separata steg i Auto DevOps och använda sin anpassade fil gitlab-ci.yml. På så sätt kan man bara inkludera de nödvändiga jobben och dra nytta av uppdateringar i upstream.

Automatisk hantering av gruppmedlemmar på GitLab.com med SCIM

SILVER, GOLD

Tidigare var man tvungen att hantera medlemskap i grupper på GitLab.com manuellt. Nu kan man 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 många användare och centraliserade identitetsleverantörer. Nu kan du ha en enda sanningskälla, som Azure Active Directory, och användare kommer att skapas och tas bort automatiskt via identitetsleverantören snarare än manuellt.

Inloggning på GitLab.com via SAML-leverantör

SILVER, GOLD

Tidigare, vid användning av SAML SSO för grupper, var användaren tvungen att logga in med GitLab-uppgifter och identitetsleverantör. Nu kan man logga in direkt via SSO som en GitLab-användare kopplad till den konfigurerade gruppen.

Användarna behöver inte logga in två gånger, vilket gör det mer praktiskt för företag att använda SAML SSO för GitLab.com.

Andra förbättringar i GitLab 11.10

Schema för underordnade epics

ULTIMATE, GOLD

I den föregående utgåvan lade vi till underordnade epics (epics till epics) för att du lättare ska kunna hantera strukturen för uppgiftsfördelningen. Underordnade epics visas på sidan för den överordnade epics.

I denna utgåva visas schemat för underordnade epics på sidan för den överordnade epics, så att team kan se tidslinjen för underordnade epics och hantera tidsberoenden.

Popup-fönster för merge-förfrågningar

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

I denna utgåva presenterar vi informativa skärmar som visas när man hovrar över en länk till en merge-förfrågan. Tidigare visade vi bara titeln på merge-förfrågan, men nu även statusen för merge-förfrågan, statusen för CI-pipelinen och en kort URL.

I framtida versioner planerar vi att lägga till mer viktig information, som ansvariga personer och kontrollpunkter, och vi kommer även att införa popup-fönster för uppgifter.

Filtrering av merge-förfrågningar efter målgrenar

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Git-arbetsflöden för mjukvaruversionering eller distribution är ofta kopplade till flera långvariga grenar – för att införa korrigeringar i tidigare versioner (till exempel, stable-11-9) eller övergång från kvalitetskontroll till produktion (till exempel, integration), men det kan vara svårt att hitta merge-förfrågningar för dessa grenar bland många öppna merge-förfrågningar.

Listan över merge-förfrågningar för projekt och grupper kan nu filtreras efter den målgren som merge-förfrågan riktar sig mot, för att underlätta sökandet efter det som behövs.

Tack, Hiroyuki Sato (Hiroyuki Sato)!

Överföring och merge vid lyckad pipeline

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Om vi använder metoden för trunkbaserad utveckling bör vi undvika långlivade grenar till förmån för kortvariga grenar med en ägare. Små ändringar skickas ofta direkt till målgrenen, men vi riskerar att bryta bygget.

I denna version stöder GitLab nya överföringsalternativ i Git för att automatiskt öppna merge-förfrågningar, ange målgren och säkerställa merge vid lyckad pipeline från kommandoraden under överföring till grenen.

Förbättrad integration med externa övervakningspaneler

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

GitLab kan ansluta till flera Prometheus-servrar (i nivå med miljö, projekt och grupp (förväntas)), men att ha flera slutpunkter kan komplicera systemet eller inte stödas av standardövervakningspaneler. I denna version kan teamen använda ett API för Prometheus, vilket förenklar integrationen med tjänster som Grafana avsevärt.

Sortering av Wiki-sidor efter skapelsedatum

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

I projektets Wiki kan team dela dokumentation och annan viktig information tillsammans med källkoden och uppgifterna. I denna version kan listan över sidor i Wiki sorteras efter skapelsedatum och titel för att snabbt hitta nyligen skapad innehåll.

Övervakning av resurser som begärs av klustret

ULTIMATE, GOLD

GitLab hjälper till att övervaka Kubernetes-klustret för utvecklade och driftade applikationer. Från och med denna version kan du spåra begärda resurser för CPU och minne av klustret, för att upptäcka potentiella problem innan de blir allvarliga.

Visning av lastbalanserarens mätvärden på Grafanas övervakningspanel

CORE, STARTER, PREMIUM, ULTIMATE

Det är mycket viktigt att övervaka driftskompatibiliteten för GitLab-instansen. Tidigare gav vi standardövervakningspaneler via den inbyggda instansen av Grafana. Från och med denna version har vi lagt till ytterligare paneler för att övervaka NGINX load balancers.

SAST för Elixir

ULTIMATE, GOLD

Vi fortsätter att utöka språkstödet och fördjupa säkerhetskontrollerna. I denna version har vi inkluderat säkerhetskontroller för projekt på Elixir och projekt skapade på Phoenix-plattformen.

Flera förfrågningar i en diagram

PREMIUM, ULTIMATE, SILVER, GOLD

I GitLab kan man skapa diagram för att visualisera insamlade mätvärden. Ofta — till exempel om man vill se maximalt eller genomsnittligt värde av en mätning — vill man visa flera värden i ett diagram. Från och med denna version har ni nu den möjligheten.

DAST-resultat på gruppens säkerhetspanel

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Vi har lagt till resultat från dynamisk applikationssäkerhetstestning (Dynamic Application Security Testing, DAST) på säkerhetspanelen i gruppen förutom SAST, container-scanning och beroendesökning.

Tillägg av metadata i rapporten om container-scanning

ULTIMATE, GOLD

I denna version innehåller rapporten om container-scanning mer metadata — vi har lagt till berörd komponent (Clair-funktion) i den befintliga metadata: prioritet, identifikator (förknippad med mitre.org) och berörd nivå (till exempel debian:8).

Tillägg av rapporttyp för mätvärden i merge requests

PREMIUM, ULTIMATE, SILVER, GOLD

GitLab tillhandahåller redan flera typer av rapporter som kan inkluderas direkt i merge requests: från rapporter om kodkvalitet och modultestning vid granskning till SAST och DAST vid skyddsnivå.

Och även om detta är viktiga rapporter behövs grundläggande information som är lämplig för olika scenarier. I GitLab 11.10 tillhandahåller vi rapporter om mätvärden direkt i merge requesten, som förväntar sig ett enkelt nyckel-värde-par. Således kan användarna spåra förändringar över tid, inklusive användarmätvärden, och förändringar i mätvärden för en specifik merge request. Användning av minne, testning av specialiserade belastningar och driftsstatus kan omvandlas till enkla mätvärden som kan visas direkt i merge requests tillsammans med andra inbyggda rapporter.

Stöd för multimodulära Maven-projekt för att skanna beroenden

ULTIMATE, GOLD

I den här versionen stöder multimodulära Maven-projekt scanning av GitLab-beroenden. Tidigare, om en under-modul hade ett beroende av en annan modul på samma nivå, kunde den inte lösa nedladdningen från det centrala Maven-repositoriet. Nu skapas ett multimodulärt Maven-projekt med två moduler och ett beroende mellan de två modulerna. Beroendet mellan moduler på samma nivå är nu tillgängligt i det lokala Maven-repositoriet för att byggprocessen ska kunna fortsätta.

Användare kan ändra vägen för att klona i CI

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Som standard klonar GitLab Runner projektet till en unik inbäddad väg i $CI_BUILDS_DIR. Men för vissa projekt, till exempel Golang, måste koden klonas till en specifik katalog för att den ska kunna byggas.

I GitLab 11.10 införde vi variabeln GIT_CLONE_PATH, vilket gör det möjligt att ange en specifik väg dit GitLab Runner klonar projektet före uppgiftens körning.

Enkel maskering av skyddade variabler i loggar

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

GitLab erbjuder flera sätt att skydda och begränsa omfattningen av variabler i GitLab CI/CD. Men variabler kan fortfarande av misstag eller avsiktligt hamna i byggloggar.

GitLab tar riskhantering och revision på allvar och fortsätter att lägga till funktioner för att uppfylla kraven. I GitLab 11.10 introducerade vi möjligheten att maskera vissa typer av variabler i jobbslingornas loggar, vilket ger en extra skyddsnivå mot att innehållet i dessa variabler oavsiktligt dyker upp i loggarna. Dessutom maskerar GitLab nu automatiskt många inbyggda variabeltoken.

Aktivera och inaktivera Auto DevOps på gruppnivå

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Med Auto DevOps i GitLab.com-projektet kan du enkelt hantera moderna DevOps-arbetsflöden – från byggande till leverans.

Från och med GitLab 11.10 kan du aktivera och inaktivera Auto DevOps för alla projekt inom en grupp.

Förenklad och förbättrad licenssida

STARTER, PREMIUM, ULTIMATE

För att hantera licensnycklar var enklare och mer användarvänligt har vi ändrat designen på licenssidan i administrationspanelen och lyft fram de viktigaste delarna.

Uppdatering av etikettväljaren för Kubernetes-deployments

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

På deploymentspaneler visas information om alla Kubernetes-deployments.

I den här versionen har vi ändrat hur etiketter mappas till deployments. Nu är matchningar tillgängliga för app.example.com/app och app.example.com/env eller app. Detta kommer att undvika konflikter vid filtrering och risken för felaktiga distributioner relaterade till projektet.

Dessutom i GitLab version 12.0 kommer vi att ta bort app-taggen från Kubernetes distributionsväljaren, och matchning kommer bara att vara möjligt utifrån app.example.com/app och app.example.com/env.

Dynamisk skapelse av Kubernetes-resurser

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Kubernetes-integrationen i GitLab gör det möjligt att använda RBAC-funktioner med hjälp av ett tjänstekonto och ett dedikerat namnrum för varje GitLab-projekt. Från och med denna utgåva kommer dessa resurser att skapas endast när de behövs för distribution för att maximera effektiviteten.

Vid distribution av Kubernetes kommer GitLab CI att skapa dessa resurser innan distributionen.

Grupp-runners för kluster på gruppnivå

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Kluster på gruppnivå stöder nu installation av GitLab Runner. Kubernetes-runners på gruppnivå visas för underprojekten som grupp-runners som har märkts med etiketten cluster och kubernetes.

Anropsräknare för Knative-funktioner

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Funktioner som distribueras med GitLab Serverless, visar nu antalet mottagna anrop för respektive funktion. För detta krävs det att Prometheus installeras på klustret där Knative är installerat.

Kontroll av parametrar git clean för GitLab CI/CD-jobb

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Som standard kör GitLab Runner git clean i koden underladdningsprocessen vid körning av ett jobb i GitLab CI/CD. Från och med GitLab 11.10 kan användare kontrollera parametrarna som skickas till kommandot git clean. Detta är användbart för team med dedikerade runners och för team som bygger projekt från stora monorepositorier. Nu kan de hantera nedladdningsprocessen före körningen av skripten. Den nya variabeln GIT_CLEAN_FLAGS har som standardvärde -ffdx och accepterar alla möjliga parametrar till kommandot [git clean](https://git-scm.com/docs/git-clean).

Extern autentisering i Core

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Säkra miljöer kan kräva en ytterligare extern resurstillstånd för åtkomst till projektet. Vi har lagt till stöd för en extra nivå av åtkomstkontroll i 10.6 och har fått många förfrågningar om att öppna denna funktionalitet i Core. Vi är glada att kunna presentera extern autentisering och en extra säkerhetsnivå för Core-exemplar, eftersom denna funktion behövs av vissa deltagare.

Möjlighet att skapa projekt i grupper i Core

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Utvecklarrollen kan skapa projekt i grupper sedan version 10.5, och nu är detta även möjligt i Core. Att skapa projekt är en nyckelfunktion för produktivt arbete i GitLab, och tack vare att denna funktion har lagts till i Core är det nu enklare för deltagare att engagera sig i nya uppgifter.

GitLab Runner 11.10

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Idag har vi släppt GitLab Runner 11.10! GitLab Runner är ett open source-projekt som används för att köra CI/CD-jobb och skicka resultaten tillbaka till GitLab.

De mest intressanta förändringarna:

• Parameter för att ange kloningsväg.
• Förbättrat stöd för git clean.
• Möjlighet att stänga av felsökningsspårning.
• Användning av fördröjd variabelutvidgning för att kontrollera fel i Windows Cmd.
• Korrigering av färgutgång i Windows.

En fullständig lista över ändringar finns i changelog för GitLab Runner: CHANGELOG.

Korrigering av det återvändande project_id i API:et för blob-sökning i Elasticsearch

STARTER, PREMIUM, ULTIMATE

Vi har åtgärdat en bugg i blob-söknings-API:et i Elasticsearch som felaktigt returnerade 0 för project_id. Det kommer att behövas omindexera Elasticsearch, för att få korrekta värden project_id efter att ha installerat denna version av GitLab.

Förbättringar av Omnibus

CORE, STARTER, PREMIUM, ULTIMATE

Vi har gjort följande förbättringar i Omnibus i GitLab 11.10:

• GitLab 11.10 inkluderar Mattermost 5.9.0, ett öppet källkods-alternativ till Slack, som i den senaste versionen innehåller en ny integrationskatalog för enkel överföring av data från Hipchat och mycket mer. Denna version inkluderar säkerhetsuppdateringar, och vi rekommenderar att du uppdaterar.
• Vi integrerat Grafana med Omnibus, och nu har det blivit mycket enkelt att börja övervaka din GitLab-instans.
• Vi har lagt till stöd för att ta bort gamla containerbilder från Docker-registret.
• Vi har uppdaterat ca-certifikat till 2019-01-23.

Prestandaförbättringar

CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD

Vi fortsätter att förbättra prestandan i GitLab med varje utgåva för GitLab-instanser av alla storlekar. Några förbättringar i GitLab 11.10:

• Autofyllning av användare sker nu snabbare.
• SQL-frågor för att hämta projektuppgifter vid sökning har optimerats.
• Elasticsearch-sökresultat inkluderar längre Gitaly.
• GraphQL-frågor har nu en komplexitetsbegränsning.
• Instrumentering av diffar har stängts av för att öka prestandan vid merge-förfrågningar när Prometheus är aktiverat.
• Förbättrad prestanda vid import av pull-förfrågningar från GitHub.
• Sökning av commit i cache baserat på referensnamn.
• Förbättrad prestanda vid diffning av merge-förfrågningar — nu cachas blob diff-filer.

Förbättringar av GitLab-diagram

CORE, STARTER, PREMIUM, ULTIMATE

Vi har gjort följande förbättringar av GitLab-diagram:

• Tillagt stöd för Elasticsearch.

Utdaterade funktioner

GitLab Geo kommer att säkerställa hashad lagring i GitLab 12.0

GitLab Geo kräver hashad lagring för att mildra konkurrensen på sekundära noder. Detta noterades i gitlab-ce#40970.

I GitLab 11.5 har vi lagt till detta krav i Geo-dokumentationen: gitlab-ee#8053.

I GitLab 11.6 sudo gitlab-rake gitlab:geo:check kontrollerar om hashad lagring är aktiverad och att alla projekt migreras. Se. gitlab-ee#8289. Om du använder Geo, vänligen kör denna kontroll och migrera så snart som möjligt.

I GitLab 11.8 konstant avaktiverat varningsmeddelande gitlab-ee!8433 kommer att visas på sidan Admin-område › Geo › Noder, om ovanstående kontroller inte tillåts.

I GitLab 12.0 Geo kommer att använda krav för hashad lagring. Se. gitlab-ee#8690.

Datum för borttagning: 22 juni 2019.

Stöd för Ubuntu 14.04

GitLab 11.10 blir den sista versionen med stöd för Ubuntu 14.04.

Canonical har meddelat att standardstödet för Ubuntu 14.04 upphörde den april 2019. Vi rekommenderar användare att uppgradera till en stödd LTS-version: Ubuntu 16.04 eller Ubuntu 18.04.

Datum för borttagning: 22 maj 2019.

Begränsning av det maximala antalet pipeliner som kan skapas av en enda push

Tidigare skapade GitLab pipeliner för HEAD varje gren i en push. Detta är praktiskt för utvecklare som pushar flera ändringar samtidigt (till exempel till en funktionsgren och till grenen develop).

Men vid push av ett stort förråd, med många aktiva grenar (till exempel för flytt, spegling eller förgrening), behövs det inte att skapa en pipeline för varje gren. Från och med GitLab 11.10 skapar vi max 4 pipeliner vid push.

Datum för borttagning: 22 maj 2019.

Föråldrade legacy-vägar i GitLab Runner

Från och med GitLab 11.9 använder GitLab Runner ny metod kloning/anrop av förrådet. För närvarande kommer GitLab Runner att använda den gamla metoden om den nya inte stöds. Läs mer i denna uppgift.

I GitLab 11.0 ändrade vi utseendet på konfigurationen av metrics-server för GitLab Runner. metrics_server kommer att tas bort till förmån för listen_address i GitLab 12.0. Mer information finns i denna uppgift.

I version 11.3 började GitLab Runner stödja flera cache-leverantörer; vilket ledde till nya inställningar för specifik S3-konfiguration. I dokumentationen, en tabel med ändringar och instruktioner för att övergå till den nya konfigurationen. Läs mer i denna uppgift.

Dessa vägar kommer att bli otillgängliga i GitLab 12.0. Som användare behöver du inte ändra något, bara försäkra dig om att GitLab-instansen fungerar med version 11.9+ vid uppgradering till GitLab Runner 12.0.

Datum för borttagning: 22 juni 2019.

Föråldrad parameter för funktionens ingångspunkt för GitLab Runner

I 11.4 introducerades en parameter för GitLab Runner FF_K8S_USE_ENTRYPOINT_OVER_COMMAND för att åtgärda problem som #2338 och #3536.

I GitLab 12.0 kommer vi att återgå till rätt beteende, som om funktionsparametern var inaktiverad. Mer information finns i denna uppgift.

Datum för borttagning: 22 juni 2019.

Föråldrat stöd för Linux-distributioner som nått EOL för GitLab Runner

Vissa Linux-distributioner där GitLab Runner kan installeras har nått slutet av sitt liv.

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 kan hittas i vår dokumentationen. Tack till Javier Jardón för hansJavier Jardón) för sin insats!

Datum för borttagning: 22 juni 2019.

Som en del av insatserna för att stödja

Windows Docker-executorn måste vi ta bort vissa gamla kommandon som används för helper image I GitLab 12.0 startas GitLab Runner med nya kommandon. Detta berör endast användare som åsidosätter.

I GitLab 12.0 startar GitLab Runner med nya kommandon. Detta gäller endast användare som överskrider hjälpbilderUtvecklare kan ta bort Git-taggar i GitLab 11.10 denna uppgift.

Datum för borttagning: 22 juni 2019.

Borttagning av det tidigare git clean-mekanismen från GitLab Runner

I GitLab Runner 11.10 erbjuder vi möjligheten att konfigurera hur Runner kör kommandot git clean. Dessutom tar den nya rensningsstrategin bort användningen av git reset och placerar kommandot git clean efter steg för export.

Eftersom denna förändring i beteende kan påverka vissa användare har vi förberett en parameter FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Om värdet sätts trueåterställer det den gamla städstrategin. Mer information om användningen av funktionsparametrar i GitLab Runner finns i dokumentationen.

I GitLab Runner 12.0 kommer vi att ta bort stödet för legacy-rensningsstrategin och möjligheten att återställa den med funktionsparametern. Läs mer i denna uppgift.

Datum för borttagning: 22 juni 2019.

Systeminformation avsnittet i administratörspanelen

GitLab visar information om din GitLab-instans i admin/system_info, men denna information kan vara felaktig.

Vi vi kommer att ta bort detta avsnitt i administratörspanelen i GitLab 12.0 och rekommenderar att använda andra övervakningsmöjligheter..

Datum för borttagning: 22 juni 2019.

Ändringslogg

Sök efter alla dessa ändringar i ändringsloggen:

• GitLab Community Edition
• GitLab Enterprise Edition
• GitLab Runner

Installation

Om du ställer in en ny installation av GitLab, besök GitLabs nedladdningssida.

Uppdatering

Kolla in uppdateringssidan.

GitLab prenumerationsplaner

GitLab finns i två alternativ: självhostad och molnbaserad SaaS.

Självhostad: lokalt eller på den föredragna molnplattformen.

• Core: för små team, personliga projekt eller en provversion av GitLab under obegränsad tid.
• Starter: för team som arbetar på en och samma plats med flera projekt som behöver professionellt stöd.
• Premium: för distribuerade team som behöver avancerade funktioner, hög tillgänglighet och support dygnet runt.
• Ultimate: för företag som kräver en robust strategi och implementering med förbättrad säkerhet och efterlevnad.

Molnbaserad SaaS — GitLab.com: värd, hanteras och administreras av GitLab med gratis och betalda prenumerationer för individuella utvecklare och team.

• Gratis: obegränsade privata repository och obegränsat antal projektmedlemmar. Stängda projekt har tillgång till funktioner på Gratis, medan öppna projekt har tillgång till funktioner på Guld.
• Brons: för team som behöver tillgång till avancerade arbetsflödesfunktioner.
• Silver: för team som behöver mer pålitliga DevOps-funktioner, efterlevnad och snabb support.
• Guld: passar för många CI/CD-jobb. Alla öppna projekt kan gratis använda Guld-funktioner oavsett plan.

Källa: habr.com