GitLab 11.10

GitLab 11.10

GitLab 11.10 med pipelines på kontrolpanelet, pipelines til samlede resultater og forslag til flere linjer i merge-anmodninger.

Praktiske oplysninger om pipelines' drift på tværs af projekter

GitLab fortsætter med at øge gennemsigtigheden i DevOps-livscyklussen. I denne udgivelse er kontrolpanelet der tilføjet en oversigt over pipeline-status.

Det er praktisk, selvom du kun undersøger en pipelines for et enkelt projekt, men især nyttigt, hvis der er flere projekter, – hvilket ofte er tilfældet, hvis du bruger mikrotjenester og ønsker at køre en pipeline til test og levering af kode fra forskellige repositories af projekter. Nu kan du straks se driftigheden af pipelines på kontrolpanelet, uanset hvor de bliver kørt.

Kørsel af pipelines for samlede resultater

Over tid divergerer kilde- og målværger og kan der opstå en situation, hvor de hver for sig fungerer, men ikke sammen. Nu kan man køre pipelines for samlede resultater før merge.Så du vil hurtigt opdage fejl, der kun viser sig ved hyppig flytning af ændringer mellem værger, og dermed hurtigere rette fejlene i pipelines og bruge GitLab Runner.

Yderligere optimering af samarbejdet

I GitLab 11.10 er der endnu flere muligheder for bekvemt samarbejde og forenklede arbejdsprocesser. I den forrige udgivelse introducerede vi forslag til merge-anmodninger, hvor anmeldere kunne foreslå en ændring af én linje i kommentaren til merge-anmodningen, og det kunne straks committes direkte fra kommentartråden. Vores brugere har værdsat dette, og de har bedt om at udvide denne funktion. Nu kan du foreslå ændringer til flere linjer, ved at angive, hvilke linjer der skal fjernes, og hvilke der skal tilføjes.

Tak for jeres feedback og forslag!

Og det er ikke alt…

I denne udgivelse er der så mange fantastiske funktioner, såsom genveje inden for bestemte områder, en mere grundig rensning af containerregistret, samlet Auto DevOps og muligheden for at købe ekstra CI Runner-minutter. Nedenfor er detaljerne om hver af dem.

Månedens mest værdifulde medarbejder () i denne måned er Marcel Amirault () – Takuya Noguchi

Denne måned er månedens mest værdifulde medarbejder Takuya Noguchi (Takuya Noguchi). Takuya har ydet en fremragende indsats for GitLab: jeg har rettet fejl, afsluttet ufuldkommenheder i backend og frontend og forbedret brugergrænsefladen. Tak!

Hovedfunktioner i GitLab 11.10

Pipeline på kontrolpanelet

PREMIUM, ULTIMATE, SILVER, GOLD

Kontrolpanelet i GitLab viser oplysninger om projekter på hele GitLab-instansen. Du kan tilføje individuelle projekter én ad gangen og vælge, hvilket projekt der interesserer dig.
I denne udgave har vi tilføjet oplysninger om pipeline-statusser til kontrolpanelet. Nu kan udviklerne se pipeline-funktionalitet i alle relevante projekter — fra ét interface.

GitLab 11.10

Pipeline til samlede resultater

PREMIUM, ULTIMATE, SILVER, GOLD

Normalt afviger den oprindelige gren fra målet over tid, hvis du ikke konstant flytter ændringer mellem dem. Som et resultat er pipelinerne for både den oprindelige og målet 'grønne', og der opstår ingen merge-konflikter, men ved sammensmeltning mislykkes det på grund af inkompatibilitet af ændringer.

Når en pipeline for merge-anmodninger automatisk opretter et nyt link, der indeholder det samlede resultat fra sammensmeltningen af den oprindelige og målet gren, kan vi køre pipelinen via dette link og sikre, at det samlede resultat fungerer.

Hvis du bruger pipeliner for merge-anmodninger (i hvilken som helst kapacitet) og benytter private GitLab-løbere version 11.8 eller ældre, skal de opdateres for at undgå problemer. gitlab-ee#11122. Dette påvirker ikke brugere af offentlige GitLab-løbere.

GitLab 11.10

Forslag til ændringer i flere linjer

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

Når du arbejder sammen om merge-anmodninger, bemærker du ofte problemer og foreslår løsninger. Fra version 11.6 af GitLab understøtter vi forslag til ændringer for en enkelt linje.

I version 11.10 kan der foreslås ændringer for flere linjer i kommentarerne til diffen for merge-anmodningen, og enhver bruger med skrivebemyndigelse til den oprindelige gren kan godkende dem med ét klik. Takket være den nye funktion kan man undgå kopiering og indsættelse som i tidligere versioner.

GitLab 11.10

Labels i et område

PREMIUM, ULTIMATE, SILVER, GOLD

Med labels i ét område kan teamene anvende gensidigt eksklusive labels (i det samme område) til en opgave, merge-anmodning eller epic i scenarier med tilpassede felter eller tilpassede workflow-statusser. De konfigureres med en særlig syntaks med kolon i labelens overskrift.

Lad os antage, at du har brug for et brugerdefineret felt i opgaver for at spore det operativsystem, som dine funktioner er målrettet imod. Hver opgave skal kun relateres til én platform. Du kan oprette etiketter platform::iOS, platform::Android, platform::Linux og andre efter behov. Hvis du anvender en sådan etiket på en opgave, vil en anden eksisterende etiket, der starter med platform::.

Lad os antage, at du har etiketter workflow::development, workflow::review og workflow::deployed, der angiver tilstanden af arbejdsflowet i dit team. Hvis en opgave allerede har en etiket workflow::development, og udvikleren ønsker at flytte opgaven til fasen workflow::review, anvender han blot en ny etiket, og den gamle (workflow::development) fjernes automatisk. Denne adfærd findes allerede, når du flytter opgaver mellem etiketlisterne på opgavelisten, der repræsenterer dit teams arbejdsflow. Nu kan teammedlemmer, der ikke arbejder med opgavelisten direkte, ændre arbejdsflowet i selve opgaverne.

GitLab 11.10

Mere grundig oprydning af containerregisteret

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

Ved almindelig brug af containerregisteret med CI-pipelines sender du flere enkelte ændringer til én tag. På grund af implementeringen af Docker-distributionen er standardadfærden at gemme alle ændringer i systemet, men dette optager i sidste ende meget plads. Ved at bruge parameteren -m med registry-garbage-collect, kan du hurtigt fjerne alle tidligere ændringer og frigøre værdifuld plads.

GitLab 11.10

Køb af ekstra minutter til CI Runner

BRONZE, SILVER, GOLD

Brugere med betalte planer på GitLab.com (Gold, Silver, Bronze) kan nu købe ekstra minutter til CI Runner. Tidligere måtte man holde sig inden for kvoten fastsat af planen. Takket være denne forbedring kan man på forhånd købe minutter ud over kvoten for at undgå nedbrud i arbejdet på grund af stop i pipelines.

Lige nu koster 1000 minutter 8 dollars, og man kan købe så mange som ønskes. Ekstra minutter begynder at blive brugt, når du har brugt hele din månedlige kvote, og eventuelle resterende ekstra minutter overføres til næste måned. I den kommende udgave vi ønsker at tilføje denne funktion til de gratis planer.

GitLab 11.10

Sammensat Auto DevOps

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

Med Auto DevOps kan teams næsten ubesværet overgå til moderne DevOps-praksisser. Fra GitLab 11.10 leveres hver job i Auto DevOps som en selvstændig skabelon. Brugere kan bruge includes-funktionen i GitLab CI til at inkludere separate faser af Auto DevOps og samtidig bruge sin egen tilpassede fil gitlab-ci.yml. På den måde kan du kun inkludere de nødvendige jobs og drage fordel af opdateringerne i upstream.

GitLab 11.10

Automatisk styring af medlemskab i grupper på GitLab.com ved hjælp af SCIM

SILVER, GOLD

Tidligere måtte medlemskab i grupper på GitLab.com administreres manuelt. Nu kan man bruge SAML SSO og styre medlemskab ved hjælp af SCIM for at oprette, slette og opdatere brugere på GitLab.com.

Dette er især nyttigt for virksomheder med mange brugere og centraliserede identitetsudbydere. Nu kan du have en enkelt sandhedskilde, som f.eks. Azure Active Directory, og brugere oprettes og slettes automatisk gennem identitetsudbyderen i stedet for manuelt.

GitLab 11.10

Log ind på GitLab.com via en SAML-udbyder

SILVER, GOLD

Tidligere, når man brugte SAML SSO til grupper, skulle brugeren logge ind med GitLab-legitimationsoplysninger og identitetsudbyderen. Nu kan man logge ind direkte via SSO som en GitLab-bruger tilknyttet den konfigurerede gruppe.

Brugerne skal ikke logge ind to gange, så det er lettere for virksomheder at bruge SAML SSO til GitLab.com.

GitLab 11.10

Andre forbedringer i GitLab 11.10

Schema for underliggende epics

ULTIMATE, GOLD

I den tidligere udgave tilføjede vi underliggende epics (epics af epics) for at gøre det lettere at styre strukturen af opgavefordelingen. Underliggende epics vises på siden for den overordnede epic.

I denne udgave vises schemaet for underliggende epics på siden for den overordnede epic, så teams kan se tidslinjen for de underliggende epics og håndtere tidsafhængigheder.

GitLab 11.10

Pop-up skærme for merge requests

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

I denne udgave introducerer vi informative skærme, der vises, når musen holdes over linket til merge request. Tidligere viste vi kun titlen på merge request, men nu også status for merge request, status for CI-pipeline og en kort URL.

I fremtidige udgaver planlægger vi at tilføje flere vigtige oplysninger, som f.eks. ansvarlige personer og kontrolpunkter, og vi vil også introducere pop-up skærme for opgaver.

GitLab 11.10

Filtrering af merge requests efter målbrancher

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

Git-arbejdsprocesser til udgivelse eller levering af software er ofte forbundet med flere langsigtede grene — til at lave rettelser i tidligere versioner (f.eks. stable-11-9) eller overgangen fra kvalitetssikring til produktion (f.eks. integration), men det kan være svært at finde pull-requests for disse grene blandt de mange åbne pull-requests.

Listen over pull-requests for projekter og grupper kan nu filtreres efter den målrettede gren for pull-request, så det er lettere at finde den ønskede.

Tak, Hiroyuki Sato (Hiroyuki Sato)!

GitLab 11.10

Send og merge ved succesfuld pipeline

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

Hvis vi bruger trunk-baseret udviklingsmetode, skal vi undgå langsigtede grene til fordel for små midlertidige grene med én ejer. Små ændringer sendes ofte direkte til den målrettede gren, men vi risikerer at bryde bygningen.

I denne version understøtter GitLab nye uploadindstillinger i Git, så der automatisk kan åbnes pull-requests, angives målgren og sikres merge ved succesfuld pipeline fra kommandolinjen under upload til grenen.

GitLab 11.10

Forbedret integration med eksterne overvågningspaneler

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

GitLab kan tilgå flere Prometheus-servere (på miljø-, projekt- og gruppe-niveau (forventes)), men at have flere slutpunkter kan komplicere systemet eller ikke understøttes af standardovervågningspaneler. I denne version kan teams bruge én Prometheus API, hvilket væsentligt forenkler integrationen med tjenester som Grafana.

Sortering af Wiki-sider efter oprettelsesdato

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

I projektets Wiki kan teams dele dokumentation og anden vigtig information sammen med kildekode og opgaver. I denne version kan listen over sider i Wiki sorteres efter oprettelsesdato og titel for hurtigt at finde nyligt oprettet indhold.

GitLab 11.10

Overvågning af ressourcer, der anmodes om af klyngen

ULTIMATE, GOLD

GitLab hjælper med at overvåge Kubernetes-klyngen for udviklede og operationelle applikationer. Fra denne version kan du spore de ressourcer for processor og hukommelse, der anmodes om af klyngen, for at opdage potentielle problemer, før de bliver til problemer.

GitLab 11.10

Visning af belastningsbalanceringsmetrikker på Grafana-overvågningspanelet

CORE, STARTER, PREMIUM, ULTIMATE

Det er meget vigtigt at overvåge driften af GitLab-installationen. Tidligere tilbød vi standard overvågningspaneler via den indbyggede Grafana-installation. Fra denne version har vi inkluderet ekstra paneler til overvågning af NGINX load balancere.

SAST til Elixir

ULTIMATE, GOLD

Vi fortsætter med at udvide sprogunderstøttelsen og forstærke sikkerhedstjek. I denne version har vi tilføjet sikkerhedstjek for projekter skrevet i Elixir og projekter bygget på Phoenix-platformen.

Flere forespørgsler i et diagram

PREMIUM, ULTIMATE, SILVER, GOLD

I GitLab kan du oprette diagrammer for at visualisere de indsamlede metrikker. Ofte - for eksempel når du vil se maksimum- eller gennemsnitsværdien af en metrisk værdi - ønsker man at vise flere værdier i et enkelt diagram. Fra denne version har du denne mulighed.

DAST-resultater på gruppe sikkerhedspanel

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

Vi har tilføjet resultater fra Dynamic Application Security Testing (DAST) til sikkerhedspanelet på gruppe niveau, udover SAST, container scanning og afhængighedsscanning.

Tilføjelse af metadata til container-scanningsrapporten

ULTIMATE, GOLD

I denne version indeholder rapporten fra container-scanningen flere metadata - vi har tilføjet berørt komponent (Clair-funktion) til de eksisterende metadata: prioritet, identifikator (med reference til mitre.org) og berørt niveau (f.eks. debian:8).

Tilføjelse af rapporttype for metrikker i merge-anmodninger

PREMIUM, ULTIMATE, SILVER, GOLD

GitLab tilbyder allerede flere typer rapporter, som kan inkluderes direkte i merge-anmodninger: fra rapporter om kodekvalitet og modultests i anmeldelsesfasen til SAST og DAST i beskyttelsesfasen.

Og selvom disse rapporter er vigtige, er grundlæggende oplysninger, der er relevante for forskellige scenarier, også nødvendige. I GitLab 11.10 giver vi rapporter om metrikker direkte i merge-anmodningen, der forventer et simpelt nøgle-værdi-par. Dette gør det muligt for brugerne at spore ændringer over tid, inklusive brugerdefinerede metrikker, og ændringer af metrikker for en bestemt merge-anmodning. Hukommelsesforbrug, test af specialiserede belastninger og tilgængelighedstatus kan konverteres til simple metrikker, der kan ses direkte i merge-anmodningerne sammen med andre indbyggede rapporter.

Understøttelse af multimodulære Maven-projekter til scanning af afhængigheder

ULTIMATE, GOLD

I denne udgave understøtter multimodulære Maven-projekter scanning af afhængigheder fra GitLab. Tidligere kunne et underprojekt, der havde en afhængighed fra et andet underprojekt på samme niveau, ikke løse download fra det centrale Maven-repositorium. Nu oprettes et multimodulært Maven-projekt med to moduler og en afhængighed imellem de to moduler. Afhængigheden mellem moduler på samme niveau er nu tilgængelig i det lokale Maven-repositorium, så bygningen kan fortsætte.

Brugere kan ændre stien for kloning i CI

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

Som standard kloner GitLab Runner projektet i en unik indlejret sti i $CI_BUILDS_DIR. Men for nogle projekter, som Golang, skal koden klones til en specifik mappe for at kunne bygges.

I GitLab 11.10 introducerede vi variablen GIT_CLONE_PATH, som giver mulighed for at angive en specifik sti, hvor GitLab Runner kloner projektet, før opgaven udføres.

Simpel maskering af beskyttede variabler i logs

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

GitLab tilbyder flere måder til at beskytte og begribe omfanget af variabler i GitLab CI/CD. Men variabler kan stadig ved et uheld eller med vilje ende i byggeprotokoller.

GitLab tager risikostyring og revision alvorligt og fortsætter med at tilføje funktioner for at overholde krav. I GitLab 11.10 introducerede vi muligheden for at maskere visse typer variabler i jobtrace logs, ved at tilføje et beskyttelsesniveau mod utilsigtet eksponering af indholdet af disse variabler i logs. Derudover maskerer GitLab nu automatiske maskeringer mange indbyggede variabeltoken.

Aktivering og deaktivering af Auto DevOps på gruppe niveau

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

Med Auto DevOps i et GitLab.com-projekt kan man nemt implementere moderne DevOps-arbejdsprocesser — fra bygning til levering.

Fra GitLab 11.10 kan du aktivere og deaktivere Auto DevOps for alle projekter i en gruppe.

Forenklet og forbedret licensside

STARTER, PREMIUM, ULTIMATE

For at gøre administrationen af licensnøgler lettere og simpler har vi ændret designet på licenssiden i administrationspanelet og fremhævet de vigtigste elementer.

GitLab 11.10

Opdatering af etiketsvælger til Kubernetes-udrulninger

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

På udrulningspanelerne vises oplysninger om alle Kubernetes-udrulninger.

I denne udgave har vi ændret måden, etiketter matches med udrulninger. Nu er matchning tilgængeligt. app.example.com/app og app.example.com/env eller app. Dette vil undgå konflikter under filtrering og risiko for forkerte deployment relateret til projektet.

Desuden i GitLab version 12.0 fjerner vi app etiketten fra Kubernetes deployment vælgeren, og match vil kun være muligt på app.example.com/app og app.example.com/env.

Dynamisk oprettelse af Kubernetes ressourcer

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

Integration af Kubernetes i GitLab muliggør brugen af RBAC-funktionen med en servicekonto og dedikeret navnerum for hvert GitLab projekt. Fra denne udgave vil disse ressourcer blive oprettet kun når de er nødvendige for deployment for maksimal effektivitet.

Under Kubernetes deployment vil GitLab CI oprette disse ressourcer før deployment.

Gruppe runners for grupper på niveauet

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

Grupper på niveauet understøtter nu installation af GitLab Runner. Kubernetes runners på niveauet vises for underprojekter som gruppe runners, markeret med etiketter cluster og kubernetes.

Opkaldstæller for Knative funktioner

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

Funktioner der er distribueret med GitLab Serverless, viser nu antallet af modtagne opkald for en enkelt funktion. For at gøre dette skal Prometheus være installeret på klyngen, hvor Knative er installeret.

GitLab 11.10

Kontrol af parametre git clean for GitLab CI/CD jobs

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

Som standard udfører GitLab Runner git clean under kodeudtrækningen, når et job køres i GitLab CI/CD. Fra GitLab 11.10 kan brugere kontrollere parametrene der gives til kommandoen git clean. Dette er nyttigt for teams med dedikerede runners samt for teams der bygger projekter fra store monorepositorier. Nu kan de styre udtræksprocessen før scripts udføres. Den nye variabel GIT_CLEAN_FLAGS har som standard værdien -ffdx og accepterer alle mulige parametre for kommandoen [git clean](https://git-scm.com/docs/git-clean).

Ekstern godkendelse i Core

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

Sikrede miljøer kan kræve en ekstra ekstern godkendelsesressource for adgang til projektet. Vi har tilføjet support for et ekstra niveau af adgangskontrol i 10.6 og har modtaget mange anmodninger om at åbne denne funktionalitet i Core. Vi er glade for at præsentere ekstern godkendelse og et ekstra sikkerhedsniveau for Core instanser, da denne funktion er nødvendig for enkelte deltagere.

Mulighed for at oprette projekter i grupper i Core

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

Developer rollen kan oprette projekter i grupper siden version 10.5, og nu er det muligt i Core. Oprettelse af projekter er en nøglefunktion for produktiv arbejde i GitLab, og med inkluderingen af denne funktion i Core er det nu lettere for deltagerne at tage fat på noget nyt.

GitLab Runner 11.10

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

I dag har vi udgivet GitLab Runner 11.10! GitLab Runner er et open source-projekt, der bruges til at køre CI/CD-opgaver og sende resultaterne tilbage til GitLab.

De mest interessante ændringer:

En komplet liste over ændringer kan findes i changelog for GitLab Runner: CHANGELOG.

Rettelse af returneret project_id i blob-søge-API'et i Elasticsearch

STARTER, PREMIUM, ULTIMATE

Vi har rettet en fejl i blob-søge-API'et i Elasticsearch, som fejlagtigt returnerede 0 for project_id. Det vil være nødvendigt at genindeksere Elasticsearch, for at få de korrekte værdier project_id efter installationen af denne version af GitLab.

Omnibus-forbedringer

CORE, STARTER, PREMIUM, ULTIMATE

Vi har lavet følgende forbedringer i Omnibus i GitLab 11.10:

Ydelsesforbedringer

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

Vi fortsætter med at forbedre ydeevnen i GitLab med hver udgivelse for GitLab-forekomster i enhver størrelse. Nogle forbedringer i GitLab 11.10:

Forbedring af GitLab-diagrammer

CORE, STARTER, PREMIUM, ULTIMATE

Vi har lavet følgende forbedringer til GitLab-diagrammer:

Forældede funktioner

GitLab Geo vil levere hash-baseret lagring i GitLab 12.0

GitLab Geo kræver hash-baseret lagring for at afbøde konkurrencen på sekundære noder. Dette blev omtalt i gitlab-ce#40970.

I GitLab 11.5 har vi tilføjet dette krav til Geo-dokumentationen: gitlab-ee#8053.

I GitLab 11.6 sudo gitlab-rake gitlab:geo:check kontrollerer, om hash-lagring er aktiveret, og om alle projekter migreres. Se. gitlab-ee#8289. Hvis du bruger Geo, skal du køre denne kontrol og migrere så hurtigt som muligt.

I GitLab 11.8 permanent deaktiverbart advarsel gitlab-ee!8433 vil blive vist på siden Adminområde › Geo › Noder, hvis de førnævnte kontroller ikke er blevet godkendt.

I GitLab 12.0 Geo vil bruge kravene til hash-lagring. Se. gitlab-ee#8690.

Slettedato: 22. juni 2019.

Understøttelse af Ubuntu 14.04

GitLab 11.10 vil blive den sidste version med understøttelse af Ubuntu 14.04.

Canonical har annonceret ophøret af standardunderstøttelse af Ubuntu 14.04 fra april 2019. Vi anbefaler brugerne at opgradere til en understøttet LTS-version: Ubuntu 16.04 eller Ubuntu 18.04.

Slettedato: 22. maj 2019

Begrænsning af det maksimale antal pipelines, der kan oprettes af en enkelt push

Tidligere oprettede GitLab pipelines for HEAD hver gren i pushen. Dette er praktisk for udviklere, der sender flere ændringer samtidigt (f.eks. til en funktionsgren og til grenen develop).

Men ved push af et stort repository, hvor der er mange aktive grene (f.eks. til flytning, spejling eller forgrening), er det ikke nødvendigt at oprette en pipeline for hver gren. Fra GitLab 11.10 opretter vi maksimalt 4 pipelines ved push.

Slettedato: 22. maj 2019

Forældede legacy-stier i GitLab Runner

Fra Gitlab 11.9 bruger GitLab Runner en ny metode kloning\/kald af repository. I øjeblikket vil GitLab Runner bruge den gamle metode, hvis den nye ikke understøttes. Læs mere i denne opgave.

I GitLab 11.0 ændrede vi synet på metrics server-konfiguration for GitLab Runner. metrics_server vil blive fjernet til fordel for listen_address i GitLab 12.0. Læs mere i denne opgave.

I version 11.3 begyndte GitLab Runner at understøtte flere cache-udbydere; hvilket førte til nye indstillinger for den specifikke S3-konfiguration. I dokumentationen, med en tabel over ændringer og instruktioner til at overgå til den nye konfiguration. Læs mere i denne opgave.

Disse stier vil ikke være tilgængelige i GitLab 12.0. Som bruger behøver du ikke at ændre noget, blot sikre dig, at din GitLab-installation kører på version 11.9+ ved opgradering til GitLab Runner 12.0.

Slettedato: 22. juni 2019.

Forældet parameter for feature entry point til GitLab Runner

I 11.4 blev GitLab Runner introduceret med parameteren FF_K8S_USE_ENTRYPOINT_OVER_COMMAND for at rette sådanne problemer som #2338 og #3536.

I GitLab 12.0 vil vi skifte til korrekt opførsel, som om feature-parameteren var deaktiveret. Læs mere i denne opgave.

Slettedato: 22. juni 2019.

Forældet understøttelse af Linux-distributioner, der har nået EOL, for GitLab Runner

Nogle Linux-distributioner, hvor GitLab Runner kan installeres, er udløbet.

I GitLab 12.0 vil GitLab Runner ikke længere distribuere pakker til sådanne Linux-distributioner. Den fulde liste over distributioner, der ikke længere understøttes, kan findes i vores dokumentationen. Tak til Javier Ardó (Javier Jardón) for dit bidrag!

Slettedato: 22. juni 2019.

Fjernelse af gamle GitLab Runner Helper-kommandoer

Som led i indsatsen for at understøtte Windows Docker executor blev nogle gamle kommandoer, der bruges til helper image.

I GitLab 12.0 kører GitLab Runner med nye kommandoer. Dette gælder kun for brugere, der overrider helper-billede. Læs mere i denne opgave.

Slettedato: 22. juni 2019.

Fjernelse af den legacy git clean mekanisme fra GitLab Runner

I GitLab Runner 11.10 giver vi mulighed for at konfigurere, hvordan Runner udfører kommandoen git clean. Desuden fjerner den nye rengøringsstrategi brugen af git reset og placerer kommandoen git clean efter upload-trinnet.

Da denne ændring i adfærd kan påvirke nogle brugere, har vi forberedt parameteren FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Hvis værdien sættes til true, vil den genoprette legacy-rengøringsstrategien. Mere om brugen af funktionsparametre i GitLab Runner kan findes i dokumentationen.

I GitLab Runner 12.0 vil vi fjerne understøttelsen af legacy-rengøringsstrategien og muligheden for at genoprette den via funktionsparameteren. Læs mere i denne opgave.

Slettedato: 22. juni 2019.

Systeminfo-sektionen i administrationspanelet

GitLab præsenterer oplysninger om din GitLab-instans i admin/system_info, men disse oplysninger kan være unøjagtige.

Vi vil fjerne denne sektion af administrationspanelet i GitLab 12.0 og anbefaler at bruge andre overvågningsmuligheder.

Slettedato: 22. juni 2019.

Ændringslog

Find alle disse ændringer i ændringsloggen:

Installation

Hvis du konfigurerer en ny GitLab-installation, besøg download-siden for GitLab.

Opdatering

Tjek ind på opdateringsside.

GitLab abonnementsplaner

GitLab findes i to versioner: selv-hostet og cloudbaseret SaaS.

Selv-hostet: lokalt eller på en foretrukken cloudplatform.

  • Core: til små teams, personlige projekter eller en ubegribset prøveversion af GitLab.
  • Starter: til teams, der arbejder på et kontor med flere projekter, som har brug for professionel support.
  • Premium: til distribuerede teams, der har brug for avancerede funktioner, høj tilgængelighed og døgnsupport.
  • Ultimate: til virksomheder, der kræver en robust strategi og implementering med forbedret sikkerhed og overholdelse af krav.

Cloudbaseret SaaS — GitLab.com: hostet, styret og administreret af GitLab med gratis og betalte abonnementer til individuelle udviklere og teams.

  • Gratis: ubegrænsede private repositories og ubegrænsede deltagerantal. Lukkede projekter har adgang til funktioner på niveau Gratis, mens åbne projekter har adgang til funktioner på niveau Gold.
  • Bronze: til teams, der har brug for adgang til avancerede arbejdsstrømsfunktioner.
  • Silver: til teams, der kræver mere pålidelige DevOps-capabilities, overholdelse af krav og hurtig support.
  • Gold: egnet til mange CI/CD jobs. Alle åbne projekter kan gratis bruge Gold-funktioner uafhængigt af planen.

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster