De release 13.4 is uitgebracht met de HashiCorp-opslag voor CI-variabelen, Kubernetes Agent en een beveiligingscentrum, evenals schakelbare functies in Starter.
Bij GitLab denken we altijd na over hoe we gebruikers kunnen helpen om risico's te verminderen, de efficiëntie te verhogen en de snelheid van levering op uw favoriete platform te verbeteren. Deze maand hebben we een aantal nuttige vernieuwingen toegevoegd die de beveiligingsmogelijkheden uitbreiden, het aantal kwetsbaarheden verminderen, de efficiëntie verhogen, het werken met GitLab vereenvoudigen en uw team helpen om functies nog sneller te leveren. We hopen dat de belangrijkste functies van deze release nuttig voor u zijn. 53 andere nieuwe functies, toegevoegd in deze release.
Uitgebreidere beveiligingsmogelijkheden
We voegen elke maand een paar nieuwe functies toe aan GitLab DevSecOps, en deze release is daarop geen uitzondering. in het kader van bouwen en implementeren. Daarnaast kunnen organisaties die verantwoordelijkheidsdeling voor code-implementatie willen handhaven, nu Deze rol valt onder en stelt hen in staat om merge requests te bevestigen en code in beveiligde omgevingen te implementeren, zonder toegang te geven om de code zelf te wijzigen.
Een andere manier om risico's te verlagen is het gebruik van de nieuwe Operatiespecialisten kunnen Kubernetes-clusters vanuit GitLab implementeren zonder toegang tot hun cluster voor het hele internet te hoeven openen. We introduceren ook automatische versiecontrole voor nieuwe Terraform-statebestanden met voor naleving van voorschriften en gemak bij debugging. Tot slot is het beveiligingsdashboard in de instantie veranderd in met rapporten over kwetsbaarheden en beveiligingsinstellingen.
Handiger en efficiënter werken met GitLab
We hebben onze wereldwijde zoekfunctie verbeterd door waardoor u eenvoudig kunt overschakelen naar de laatste tickets, groepen, projecten, instellingen en secties van de handleiding. We zijn blij aan te kondigen dat er nu omleidingen zijn in GitLab Pages. voor het doorsturen van afzonderlijke pagina's en mappen binnen de site, zodat gebruikers hun sites effectiever kunnen uitrollen. Voor degenen die uitgebreide informatie over uitrol willen ontvangen, maakt deze release het mogelijk !
Open source modules
Wij presenteren , die is toegevoegd door . Marks van de coverage van unit tests van de gewijzigde code geven ontwikkelaars een duidelijk overzicht van de code coverage bij de review; deze informatie helpt om de review sneller te maken en de tijd voor het mergen en uitrollen van nieuwe code te verminderen. En we en we zijn van plan .
En dit is nog maar het begin!
Zoals altijd is er te weinig ruimte in het algemene overzicht, maar er zijn zeer veel geweldige functies in release 13.4. Hier zijn nog een paar:
- .
Als je van tevoren wilt weten wat je kunt verwachten in de volgende release, kijk dan naar .
.
van deze maand —
Fabio heeft een aanzienlijke bijdrage geleverd in — een functie waar de GitLab-gemeenschap lange tijd op heeft gewacht. Dit is een echt belangrijke bijdrage met niet-triviale wijzigingen die voortdurende samenwerking met teamleden van GitLab vereisten en veel gebieden van het project aangrepen, zoals UX, front-end en back-end.
Belangrijkste functies van release GitLab 13.4
Gebruik HashiCorp Vault sleutels in CI-taken
(PREMIUM, ULTIMATE, SILVER, GOLD)
In release 12.10 heeft GitLab de mogelijkheid geïntroduceerd om sleutels in CI-taken te ontvangen en door te geven via de GitLab runner. Nu breiden we , door nieuwe syntaxis toe te voegen voor secrets naar bestand .gitlab-ci.yml. Dit zal de configuratie en het gebruik van HashiCorp storage met GitLab vergemakkelijken.
en .
Een introductie van de GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
Integratie van GitLab met Kubernetes maakt het al geruime tijd mogelijk om in Kubernetes-clusters te implementeren zonder handmatige instellingen. Veel gebruikers waarderen het gemak van deze combinatie, terwijl anderen enkele moeilijkheden tegenkwamen. Voor de huidige integratie moet uw cluster toegankelijk zijn vanuit het internet, zodat GitLab er toegang toe heeft. Voor veel organisaties is dit niet mogelijk, aangezien ze de toegang tot clusters beperken om redenen van beveiliging, naleving of regelgeving. Om deze beperkingen te omzeilen, moesten gebruikers hun eigen tools bovenop GitLab bouwen, anders konden ze deze mogelijkheid niet gebruiken.
Vandaag introduceren we de GitLab Kubernetes Agent — een nieuwe manier om in Kubernetes-clusters te implementeren. De agent werkt binnen uw cluster, zodat u het niet voor het hele internet hoeft te openen. De agent coördineert de implementatie door nieuwe wijzigingen bij GitLab op te vragen, in plaats van dat GitLab updates naar het cluster verzendt. Ongeacht welke GitOps-methode u gebruikt, GitLab zal bij u passen.
Let op, dit is de eerste release van de agent. Momenteel richten we ons met de GitLab Kubernetes Agent op het configureren en beheren van implementaties via code. Sommige bestaande functies van de Kubernetes-integratie, zoals implementatiedashboards en door GitLab beheerde applicaties, worden voorlopig niet ondersteund. , dat deze mogelijkheden in toekomstige versies aan de agent zullen worden toegevoegd, evenals nieuwe integraties die gericht zijn op veiligheid en naleving.
en .
Geef gebruikers toestemming voor implementatie zonder toegang tot de code
(PREMIUM, ULTIMATE, SILVER, GOLD)
Voorheen bood het machtigingssysteem in GitLab niet de mogelijkheid om verantwoordelijkheden binnen uw team goed te verdelen tussen degenen die verantwoordelijk zijn voor ontwikkeling en degenen die verantwoordelijk zijn voor implementatie. Met de release van GitLab 13.4 kunt u toestemming geven voor het goedkeuren van merge-verzoeken voor implementatie, evenals voor de feitelijke implementatie van code aan mensen die geen code schrijven, zonder hen de rechten van een maintainer (in de Nederlandse lokale versie van GitLab ‘ondersteuner’) te geven.
en .
Veiligheidscentrum
(ULTIMATE, GOLD)
Vroeger was het beheren van kwetsbaarheden op instapniveau beperkt in functionaliteit en flexibiliteit. De interface bestond uit één pagina die details van kwetsbaarheden, grafieken van metrics en instellingen verenigde. Er was niet veel ruimte voor de ontwikkeling van deze functies of het gebruik van andere beveiligingsmiddelen.
We hebben fundamentele veranderingen aangebracht in het beheer van beveiliging en de transparantie ervan in GitLab. Het beveiligingspaneel van de instantie is veranderd in een volledig beveiligingscentrum. De grootste wijziging is de introductie van een nieuwe menustructuur: in plaats van één pagina ziet u nu afzonderlijk het beveiligingsdashboard, het kwetsbaarhedenrapport en de instellingen. Hoewel de functionaliteit onveranderd is gebleven, zal het splitsen in onderdelen de verbetering van deze sectie vergemakkelijken, wat anders moeilijk zou zijn geweest. Dit creëert ook een basis voor de toevoeging van andere beveiligingsmogelijkheden in de toekomst.
De speciale sectie voor het kwetsbaarhedenrapport heeft nu meer ruimte om belangrijke details weer te geven. Hier zijn de kwetsbaarheden verzameld die momenteel op de kwetsbaarhedenlijst van het project staan. Door de widgets met kwetsbaarhedenmetrics naar een afzonderlijke sectie te verplaatsen, ontstaat er een handig beveiligingsdashboard. Dit wordt nu een canvas voor toekomstige visualisaties - niet alleen voor het beheren van kwetsbaarheden, maar ook voor andere beveiligingsgerelateerde metrics. Ten slotte creëert een aparte instellingenruimte een gemeenschappelijke ruimte voor alle beveiligingsinstellingen op instapniveau, niet alleen voor het beheren van kwetsbaarheden.
en .
Inschakelbare functies zijn nu in GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab 11.4 is uitgebracht . In 12.2 introduceerden we strategieën voor hen en , en in 13.1 hebben we en voor verschillende omgevingen.
Eerder dit jaar heeft GitLab de verplichting aangegaan over te zetten naar open source. In deze release hebben we de overdracht van inschakelbare functies naar het Starter-plan voltooid en zullen we doorgaan met de overdracht naar Core met . We zijn blij deze mogelijkheid aan meer gebruikers te bieden en willen weten hoe u ze zult gebruiken.
en .
Snelle navigatie vanuit de zoekbalk
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Soms wil je tijdens het navigeren door GitLab rechtstreeks naar een specifiek project gaan, in plaats van naar de zoekresultatenpagina.
Met het globale zoekpaneel kun je snel toegang krijgen tot de laatste tickets, groepen, projecten, instellingen en ondersteuningssecties. Je kunt zelfs de sneltoets gebruiken /, om de cursor naar het zoekpaneel te verplaatsen, zodat je nog effectiever door GitLab kunt navigeren!
en .
Weergave van code-dekking in merge-verzoeken
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bij het beoordelen van een merge-verzoek kan het moeilijk zijn om te bepalen of de gewijzigde code is gedekt door unit-tests. In plaats daarvan kunnen reviewers zich baseren op de algemene dekking en eisen dat deze wordt verhoogd voordat ze het merge-verzoek goedkeuren. Dit kan leiden tot een onsystematische benadering van het schrijven van tests, wat eigenlijk de codekwaliteit of de testdekking niet verbetert.
Nu je het diff van het merge-verzoek bekijkt, zie je een visuele weergave van de code-dekking. Nieuwe markeringen helpen om snel te begrijpen of de gewijzigde code door een unit-test is gedekt, wat helpt bij het versnellen van de codebeoordeling en de tijd voor het mergen en implementeren van nieuwe code.
Dank en Siemens voor deze functie!
en .
Meer omgevingen en projecten op het omgevingpaneel
(PREMIUM, ULTIMATE, SILVER, GOLD)
Met de release van GitLab 12.5 kon je met de de status van omgevingen volgen, maar niet meer dan zeven omgevingen in drie projecten. We hebben dit paneel verbeterd in release 13.4, door het op pagina's te splitsen, zodat je je omgevingen gemakkelijker kunt onderhouden en beheren op grotere schaal. Nu kun je meer omgevingen in meer projecten zien.
en .
GitLab heeft het beheer van de GitLab Terraform-provider overgenomen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Onlangs hebben we en we zijn van plan . In de afgelopen maand hebben we 21 merge-verzoeken geaccepteerd en 31 tickets gesloten, waaronder enkele lang bestaande bugs en ontbrekende functies, zoals . Je kunt in de documentatie over Terraform.
en .
Fuzzing-testen van API met OpenAPI-specificaties of een HAR-bestand.
(ULTIMATE, GOLD)
Fuzzing-testen van API's is een uitstekende manier om fouten en kwetsbaarheden in uw webapplicaties en API's te vinden die andere scanners en testmethoden mogelijk over het hoofd zien.
API-fuzzing in GitLab maakt het mogelijk om of van uw applicatie en genereert vervolgens automatisch willekeurige invoer die bedoeld is om randgevallen te testen en fouten te zoeken. De resultaten worden onmiddellijk weergegeven binnen uw pipeline.
Dit is onze eerste release van API-fuzzing en we zijn benieuwd naar uw mening. Voor fuzzing-testen hebben we nog , die we zullen baseren op deze feature-release.
en .
Voorbeeld van nieuwe grafieken op het metriekdashboard
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vroeger was het maken van een grafiek op het metriekdashboard in GitLab een moeilijke taak. Nadat u een metriek in het YAML-bestand van het dashboard had aangemaakt, moest u wijzigingen aanbrengen in master, zonder dat u kon controleren of de zojuist gemaakte grafiek werkte zoals u wilde. Met deze release kunt u wijzigingen in real-time bekijken terwijl u de grafiek aanmaakt, zodat u inzicht krijgt in het resultaat voordat u de wijzigingen naar het YAML-bestand van het dashboard verzendt.
en .
Testcoverage-gegevens voor alle projecten in de groep
(PREMIUM, ULTIMATE, SILVER, GOLD)
Wanneer u een groot aantal projecten in GitLab beheert, heeft u een enkele informatiebron nodig over hoe de testcoverage in de loop van de tijd verandert voor alle projecten. Eerder vereiste het weergeven van deze informatie vermoeiende en tijdrovende handmatige arbeid: u moest de testcoverage-gegevens van elk project downloaden en deze in een tabel samenvoegen.
Met de release 13.4 is het nu mogelijk om deze gegevens eenvoudig en snel te verzamelen in .csv -bestand met alle testcoverage-gegevens van alle projecten in de groep of van een geselecteerde set projecten. Deze functie is een MVC, en het zal mogelijk zijn om .
en .
Ondersteuning voor nieuwe talen voor volledige fuzzing-tests
(ULTIMATE, GOLD)
Deze release introduceert ondersteuning voor meerdere nieuwe talen voor fuzzing-tests gericht op volledige dekking.
Nu kunt u alle mogelijkheden van fuzz-testing in uw Java-, Rust- en Swift-toepassingen beoordelen en fouten en kwetsbaarheden vinden die andere scanners en testmethoden mogelijk missen.
en .
Meldingen op de startpagina van omgevingen
(PREMIUM, ULTIMATE, SILVER, GOLD)
De pagina van omgevingen toont de algemene status van uw omgevingen. In deze release hebben we deze pagina verbeterd door meldingen weer te geven. Actieve meldingen, samen met de status van uw omgevingen, helpen u sneller actie te ondernemen om opkomende situaties te verhelpen.
en .
Geneste pipelines kunnen nu hun geneste pipelines starten
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Met geneste pipelines is het nu mogelijk om nieuwe pipelines binnen sub-pipelines te starten. Een extra diepte-niveau kan nuttig zijn als u flexibiliteit nodig heeft om een variabel aantal pipelines te genereren.
Eerder, bij het gebruik van geneste pipelines, had elke sub-pipeline een trigger-taak nodig, handmatig ingesteld in de bovenliggende pipeline. Nu kunt u geneste pipelines maken die dynamisch een onbeperkt aantal nieuwe geneste pipelines zullen starten. Bijvoorbeeld, als u een monorepository heeft, kunt u dynamisch de eerste geneste pipeline genereren die zelf het benodigde aantal nieuwe pipelines aanmaakt, op basis van wijzigingen in de branch.
en .
Verbeterde navigatie tussen bovenliggende en geneste pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Het navigeren tussen bovenliggende en geneste pipelines was eerder niet erg gebruiksvriendelijk — het kostte veel klikken om bij de juiste pipeline te komen. Het was ook moeilijk te begrijpen welke taak deze pipeline had geactiveerd. Nu is het veel gemakkelijker om de verbanden tussen bovenliggende en geneste pipelines te zien.
en .
Parallele matrix-taken tonen relevante variabelen in de naam van de taak
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Als u gebruik heeft gemaakt van , dan is het u misschien opgevallen dat het moeilijk te bepalen was welke matrix-variabele voor een bepaalde taak werd gebruikt, omdat de namen van de taken eruitzagen als matrix 1/4In release 13.4, you will see relevant variable values that were used in this task instead of the generic task name. For example, if your goal is debugging for the x86 architecture, the task will be called matrix: debug x86.
en .
Other improvements in GitLab 13.4
Connecting your Atlassian account
(CORE, STARTER, PREMIUM, ULTIMATE)
GitLab users can now link their GitLab accounts to Atlassian Cloud accounts. This will allow authentication in GitLab with Atlassian credentials and lay the groundwork for future improvements in integration and other products from the Atlassian line.
en .
Exporting the list of all merge commits
(ULTIMATE, GOLD)
Organizations focused on compliance need a way to show auditors a complete overview of components related to any specific change in production. Within GitLab, this means gathering everything in one place: merge requests, tickets, pipelines, security scans, and other commit data. Until now, you had to either manually collect this in GitLab or set up your own tools to gather the information, which was not very effective.
Now you can programmatically collect and export this data to meet audit requirements or conduct other analyses. To export the list of all merge commits for the current group, you need to go to the and click the button List of all merge commits. The resulting file will contain all merge request commits, their authors, the ID of the related merge request, the group, project, confirming users, and other information.
en .
Outputting the list and managing personal access tokens via the API
(ULTIMATE, GOLD)
Managing access to the GitLab namespace is an important part of compliance activities. From the principles of least privilege to timer-based access revocation—there may be several requirements related to personal access tokens in GitLab. To make it easier to maintain and manage all these user credentials within your namespace, we have provided the ability to output a list of all personal access tokens and optionally via API.
Deze verbeteringen in de GitLab API stellen gebruikers in staat om hun eigen persoonlijke toegangstokens op te sommen en in te trekken, terwijl beheerders een lijst kunnen genereren en de tokens van hun gebruikers kunnen intrekken. Beheerders hebben nu gemakkelijker zicht op wie toegang heeft tot hun namespace, kunnen besluiten om toegang toe te wijzen op basis van gebruikersgegevens, en kunnen persoonlijke toegangstokens intrekken die mogelijk zijn gecompromitteerd of die buiten het beleid van het bedrijf voor toegangsbeheer vallen.
en .
Gerelateerde tickets en andere functies nu in GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Enkele maanden geleden hebben we een plan aangekondigd om . In het kader van het nakomen van deze belofte hebben we , en (in de Nederlandse vertaling van GitLab 'discussiebord') beschikbaar in het Core-plan. Dit geldt alleen voor relaties van het type 'gerelateerd aan'; relaties van het type 'blokkeert' en 'geblokkeerd door' blijven in de betaalde plannen.
en .
Weergave van de naam van de oorspronkelijke branch op de zijbalk van de merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bij het beoordelen van codewijzigingen, discussies en commits van de merge request is het vaak wenselijk om een lokale checkout van de branch te maken voor een grondiger review. Echter, naarmate er meer inhoud aan de beschrijving van de merge request wordt toegevoegd, wordt het steeds moeilijker om de naam van de branch te vinden, en moet men verder door de pagina scrollen.
We hebben de naam van de branch aan de zijbalk van de merge request toegevoegd, waardoor deze te allen tijde beschikbaar is en men niet langer door de hele pagina hoeft te scrollen. Net als de link naar de merge request bevat het gedeelte met de oorspronkelijke branch een handige knop 'kopiëren'.
Dank voor zijn enorme bijdrage aan de ontwikkeling van deze functie!
en .
Aanduiding van ingeklapt bestanden in de diffs van de merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Merge-aanvragen die wijzigingen aan meerdere bestanden toevoegen, vouwen soms de diff van grote bestanden in om de prestaties te verbeteren. Wanneer dit gebeurt, kan het zijn dat je per ongeluk een bestand mist bij de review, vooral in merge-aanvragen met een groot aantal bestanden. Vanaf versie 13.4 zullen merge-aanvragen diff's markeren die ingeklapte bestanden bevatten, zodat je deze bestanden niet mist tijdens de code review. Voor nog meer duidelijkheid zijn we van plan om in de toekomst deze bestanden extra te markeren. Blijf op de hoogte van updates in .
en .
Waarschuwing voor de aanwezigheid van ingeklapte bestanden in de diff van de merge-aanvraag
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In de sectie met de diff's van merge-aanvragen worden grote bestanden ingeklapt om de prestaties te verbeteren. Bij het reviewen van de code kunnen echter enkele bestanden gemist worden wanneer de reviewer door de lijst met bestanden bladert, omdat alle grote bestanden zijn ingeklapt.
We hebben een zichtbare waarschuwing bovenaan de pagina van de diff van de merge-aanvraag toegevoegd om gebruikers te informeren dat er een ingeklapt bestand in deze sectie is. Op deze manier mis je geen wijzigingen in de merge-aanvraag tijdens de review.
en .
Automatisch herstel van de Gitaly-cluster repository
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vroeger, wanneer de primaire node van het Gitaly-cluster werd uitgeschakeld, werden repositories op deze node gemarkeerd als alleen-lezen. Dit voorkwam dataverlies in situaties waarin er wijzigingen op de node waren die nog niet waren gerepliceerd. Wanneer de node weer werd aangesloten, herstelde GitLab niet automatisch, en moesten beheerders het synchronisatieproces handmatig starten of akkoord gaan met dataverlies. Dit kon ook leiden tot verouderde of alleen-lezen repositories in andere situaties, zoals een mislukte replicatieopdracht op de secundaire node. In dit geval bleef de repository verouderd totdat de volgende schrijfoperatie plaatsvond, die de replicatieopdracht zou activeren.
Om dit probleem op te lossen nu plant hij een replicatietaak wanneer hij een verouderde repository op één node ontdekt en de laatste versie van de repository op een andere. Deze replicatietaak maakt de repository automatisch actueel, waardoor handmatig gegevensherstel niet nodig is. Automatisch herstel zorgt ook voor een snelle actualisatie van secundaire nodes als de replicatietaak mislukt, in plaats van te wachten op de volgende schrijfoperatie. Aangezien veel Gitaly-clusters een groot aantal repositories opslaan, vermindert dit aanzienlijk de tijd die beheerders en engineers voor betrouwbaarheid besteden aan gegevensherstel na een fout.
Bovendien start automatische reparatie de replicatie van repositories op elke nieuwe Gitaly-node die aan de cluster is toegevoegd, waardoor handmatig werk bij het toevoegen van nieuwe nodes wordt geëlimineerd.
en .
Markeer de to-do taak als voltooid op de ontwerppagina
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Effectieve communicatie in GitLab is gebaseerd op to-do lijsten. Als je in een opmerking wordt genoemd, is het cruciaal om de mogelijkheid te hebben om naar de taak te gaan en ofwel te beginnen met iets te doen, of deze als voltooid te markeren. Ook is het belangrijk om de mogelijkheid te hebben om een taak aan jezelf toe te wijzen wanneer je aan iets wilt werken of hier later op wilt terugkomen.
Eerder was het niet mogelijk om taken toe te voegen of ze als voltooid te markeren tijdens het werken met ontwerpen. Dit verstoorde de communicatie tussen productteams aanzienlijk, aangezien to-do taken een cruciaal onderdeel zijn van de workflow in GitLab.
In release 13.4 halen ontwerpen de opmerkingen bij tickets in gebruik van taken in, wat het werken ermee consistenter en efficiënter maakt.
en .
Verbeterde foutopsporinggids voor CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
We hebben de foutopsporinggids voor GitLab CI/CD verbeterd door extra informatie toe te voegen over veelvoorkomende problemen waarmee je te maken kunt krijgen. We hopen dat de verbeterde documentatie een waardevolle bron zal zijn die je helpt om GitLab CI/CD snel en eenvoudig in te stellen en te starten.
en .
Merge-verzoeken vallen niet langer uit de merge-wachtrij
(PREMIUM, ULTIMATE, SILVER, GOLD)
Eerder konden merge-verzoeken per ongeluk uit de merge-wachtrij vallen vanwege late opmerkingen. Als het merge-verzoek al in de wachtrij stond en iemand een opmerking toevoegde die een nieuw niet-opgelost discussie creëerde, werd het merge-verzoek als ongeschikt beschouwd voor de merge en viel het uit de wachtrij. Nu, nadat een merge-verzoek aan de merge-wachtrij is toegevoegd, kunnen nieuwe opmerkingen worden toegevoegd zonder het merge-proces te verstoren.
en .
Weergave van de code coverage waarde in het merge-verzoek voor de taak
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ontwikkelaars moeten in staat zijn om de code coverage waarde te zien na de voltooiing van de pipeline — zelfs in complexe scenario's zoals een pipeline die met meerdere taken werkt die moeten worden geparsed om de code coverage waarde te berekenen. Eerder toonde de widget van het merge-verzoek alleen het gemiddelde van deze waarden, wat betekende dat je naar de taakpagina en weer terug naar het merge-verzoek moest gaan om de tussenliggende code coverage waarden te krijgen. Om je tijd te besparen en deze onnodige stappen te vermijden, hebben we in de widget de weergave van de gemiddelde code coverage toegevoegd, de wijziging tussen de doel- en oorspronkelijke branches en een tooltip die de code coverage waarde toont voor elke taak waarop de gemiddelde waarde is gebaseerd.
en .
Verwijderen van pakketten uit het pakketregister tijdens het bekijken van een groep
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Het GitLab-pakketregister is een plek voor het opslaan en verspreiden van pakketten in verschillende formaten. Wanneer je veel pakketten in je project of groep hebt, moet je ongebruikte pakketten snel kunnen identificeren en verwijderen, zodat mensen ze niet downloaden. Je kunt pakketten uit je register verwijderen via of via de gebruikersinterface van het pakketregister. Tot nu toe kon je echter geen pakketten verwijderen tijdens het bekijken van een groep via de gebruikersinterface. Hierdoor moest je overtollige pakketten apart voor elk project verwijderen, wat inefficiënt was.
Nu kun je pakketten verwijderen terwijl je het pakketregister van de groep bekijkt. Ga gewoon naar de pagina van het pakketregister van de groep, filter de pakketten op naam en verwijder alle onnodige.
en .
Schaalbaarheid van Conan-pakketten naar projectniveau
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Je kunt de Conan-repository in GitLab gebruiken om afhankelijkheden van C/C++ te publiceren en te verspreiden. Eerder konden pakketten echter alleen tot instantie-niveau worden geschaald, aangezien de naam van het Conan-pakket maximaal 51 tekens kon bevatten. Als je een pakket uit een subgroep wilde publiceren, bijvoorbeeld gitlab-org/ci-cd/package-stage/feature-testing/conan, was het bijna onmogelijk om dit te doen.
Nu kun je Conan-pakketten naar projectniveau schalen, wat het eenvoudig maakt om afhankelijkheden van jouw projecten te publiceren en te verspreiden.
en .
Ondersteuning voor nieuwe package managers en talen voor afhankelijkheidsscanning
(ULTIMATE, GOLD)
We zijn blij om afhankelijkheidsscanning voor projecten met code in C, C++, C# en .Net, die NuGet 4.9+ of Conan-pakketmanagers gebruiken, toe te voegen aan onze lijst . Nu kun je afhankelijkheidsscanning opnemen als onderdeel van de Secure-fase, om bekende kwetsbaarheden van afhankelijkheden die via pakketmanagers zijn toegevoegd, te controleren. Gevonden kwetsbaarheden worden weergegeven in jouw merge-verzoek samen met het niveau van hun gevaarlijkheid, zodat je voordat je de merge uitvoert weet welke risico's de nieuwe afhankelijkheid met zich meebrengt. Je kunt jouw project ook zo instellen dat het vereist voor afhankelijkheden met kwetsbaarheden met een kritisch (Critical), hoog (High) of onbekend (Unknown) gevaarlijkheidsniveau.
en .
Meldingen bij het wijzigen van de merge-verzoekinstelling naar 'Mergen bij succesvolle voltooiing van de pipeline'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Eerder, bij het instellen van de merge-verzoekinstelling Mergen wanneer de pipeline is voltooid (Merge When Pipeline Succeeds, MWPS) werd er geen e-mailmelding verzonden. Je moest handmatig de status controleren of wachten op een melding over de uitvoering van de merge. In deze release zijn we blij om de bijdrage van gebruiker , die dit probleem heeft opgelost door automatische melding te verzenden naar iedereen die op het merge-verzoek is geabonneerd wanneer de reviewer de merge-instelling wijzigt naar MWPS, voor te stellen.
en .
Het creëren van EKS-clusters met een door de gebruiker opgegeven Kubernetes-versie
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab-gebruikers kunnen nu zelf de versie van Kubernetes kiezen die aan EKS wordt geleverd; u kunt kiezen tussen versies 1.14–1.17.
en .
Incidenten creëren als tickettypes
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Niet elk probleem dat zich voordoet, leidt onmiddellijk tot het versturen van meldingen: gebruikers rapporteren uitval, terwijl teamleden problemen met de prestaties onderzoeken. Nu zijn incidenten een type ticket, zodat uw teams ze snel binnen de gebruikelijke workflow kunnen aanmaken. Klik Nieuwe taak vanaf elke locatie in GitLab, en in het veld Type selecteer Incident.
en .
Het vermelden van GitLab-meldingen in Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
We hebben de GitLab-meldingen verbeterd door een nieuw type vermelding speciaal voor hen toe te voegen in de GitLab-uitvoering van Markdown, waardoor het eenvoudiger wordt om meldingen te delen en te vermelden. Gebruik ^alert#1234, om een melding in elk veld met Markdown-opmaak te vermelden: in incidenten, tickets of merge-verzoeken. Dit helpt u ook om taken die uit meldingen worden aangemaakt, te onderscheiden van die voortkomen uit tickets of merge-verzoeken.
en .
Bekijk de meldingsbelasting van incidenten
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
De beschrijving van de melding bevat informatie die essentieel is voor het diagnosticeren van storingen en herstel, en deze informatie moet gemakkelijk toegankelijk zijn, zodat u niet van gereedschappen of tabbladen hoeft te schakelen terwijl u een incident oplost. Incidenten die uit meldingen zijn aangemaakt, tonen de volledige beschrijving van de melding in het tabblad Alert Details.
75% snellere geavanceerde zoektocht
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab, als een enkele applicatie, heeft de unieke mogelijkheid om de zoekopdracht naar inhoud door het hele DevOps-workflow snel te maken. In GitLab 13.4 levert de geavanceerde zoektocht resultaten 75% sneller op wanneer deze , zoals op GitLab.com.
en .
Bekijk verwijderde projecten voor beheerders
(CORE, STARTER, PREMIUM, ULTIMATE)
De mogelijkheid om het verwijderen van een project uit te stellen is Echter, het was eerder niet mogelijk om op één plek alle projecten te zien die te wachten staan op verwijdering. Nu kunnen beheerders van GitLab-gebruikersinstanties alle projecten die op verwijdering wachten op één plek bekijken, samen met knoppen voor het eenvoudig herstellen van deze projecten.
Deze mogelijkheid stelt beheerders in staat om beter toezicht te houden op de verwijdering van projecten, door alle benodigde informatie op één plek te verzamelen en de kans te bieden om ongewenste verwijderacties te annuleren.
Dank voor deze functie!
en .
API-ondersteuning voor pushregels voor groepen toegevoegd
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Voorheen konden pushregels voor groepen alleen worden ingesteld door elke groep individueel via de GitLab-gebruikersinterface te bezoeken en deze regels toe te passen. Nu kunt u deze regels beheren via de API ter ondersteuning van uw eigen tools en automatisering binnen GitLab.
en .
Herroepen van persoonlijke toegangstokens voor zelf-beheerd credentialenopslag
(ULTIMATE)
biedt beheerders de informatie die nodig is om de credentialen van gebruikers van hun GitLab-instantie te beheren. Aangezien organisaties die zich richten op naleving van regels verschillen in de strengheid van hun credentialenbeheer, hebben we een knop toegevoegd waarmee beheerders desgewenst het persoonlijke toegangstoken van een gebruiker (PAT) kunnen intrekken. Nu kunnen beheerders eenvoudig mogelijk gecompromitteerde PAT's intrekken. Deze functie is nuttig voor organisaties die flexibelere opties nodig hebben om te voldoen aan vereisten, zodat de afleiding van hun gebruikers tot een minimum kan worden beperkt.
en .
Configuratiebestand voor de statische site-editor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 13.4 introduceren we een nieuwe manier om de statische site-editor in te stellen. Hoewel het configuratiebestand in deze release geen parameters opslaat of ontvangt, leggen we de basis voor toekomstige aanpassingen aan het gedrag van de editor. In komende releases zullen we het bestand .gitlab/static-site-editor.yml parameters voor het instellen , waarvoor , het aanpassen van de Markdown-syntaxinstellingen en andere editorinstellingen.
en .
Bewerken van de inleiding van een bestand met de statische site-editor.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
De inleiding (front matter) is een flexibele en handige manier om pagina-variabelen te definiëren in gegevensbestanden die bedoeld zijn voor verwerking door een statische site-generator. Het wordt meestal gebruikt om de paginatitel, sjabloon of auteur in te stellen, maar kan worden gebruikt om alle soorten metadata naar de generator door te geven bij het renderen van de pagina in HTML. Geplaatst aan de bovenkant van elk gegevensbestand, is de inleiding doorgaans geformatteerd als YAML of JSON en vereist het een consistente en nauwkeurige syntax. Gebruikers die niet bekend zijn met de specifieke syntaxisregels, kunnen per ongeluk ongeldige markup invoeren, wat op zijn beurt kan leiden tot opmaakproblemen of zelfs bouwfouten.
De WYSIWYG-bewerkingsmodus van de statische site-editor verwijdert al de inleiding uit de editor om deze opmaakfouten te voorkomen. Dit voorkomt echter niet dat u de waarden die in dit gedeelte zijn opgeslagen, kunt wijzigen zonder terug te keren naar de bewerking in de broncode. In GitLab 13.4 heeft u toegang tot elk veld en kunt u de waarde ervan bewerken in een vertrouwde formulierinterface. Bij het klikken op de knop Instellingen (Instellingen) verschijnt een paneel waarin voor elke sleutel die aan het begin is gedefinieerd, een formulier wordt weergegeven. De velden worden ingevuld met de huidige waarde, en om een van hen te bewerken, hoeft u alleen maar deze waarde in het webformulier in te voeren. Deze bewerking van de inleiding voorkomt complexiteit in de syntax en geeft u volledige controle over de inhoud, terwijl het zorgt voor een consistente opmaak van het eindresultaat.
en .
GitLab voor Jira en DVCS Connector nu in Core.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Voor Jira-gebruikers in GitLab: en maak het mogelijk om informatie over commits en merge requests van GitLab direct in Jira weer te geven. In combinatie met onze ingebouwde integratie met Jira, kunt u gemakkelijk tussen de twee applicaties navigeren tijdens uw werk.
Deze functies waren voorheen alleen beschikbaar in ons Premium-plan, maar zijn nu voor alle gebruikers toegankelijk!
en .
Stemmen met een meerderheid voor transacties in de Gitaly-cluster (bètaversie)
(CORE, STARTER, PREMIUM, ULTIMATE)
De Gitaly-cluster maakt het mogelijk om Git-repositories te repliceren naar meerdere 'warme' Gitaly-nodes. Dit verhoogt de beschikbaarheid door het elimineren van enkele punten van falen. , geïntroduceerd in GitLab 13.3, veroorzaakt een broadcast van wijzigingen naar alle Gitaly-nodes in de cluster, maar alleen de Gitaly-nodes die stemmen ter goedkeuring met de primaire node, slaan de wijzigingen op schijf op. Als niet alle replicanodes het eens zijn, wordt slechts één exemplaar van de wijziging op schijf opgeslagen, waardoor er een enkel punt van falen ontstaat tot de asynchrone replicatie is voltooid.
Stemmen met een meerderheid verhoogt de beschikbaarheid door toestemming van de meerderheid van de nodes (en niet van allemaal) te vereisen voordat wijzigingen op schijf worden opgeslagen. Als deze optionele functie is ingeschakeld, moet de opname succesvol op meerdere nodes worden uitgevoerd. Onenige nodes worden automatisch gesynchroniseerd via asynchrone replicatie met die nodes die een quorum hebben gevormd.
en .
Ondersteuning voor een aangepaste schema voor JSON-validatie in Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Projecten waarin mensen configuraties in JSON- of YAML-formaat schrijven, zijn vaak vatbaar voor problemen, omdat het gemakkelijk is om een typfout te maken en iets te breken. U kunt verificatietools schrijven om deze problemen in de CI-pijplijn te vangen, maar het gebruik van een JSON-schema kan nuttig zijn om documentatie en hints te bieden.
Projectdeelnemers kunnen in hun repository een pad naar het aangepaste schema definiëren in het bestand .gitlab/.gitlab-webide.yml, dat het schema en het pad naar de bestanden voor validatie aangeeft. Bij het uploaden van een specifiek bestand in Web IDE wordt er extra feedback en controle zichtbaar die helpt om het bestand te creëren.
en .
De limiet voor takken van een gerichte acyclische grafiek (DAG) is verhoogd naar 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Als u pipelines gebruikt (Directed Acyclic Graph (DAG)), heeft u misschien gemerkt dat de beperking van 10 taken die een taak kan specificeren in needs:, te streng. In 13.4 is de standaardlimiet verhoogd van 10 naar 50 om complexere netwerken van afhankelijkheden tussen taken in uw pipelines mogelijk te maken.
Als u een beheerder van een GitLab gebruikersinstance bent, kunt u deze limiet verder verhogen door een schakelbare functie in te stellen, hoewel we hiervoor geen officiële ondersteuning bieden.
en .
Verbeterd gedrag needs voor gemiste taken
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In sommige gevallen kon een gemiste taak in de pipeline ten onrechte als succesvol worden beschouwd voor de afhankelijkheden die zijn opgegeven in needs, waardoor de daaropvolgende taken werden gestart, wat niet had moeten gebeuren. Dit gedrag is gecorrigeerd in versie 13.4, en needs behandelt nu correct de gevallen van gemiste taken.
en .
Vergrendel de laatste artefact van de taak om te voorkomen dat deze wordt verwijderd
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab vergrendelt nu automatisch de laatste artefact van een succesvolle taak en pipeline op elke actieve branch, merge request of tag, om te voorkomen dat deze wordt verwijderd na het verstrijken van de geldigheid. Het wordt eenvoudiger om agressievere verloopregels in te stellen voor het opruimen van oude artefacten. Dit helpt het schijfgebruik te verlagen en zorgt ervoor dat u altijd een kopie van het laatste artefact uit de pipeline hebt.
en .
CI/CD handleiding voor het optimaliseren van pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Het optimaliseren van CI/CD-pipelines kan de levertijd versnellen en geld besparen. We hebben onze documentatie verbeterd door een beknopte handleiding toe te voegen om het maximale uit de optimalisatie van uw pipelines te halen.
en .
Het testverslag is gesorteerd op teststatus
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— dit is een eenvoudige manier om de resultaten van alle tests in de pipeline te bekijken. Met een groot aantal tests kan het echter veel tijd kosten om mislukte tests te vinden. Andere problemen die het gebruik van het rapport moeilijk kunnen maken, zijn onder andere problemen met het scrollen door lange uitvoerlogs en het afronden van de tijd naar nul voor tests die minder dan 1 seconde duren. Het testrapport plaatst nu standaard eerst de mislukte tests aan het begin van het rapport en sorteert daarna de tests op duur. Dit maakt het gemakkelijker om fouten en langdurige tests te vinden. Bovendien wordt de duur van de tests nu weergegeven in milliseconden of seconden, wat het lezen ervan veel sneller maakt, en eerdere scrollproblemen zijn ook opgelost.
en .
Beperkingen op bestandsgroottes die in het pakketrepository kunnen worden geüpload
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Er zijn nu beperkingen op de bestandsgroottes van pakketten die in het GitLab-pakketrepository kunnen worden geüpload. Beperkingen zijn toegevoegd om de prestaties van het pakketrepository te optimaliseren en misbruik te voorkomen. De beperkingen zijn afhankelijk van het pakketformaat. Voor GitLab.com zijn de maximale bestandsgroottes:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Voor aangepaste GitLab-instanties zijn de standaardwaarden hetzelfde. De beheerder kan echter de beperkingen bijwerken via de .
en .
Gebruik CI_JOB_TOKEN om PyPI-pakketten te publiceren
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Je kunt het GitLab PyPI-repository gebruiken om Python-pakketten samen met broncode en CI/CD-pipelines te maken, publiceren en delen. Voorheen kon je echter niet authentiseren in het repository met een vooraf gedefinieerde omgevingsvariabele CI_JOB_TOKEN. Hierdoor moest je je persoonlijke inloggegevens gebruiken om het PyPI-repository bij te werken, of besloot je misschien om het repository helemaal niet te gebruiken.
Het is nu gemakkelijker om GitLab CI/CD te gebruiken voor het publiceren en installeren van PyPI-pakketten met behulp van een vooraf gedefinieerde omgevingsvariabele. CI_JOB_TOKEN.
en .
DAST-scannerprofielen op aanvraag
(ULTIMATE, GOLD)
Voor het DAST-scannen op aanvraag, dat is , de DAST-scannerprofielen zijn toegevoegd. Ze breiden de configuratiemogelijkheden van deze scan uit, waardoor je snel meerdere profielen kunt aanmaken voor verschillende scantypes. In versie 13.4 bevat het scannerprofiel aanvankelijk de timeoutparameter voor de crawler, die bepaalt hoe lang de DAST-crawler actief moet zijn bij het proberen te detecteren van alle pagina's van de gescande website. Het profiel bevat ook een timeoutparameter voor de doelsite, om te bepalen hoe lang de scanner moet wachten voordat het de scan onderbreekt als de site niet reageert met een 200- of 300-statuscode. Naarmate we deze functie in toekomstige releases blijven verbeteren, zullen er extra configuratieparameters aan het scannerprofiel worden toegevoegd.
en .
Eenvoudig configuratiebestand voor redirects voor GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Als je GitLab Pages gebruikt en je wilt beter de URL-wijzigingen beheren, heb je misschien gemerkt dat het onmogelijk was om redirects op je GitLab Pages-site te beheren. GitLab maakt het nu mogelijk om regels in te stellen voor het omleiden van de ene URL naar de andere voor je Pages-site, door een configuratiebestand toe te voegen aan de repository. Deze functie is mogelijk gemaakt door de bijdrage van Kevin Barnett (), onze Eric Eastwood () en het GitLab-team. Bedankt voor jullie bijdrage.
en .
Terraform-status beheerd door GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Toegang tot eerdere versies van de Terraform-status is noodzakelijk voor zowel compliance als debuggen indien nodig. Ondersteuning voor versiebeheer van de door GitLab beheerde Terraform-status is beschikbaar vanaf GitLab 13.4. Versiebeheer wordt automatisch ingeschakeld voor nieuwe Terraform-statusbestanden. Bestaande Terraform-statusbestanden zullen in een latere release.
en .
Belangrijke details voor incidentwaarschuwingen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bij het afhandelen van incidenten is het belangrijk om gemakkelijk te bepalen hoelang een waarschuwing open heeft gestaan en hoe vaak een gebeurtenis zich heeft voorgedaan. Deze details zijn vaak cruciaal bij het bepalen van de impact op de klant en wat uw team prioriteit moet geven. Op het nieuwe incidentdetails-paneel tonen we de starttijd van de waarschuwing, het aantal gebeurtenissen en een link naar de oorspronkelijke waarschuwing. Deze informatie is beschikbaar voor incidenten die zijn aangemaakt uit waarschuwingen.
en .
Instellen en bewerken van de ernstparameter van een incident
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
De parameter 'ernst van het incident' stelt incidentresponspecialisten en belanghebbenden in staat om de gevolgen van een verstoring te beoordelen, evenals de methoden en urgentie van respons. Terwijl uw team de resultaten deelt tijdens het oplossen van het incident en herstelwerkzaamheden uitvoert, kunnen ze deze parameter aanpassen. Nu kunt u de ernst van het incident bewerken in het rechterzijpaneel van de pagina 'Incidentgegevens', en de ernst wordt weergegeven in de incidentenlijst.
en .
Het maken, bewerken en verwijderen van regels voor netwerkbeveiliging van containers
(ULTIMATE, GOLD)
Deze verbetering van de regeleditor voor netwerkbeveiliging van containers stelt gebruikers in staat om eenvoudig hun regels rechtstreeks vanuit de GitLab-gebruikersinterface te maken, te bewerken en te verwijderen. De functies van de editor omvatten een modus .yaml voor ervaren gebruikers en een regelseditor met een intuïtieve interface voor degenen die niet bekend zijn met netwerkregels. U kunt nieuwe mogelijkheden voor regelbeheer vinden in de sectie Beveiliging en compliance > Bedreigingsbeheer > Beleid (Security & Compliance > Threat Management > Policies).
en .
Ondersteuning voor Azure blob-opslag
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab en GitLab Runner ondersteunen nu , wat het gemakkelijker maakt om GitLab-diensten in Azure uit te voeren.
GitLab-instanties ondersteunen Azure voor alle soorten objectopslag, inclusief LFS-bestanden, CI-artikelen en . Volg de installatie-instructies om Azure blob-opslag in te stellen of .
GitLab-taakhandlers ondersteunen ook Azure voor het opslaan van . Azure-opslag kan worden ingesteld via de sectie .
en .
Omnibus ARM64-pakketten voor Ubuntu en OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
In reactie op de groeiende vraag naar ondersteuning voor het uitvoeren van GitLab op 64-bit ARM-architectuur, zijn we blij om de beschikbaarheid van het officiële ARM64 Ubuntu 20.04 Omnibus-pakket aan te kondigen. Hartelijk dank aan Zitai Chen en Guillaume Gardet voor hun enorme bijdrage — hun merge-verzoeken speelden hierin een sleutelrol!
Om het pakket voor Ubuntu 20.04 te downloaden en te installeren, ga naar onze en kies Ubuntu.
en .
Ondersteuning voor authenticatie met smartcards voor de GitLab Helm-chart
(PREMIUM, ULTIMATE)
Smartcards, zoals Common Access Cards (CAC), kunnen nu worden gebruikt voor authenticatie in een GitLab-instantie die is gedeployed via de Helm-chart. Smartcards worden geauthenticeerd in de lokale database met behulp van X.509-certificaten. Hierdoor is de ondersteuning voor smartcards in de Helm-chart nu in overeenstemming met de ondersteuning die beschikbaar is in Omnibus-deployments.
en .
Gedetailleerde release-opmerkingen en instructies voor update/installatie kunnen worden gelezen in de originele Engelstalige post: .
De vertaling vanuit het Engels is verzorgd door , , en .
Bron: habr.com
