Release 13.4 is uitgebracht met HashiCorp-opslag voor CI-variabelen, Kubernetes Agent en beveiligingscentrum, evenals schakelbare functies in Starter
Bij GitLab denken we er altijd over na hoe we gebruikers kunnen helpen risico's te verminderen, de efficiëntie te verbeteren en de leveringssnelheid op uw favoriete platform te verbeteren. Deze maand hebben we veel nuttige nieuwe functies toegevoegd die de beveiligingsmogelijkheden uitbreiden, het aantal kwetsbaarheden verminderen, de efficiëntie verhogen, het werken met GitLab vereenvoudigen en uw team helpen functies nog sneller te leveren. We hopen dat u de belangrijkste kenmerken van de release nuttig zult vinden, evenals 53 andere nieuwe functies, toegevoegd in deze release.
Geavanceerde beveiligingsfuncties
We proberen elke maand verschillende nieuwe functies aan GitLab DevSecOps toe te voegen, en deze release is daarop geen uitzondering. in het kader van montage en inzet. Bovendien kunnen organisaties die de scheiding van verantwoordelijkheden voor code-implementatie willen ondersteunen, dit nu doen . Deze rol komt overeen en stelt je in staat samenvoegverzoeken te bevestigen (in de Russische lokalisatie van GitLab “mergeverzoeken”) en code in beschermde omgevingen te implementeren, zonder toegang te verlenen om de code zelf te wijzigen.
Een andere manier om risico's te verminderen is door nieuw te gebruiken . Operationele teams kunnen Kubernetes-clusters vanuit GitLab implementeren zonder dat ze hun cluster aan het hele internet hoeven bloot te stellen. We introduceren ook automatische versiebeheerondersteuning voor nieuwe Terraform-statusbestanden met om naleving en het gemak van foutopsporing te ondersteunen. Ten slotte werd het instance-beveiligingsdashboard met kwetsbaarheidsrapporten en beveiligingsinstellingen.
Handiger en efficiënter werken met GitLab
We hebben onze wereldwijde zoekopdracht verbeterd om op te nemen , zodat u eenvoudig naar de nieuwste tickets, groepen, projecten, instellingen en helponderwerpen kunt navigeren. We zijn verheugd om aan te kondigen dat GitLab Pages om individuele pagina's en mappen binnen de site om te leiden, waardoor gebruikers hun sites efficiënter kunnen inzetten. En voor degenen die graag uitgebreide informatie over de implementatie willen ontvangen, biedt deze release de mogelijkheid !
Open source-bijdragen
wij presenteren die ik heb toegevoegd . Markeringen op de unittestdekking van gewijzigde code geven ontwikkelaars een duidelijk beeld van de codedekking tijdens de beoordeling; deze informatie helpt de beoordelingen te versnellen en de tijd voor het samenvoegen en implementeren van nieuwe code te verkorten. En wij ook en plannen .
En dit is nog maar het begin!
Zoals altijd is er te weinig ruimte in het algemene overzicht, maar er zijn veel coole functies in release 13.4. Hier zijn er nog een paar:
- .
Als je vooraf wilt weten wat je te wachten staat volgende laat los, kijk eens .
.
deze maand -
Fabio heeft een aanzienlijke bijdrage geleverd в - een functie waar al heel lang naar uitgekeken wordt in de GitLab-gemeenschap. Dit is een werkelijk belangrijke bijdrage met niet-triviale veranderingen die constante samenwerking met GitLab-teamleden vereisten en veel gebieden van het project beïnvloedden, zoals UX, front-end en back-end.
Belangrijkste kenmerken van de GitLab 13.4-release
Gebruik HashiCorp Vault-sleutels in CI-taken
(PREMIUM, ULTIEM, ZILVER, GOUD)
In release 12.10 introduceerde GitLab de mogelijkheid om sleutels naar CI-taken te ontvangen en over te dragen met behulp van de GitLab-taakhandler (GitLab runner). Nu zijn we aan het uitbreiden , nieuwe syntaxis toegevoegd secrets indienen .gitlab-ci.yml. Dit maakt het eenvoudiger om de HashiCorp-repository met GitLab in te stellen en te gebruiken.
и .
Introductie van GitLab Kubernetes Agent
(PREMIUM, ULTIEM)
De integratie van GitLab met Kubernetes maakt het al lang mogelijk om te implementeren in Kubernetes-clusters zonder dat handmatige configuratie nodig is. Veel gebruikers genoten van het gebruiksgemak van deze bundel, terwijl anderen enkele problemen ondervonden. Voor de huidige integratie moet uw cluster toegankelijk zijn vanaf internet, zodat GitLab er toegang toe heeft. Voor veel organisaties is dit niet mogelijk omdat ze de toegang tot clusters beperken om veiligheids-, compliance- of regelgevingsredenen. Om deze beperkingen te omzeilen, moesten gebruikers hun tools bovenop GitLab bouwen, anders zouden ze deze functie niet kunnen gebruiken.
Vandaag introduceren we de GitLab Kubernetes Agent, een nieuwe manier om te implementeren in Kubernetes-clusters. De agent wordt binnen uw cluster uitgevoerd, zodat u deze niet aan het hele internet hoeft bloot te stellen. De agent coördineert de implementatie door nieuwe wijzigingen aan te vragen bij GitLab, in plaats van dat GitLab updates naar het cluster pusht. Welke GitOps-methode je ook gebruikt, GitLab staat voor je klaar.
Houd er rekening mee dat dit de eerste release van de agent is. Onze huidige focus voor GitLab Kubernetes Agent is het configureren en beheren van implementaties via code. Sommige bestaande Kubernetes-integratiefuncties, zoals implementatieborden en door GitLab beheerde applicaties, worden nog niet ondersteund. dat deze mogelijkheden in toekomstige releases aan de agent zullen worden toegevoegd, evenals nieuwe integraties gericht op beveiliging en compliance.
и .
Geef gebruikers implementatiemachtigingen zonder codetoegang
(PREMIUM, ULTIEM, ZILVER, GOUD)
Voorheen maakte het toestemmingssysteem van GitLab het moeilijk om de verantwoordelijkheden binnen uw team goed te verdelen tussen degenen die verantwoordelijk zijn voor de ontwikkeling en degenen die verantwoordelijk zijn voor de implementatie. Met de release van GitLab 13.4 kun je toestemming geven om samenvoegverzoeken voor implementatie goed te keuren, en om code daadwerkelijk te implementeren aan mensen die de code niet schrijven, zonder hen toegangsrechten voor beheerders te geven (in de Russische lokalisatie van GitLab "onderhouder" ).
и .
Beveiligings centrum
(ULTIEME, GOUD)
Voorheen was kwetsbaarheidsbeheer op instanceniveau beperkt qua functionaliteit en flexibiliteit. De interface bestond uit één pagina die details van kwetsbaarheden, statistiekengrafieken en instellingen combineerde. Er is niet veel ruimte om deze functies te ontwikkelen of andere beveiligingsfuncties te gebruiken.
We hebben fundamentele wijzigingen aangebracht in de manier waarop we de beveiliging en transparantie in GitLab beheren. Het instance-beveiligingspaneel is omgetoverd tot een compleet beveiligingscentrum. De grootste verandering is de introductie van een nieuwe menustructuur: in plaats van één pagina zie je nu het beveiligingsdashboard, het kwetsbaarheidsrapport en het instellingengedeelte afzonderlijk. Hoewel de functionaliteit niet is veranderd, zal het opsplitsen in delen verbeteringen in deze sectie mogelijk maken die anders moeilijk zouden zijn. Dit vormt ook de weg voor het toevoegen van andere beveiligingsgerelateerde mogelijkheden in de toekomst.
De speciale sectie Kwetsbaarheidsrapport heeft nu meer ruimte om belangrijke details weer te geven. Dit zijn de kwetsbaarheden die momenteel op de lijst met kwetsbaarheden van het project staan. Door widgets met kwetsbaarheidsstatistieken naar een aparte sectie te verplaatsen, ontstaat een handig beveiligingscontrolepaneel. Het is nu een canvas voor toekomstige visualisaties – niet alleen voor kwetsbaarheidsbeheer, maar voor alle beveiligingsgerelateerde statistieken. Ten slotte creëert een apart instellingengebied een gemeenschappelijke ruimte voor alle beveiligingsinstellingen op instanceniveau, niet alleen voor kwetsbaarheidsbeheer.
и .
Schakelbare functies zijn nu beschikbaar in GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONS, ZILVER, GOUD)
GitLab 11.4 is uitgebracht . In 12.2 hebben we strategieën voor hen geïntroduceerd и , en in 13.1 voegden ze eraan toe и voor verschillende omgevingen.
Eerder dit jaar deed GitLab een toezegging naar open source. In deze release hebben we de migratie van schakelbare functies naar het Starter-abonnement voltooid en zullen we deze blijven migreren naar Core . We zijn blij deze functie aan meer gebruikers te kunnen aanbieden en willen graag horen hoe u deze gebruikt.
и .
Snelle navigatie vanuit de zoekbalk
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Soms wil je bij het navigeren door GitLab rechtstreeks naar een specifiek project gaan in plaats van naar de pagina met zoekresultaten.
Met behulp van de globale zoekbalk navigeer je snel naar de nieuwste tickets, groepen, projecten, instellingen en helponderwerpen. U kunt zelfs een sneltoets gebruiken /om je cursor naar de zoekbalk te verplaatsen om nog efficiënter door GitLab te navigeren!
и .
Codedekking weergeven in diffs van samenvoegverzoeken
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Bij het beoordelen van een samenvoegverzoek kan het moeilijk zijn om te bepalen of de gewijzigde code onder unit-tests valt. In plaats daarvan kunnen reviewers vertrouwen op de algehele dekking en verzoeken deze te vergroten voordat ze een samenvoegingsverzoek goedkeuren. Dit kan leiden tot een lukrake aanpak bij het schrijven van tests, waardoor de codekwaliteit of de testdekking niet daadwerkelijk wordt verbeterd.
Wanneer u nu een diff van een samenvoegverzoek bekijkt, ziet u een visuele weergave van de codedekking. Dankzij nieuwe markeringen kunt u snel begrijpen of de gewijzigde code onder een unit-test valt, waardoor de beoordeling van de code en het samenvoegen en implementeren van nieuwe code worden versneld.
Dank en Siemens voor deze functie!
и .
Meer omgevingen en projecten in het venster Omgevingen
(PREMIUM, ULTIEM, ZILVER, GOUD)
Sinds de release van GitLab 12.5 met behulp van je zou de status van omgevingen kunnen monitoren, maar niet meer dan zeven omgevingen in drie projecten. We hebben dit dashboard in release 13.4 verbeterd door het te pagineren, zodat u uw omgevingen op schaal kunt onderhouden en beheren. Nu kunt u meer omgevingen in meer projecten zien.
и .
GitLab neemt de controle over de GitLab Terraform-provider over
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Onlangs hebben we en plannen . De afgelopen maand hebben we 21 samenvoegverzoeken geaccepteerd en 31 tickets gesloten, inclusief enkele al lang bestaande bugs en ontbrekende functies zoals . Dat kan je in de Terraform-documentatie.
и .
Fuzzing API-testen met OpenAPI-specificaties of HAR-bestand
(ULTIEME, GOUD)
API-fuzzing-testen zijn een geweldige manier om bugs en kwetsbaarheden in uw webapplicaties en API's te vinden die andere scanners en testmethoden mogelijk over het hoofd zien.
Met API-fuzzing-tests in GitLab kunt u deze bieden of uw applicatie en genereert vervolgens automatisch willekeurige invoergegevens die zijn ontworpen om edge-cases te testen en bugs te vinden. Resultaten zijn direct zichtbaar binnen uw pipeline.
Dit is onze eerste API-fuzz-testrelease en we horen graag wat je ervan vindt. We hebben er nog meer op voorraad voor fuzz-testen , die we zullen baseren op de release van deze functie.
и .
Bekijk een voorbeeld van nieuwe grafieken in het deelvenster Metrieken
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Voorheen was het maken van een grafiek in het metrische dashboard in GitLab geen gemakkelijke taak. Nadat u de metriek in het YAML-bestand van het dashboard hebt gemaakt, heeft u wijzigingen aangebracht master, zonder dat u kunt verifiëren dat de nieuw gemaakte grafiek precies werkt zoals u nodig heeft. Vanaf deze release kunt u een voorbeeld van de wijzigingen bekijken terwijl u de grafiek maakt, zodat u een idee krijgt van het resultaat voordat u de wijzigingen naar het YAML-bestand van het dashboard verzendt.
и .
Gegevens over codedekking door tests voor alle projecten van de groep
(PREMIUM, ULTIEM, ZILVER, GOUD)
Wanneer je een groot aantal projecten in GitLab beheert, heb je één enkele informatiebron nodig over hoe de codedekking in de loop van de tijd voor alle projecten verandert. Voorheen vereiste het weergeven van deze informatie vervelend en tijdrovend handmatig werk: u moest codedekkingsgegevens van elk project downloaden en deze in een tabel combineren.
In release 13.4 werd het mogelijk om eenvoudig en snel te monteren .csv bestand met alle gegevens over codedekking voor alle projecten van de groep of voor een selectie van projecten. Deze functie is MVC, deze wordt gevolgd door de mogelijkheid .
и .
Ondersteuning voor nieuwe talen voor volledige fuzz-tests
(ULTIEME, GOUD)
Deze release introduceert ondersteuning voor verschillende nieuwe talen voor fuzz-testen gericht op volledige dekking.
Nu kunt u de volledige mogelijkheden van fuzzing-testen in uw Java-, Rust- en Swift-applicaties evalueren en fouten en kwetsbaarheden ontdekken die andere scanners en testmethoden mogelijk over het hoofd zien.
и .
Waarschuwingen op de hoofdomgevingspagina
(PREMIUM, ULTIEM, ZILVER, GOUD)
Op de pagina Omgevingen wordt de algemene status van uw omgevingen weergegeven. In deze release hebben we deze pagina verbeterd door waarschuwingsweergave toe te voegen. Geactiveerde waarschuwingen en de status van uw omgeving helpen u snel actie te ondernemen om situaties die zich voordoen te corrigeren.
и .
Geneste pijpleidingen kunnen nu hun eigen geneste pijpleidingen uitvoeren
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Door geneste pijpleidingen te gebruiken, is het nu mogelijk om nieuwe pijpleidingen binnen onderliggende pijpleidingen te laten draaien. Het extra diepteniveau kan handig zijn als u de flexibiliteit nodig heeft om een variabel aantal pijpleidingen te genereren.
Bij het gebruik van geneste pijplijnen moest voorheen voor elke onderliggende pijplijn een triggertaak handmatig worden gedefinieerd in de bovenliggende pijplijn. Nu kunt u geneste pijplijnen maken die dynamisch een willekeurig aantal nieuwe geneste pijplijnen lanceren. Als u bijvoorbeeld een monorepository heeft, kunt u dynamisch de eerste subpijplijn genereren, die zelf het vereiste aantal nieuwe pijplijnen zal creëren op basis van wijzigingen in de vertakking.
и .
Verbeterde navigatie tussen bovenliggende en geneste pijplijnen
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Voorheen was het navigeren tussen bovenliggende en geneste pijplijnen niet erg handig: u had veel klikken nodig om bij de gewenste pijplijn te komen. Het was ook niet eenvoudig om erachter te komen met welke klus de pijplijn begon. Nu zal het veel gemakkelijker zijn om de verbindingen tussen bovenliggende en geneste pijpleidingen te zien.
и .
Parallelle matrixfuncties tonen relevante variabelen in de functietitel
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Als je gebruikte , heb je misschien gemerkt dat het moeilijk was om te bepalen welke matrixvariabele voor een bepaalde functie werd gebruikt, omdat de functienamen er zo uitzagen: matrix 1/4. In release 13.4 zie je de relevante variabelewaarden die in die functie zijn gebruikt in plaats van de generieke functienaam. Als het bijvoorbeeld uw doel is om de x86-architectuur te debuggen, wordt de taak aangeroepen matrix: debug x86.
и .
Andere verbeteringen in GitLab 13.4
Een Atlassian-account koppelen
(KERN, STARTER, PREMIUM, ULTIEM)
GitLab-gebruikers kunnen nu hun GitLab-accounts koppelen aan hun Atlassian Cloud-account. Hierdoor kun je inloggen bij GitLab met je Atlassian-inloggegevens, en wordt ook de basis gelegd voor toekomstige integratieverbeteringen. en met andere producten uit de Atlassian-lijn.
и .
Een lijst met alle merge commits exporteren
(ULTIEME, GOUD)
Op compliance gerichte organisaties hebben een manier nodig om auditors een holistisch beeld te geven van de componenten die verband houden met een bepaalde verandering in de productie. In GitLab betekent dit dat je alles op één plek verzamelt: merge-aanvragen, tickets, pipelines, beveiligingsscans en andere commit-gegevens. Tot nu toe moest je het handmatig in GitLab verzamelen of je tools configureren om de informatie te verzamelen, wat niet erg efficiënt was.
U kunt deze gegevens nu programmatisch verzamelen en exporteren om aan auditvereisten te voldoen of andere analyses uit te voeren. Om een lijst met alle merge commits voor de huidige groep te exporteren, ga naar en klik op de knop Lijst met alle merge-commits. Het resulterende bestand bevat alle commits van het samenvoegverzoek, hun auteur, ID van het bijbehorende samenvoegverzoek, groep, project, bevestigingsmiddelen en andere informatie.
и .
Lijst en beheer persoonlijke toegangstokens via API
(ULTIEME, GOUD)
Het beheren van de toegang tot de GitLab-naamruimte is een belangrijk onderdeel van compliance-inspanningen. Van principes van minimale privileges tot het uitschakelen van getimede toegang, er kunnen verschillende vereisten zijn verbonden aan persoonlijke toegangstokens in GitLab. Om het makkelijker te maken om al deze gebruikersreferenties binnen uw naamruimte te onderhouden en te beheren, hebben we de mogelijkheid geboden om alle persoonlijke toegangstokens weer te geven en optioneel via API.
Met deze verbeteringen aan de GitLab API kunnen gebruikers hun eigen persoonlijke toegangstokens weergeven en intrekken, en kunnen beheerders de tokens van hun gebruikers weergeven en intrekken. Het wordt nu gemakkelijker voor beheerders om te zien wie toegang heeft tot hun naamruimte, toegangsbeslissingen te nemen op basis van gebruikersgegevens en persoonlijke toegangstokens in te trekken die mogelijk zijn gecompromitteerd of die buiten het toegangsbeheerbeleid van het bedrijf vallen.
и .
Gerelateerde problemen en andere functies bevinden zich nu in GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Een paar maanden geleden hebben we een plan aangekondigd om dat te doen . Door eraan te werken deze belofte waar te maken, hebben we dat gedaan , и (in de Russische lokalisatie van GitLab “discussiebord”) beschikbaar in het Core-plan. Dit is alleen van toepassing op ‘gekoppelde’ relaties, ‘blokken’ en ‘geblokkeerde’ relaties blijven in betaalde abonnementen.
и .
De oorsprongstaknaam weergeven in de zijbalk van het samenvoegverzoek
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Bij het beoordelen van codewijzigingen, discussies en commits van samenvoegverzoeken is het vaak wenselijk om lokaal af te rekenen in de vestiging voor een diepere beoordeling. Het vinden van de threadnaam wordt echter steeds moeilijker naarmate er meer inhoud wordt toegevoegd aan de beschrijving van het samenvoegverzoek en u verder naar beneden op de pagina moet scrollen.
We hebben de filiaalnaam toegevoegd aan de zijbalk van het samenvoegverzoek, waardoor deze op elk moment toegankelijk is en de noodzaak om door de hele pagina te scrollen wordt geëlimineerd. Net als de link naar het samenvoegverzoek bevat de bronvertakkingssectie een handige ‘kopieer’-knop.
Dank voor je enorme bijdrage aan de ontwikkeling van deze functie!
и .
Indicatie van de aanwezigheid van samengevouwen bestanden in de diffs van samenvoegverzoeken
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Samenvoegverzoeken die wijzigingen aan meerdere bestanden toevoegen, laten soms de diffs van grote bestanden samenvallen om de weergaveprestaties te verbeteren. Wanneer dit gebeurt, is het mogelijk dat tijdens de beoordeling per ongeluk een bestand wordt overgeslagen, vooral bij samenvoegverzoeken met een groot aantal bestanden. Vanaf versie 13.4 zullen samenvoegverzoeken diffs markeren die gevouwen bestanden bevatten, zodat u deze bestanden niet mist tijdens de codebeoordeling. Voor nog meer duidelijkheid zijn we van plan om in een toekomstige release accentuering aan deze bestanden toe te voegen. Blijf op de hoogte voor updates over .
и .
Waarschuwing over de aanwezigheid van samengevouwen bestanden in de diff van een samenvoegverzoek
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
In de sectie diffs voor samenvoegverzoeken worden grote bestanden samengevouwen om de prestaties te verbeteren. Bij het beoordelen van code kunnen sommige bestanden echter worden gemist wanneer de revisor door de lijst met bestanden bladert, omdat alle grote bestanden zijn samengevouwen.
We hebben een zichtbare waarschuwing bovenaan de diff-pagina van het samenvoegverzoek toegevoegd om gebruikers te informeren dat er een samengevoegd bestand in deze sectie staat. Zo mist u tijdens de beoordeling geen wijzigingen in het samenvoegverzoek.
и .
Automatisch herstel van Gitaly-clusterrepository
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Als voorheen het primaire knooppunt van een Gitaly-cluster offline ging, werden de opslagplaatsen op dat knooppunt gemarkeerd als alleen-lezen. Dit voorkwam gegevensverlies in situaties waarin er wijzigingen op het knooppunt waren die nog niet waren gerepliceerd. Toen het knooppunt weer online kwam, werd GitLab niet automatisch hersteld en moesten beheerders het synchronisatieproces handmatig starten of gegevensverlies accepteren. Andere situaties, zoals het mislukken van een replicatietaak op een secundair knooppunt, kunnen ook resulteren in verouderde of alleen-lezen opslagplaatsen. In dit geval bleef de repository verouderd totdat de volgende schrijfbewerking plaatsvond, waardoor de replicatietaak zou worden gestart.
Om dit probleem op te lossen plant nu een replicatietaak wanneer het een verouderde repository op het ene knooppunt en de nieuwste versie van de repository op een ander knooppunt detecteert. Deze replicatietaak houdt de repository automatisch up-to-date, waardoor de noodzaak om gegevens handmatig te herstellen wordt geëlimineerd. Automatisch herstel zorgt er ook voor dat secundaire knooppunten snel worden bijgewerkt als een replicatietaak mislukt, in plaats van te wachten op de volgende schrijfbewerking. Omdat veel Gilaly-clusters een groot aantal opslagplaatsen opslaan, vermindert dit aanzienlijk de tijd die beheerders en betrouwbaarheidsingenieurs besteden aan het herstellen van gegevens na een fout.
Bovendien start automatische reparatie de replicatie van opslagplaatsen op elk nieuw Gitaly-knooppunt dat aan het cluster wordt toegevoegd, waardoor handmatig werk bij het toevoegen van nieuwe knooppunten wordt geëlimineerd.
и .
Markeer een actietaak als voltooid op de ontwerppagina
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Effectieve communicatie in GitLab is gebaseerd op to-do-lijsten. Als u in een opmerking wordt genoemd, is het van cruciaal belang dat u naar een taak kunt springen en iets kunt gaan doen of deze als voltooid kunt markeren. Het is ook belangrijk om jezelf een taak te kunnen toewijzen als je ergens aan moet werken of er later op terugkomt.
Voorheen kon u bij het werken met ontwerpen geen taken toevoegen of als voltooid markeren. Dit verstoorde de efficiëntie van de communicatie tussen productteams ernstig, aangezien taken een cruciaal onderdeel zijn van de GitLab-workflow.
In release 13.4 kunnen ontwerpen de ticketopmerkingen inhalen bij het gebruik van taken, waardoor het werken ermee consistenter en efficiënter wordt.
и .
Verbeterde gids voor probleemoplossing voor CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
We hebben de gids voor het oplossen van problemen voor GitLab CI/CD verbeterd met meer informatie over veelvoorkomende problemen die u kunt tegenkomen. We hopen dat de verbeterde documentatie een waardevolle hulpbron zal zijn om u te helpen GitLab CI/CD snel en gemakkelijk aan de slag te krijgen.
и .
Samenvoegverzoeken vallen niet langer uit de samenvoegwachtrij
(PREMIUM, ULTIEM, ZILVER, GOUD)
Voorheen konden samenvoegverzoeken per ongeluk uit de samenvoegwachtrij vallen vanwege late reacties. Als een samenvoegverzoek al in de wachtrij stond en iemand er een opmerking aan toevoegde waardoor een nieuwe, onopgeloste discussie ontstond, werd het samenvoegverzoek beschouwd als niet in aanmerking komend voor een samenvoeging en zou het uit de wachtrij vallen. Nadat een samenvoegverzoek aan de samenvoegwachtrij is toegevoegd, kunnen nu nieuwe opmerkingen worden toegevoegd zonder bang te hoeven zijn het samenvoegproces te verstoren.
и .
Het weergeven van de codedekkingswaarde voor een taak in een samenvoegverzoek
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Ontwikkelaars moeten de dekkingswaarde van de code kunnen zien nadat de pijplijn is voltooid, zelfs in complexe scenario's zoals het uitvoeren van een pijplijn met meerdere taken die moeten worden geparseerd om de dekkingswaarde te berekenen. Voorheen toonde de widget voor samenvoegverzoeken alleen het gemiddelde van deze waarden, wat betekende dat u naar de vacaturepagina en terug naar het samenvoegverzoek moest navigeren om tussenliggende dekkingswaarden te krijgen. Om u tijd en deze extra stappen te besparen, hebben we ervoor gezorgd dat de widget de gemiddelde dekkingswaarde weergeeft, de veranderingen tussen de doel- en bronvestigingen, en een tooltip die de dekkingswaarde toont voor elke taak op basis waarvan het gemiddelde is berekend.
и .
Pakketten verwijderen uit het pakketregister bij het bekijken van een groep
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Het GitLab-pakketregister is een plaats waar pakketten in verschillende formaten kunnen worden opgeslagen en gedistribueerd. Wanneer uw project of groep veel pakketten bevat, moet u snel ongebruikte pakketten identificeren en verwijderen om te voorkomen dat mensen ze downloaden. U kunt pakketten uit uw register verwijderen via of via de gebruikersinterface van het pakketregister. Tot nu toe kon u echter geen pakketten verwijderen wanneer u een groep via de gebruikersinterface bekijkt. Als gevolg daarvan moest je per project onnodige pakketten verwijderen, wat inefficiënt was.
U kunt nu pakketten verwijderen wanneer u het pakketregister van een groep bekijkt. Ga eenvoudigweg naar de pakketregisterpagina van de groep, filter de pakketten op naam en verwijder alle pakketten die u niet nodig hebt.
и .
Conan-pakketten opschalen naar projectniveau
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
U kunt de Conan-repository in GitLab gebruiken om C/C++-afhankelijkheden te publiceren en te distribueren. Voorheen konden pakketten echter alleen worden geschaald naar instantieniveau, omdat de Conan-pakketnaam maximaal 51 tekens mocht bevatten. Als u bijvoorbeeld een pakket uit een subgroep wilt publiceren gitlab-org/ci-cd/package-stage/feature-testing/conan, het was bijna niet te doen.
U kunt Conan-pakketten nu schalen tot op projectniveau, waardoor u eenvoudig de afhankelijkheden van uw projecten kunt publiceren en distribueren.
и .
Ondersteuning voor nieuwe pakketbeheerders en talen voor het scannen van afhankelijkheid
(ULTIEME, GOUD)
We zijn verheugd om afhankelijkheidsscans voor C-, C++-, C#- en .Net-codeprojecten die NuGet 4.9+ of Conan-pakketbeheerders gebruiken aan onze lijst toe te voegen . U kunt nu het scannen op afhankelijkheid inschakelen als onderdeel van de fase Veilig om te controleren op bekende kwetsbaarheden in afhankelijkheden die via pakketbeheerders zijn toegevoegd. De gevonden kwetsbaarheden worden in uw samenvoegingsverzoek weergegeven, samen met hun ernstniveau, zodat u voordat u de samenvoeging uitvoert, weet welke risico's de nieuwe afhankelijkheid met zich meebrengt. U kunt uw project ook naar wens configureren voor afhankelijkheden met kwetsbaarheden met een kritiek (kritisch), hoog (hoog) of onbekend (onbekend) ernstniveau.
и .
Meldingen bij het wijzigen van de instelling voor samenvoegverzoeken in 'Samenvoegen wanneer pijplijn succesvol is voltooid'
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Voorheen bij het instellen van de instellingen voor samenvoegverzoeken Samenvoegen wanneer de pijplijn is voltooid (Merge When Pipeline Succeeds, MWPS) Er is geen e-mailmelding verzonden. U moest de status handmatig controleren of wachten op een samenvoegmelding. Met deze release zijn we blij met gebruikersbijdragen , waarmee dit probleem werd opgelost door automatische meldingen toe te voegen aan iedereen die zich heeft geabonneerd op een samenvoegverzoek wanneer een revisor de samenvoeginstelling wijzigt in MWPS.
и .
EKS-clusters maken met een door de gebruiker opgegeven versie van Kubernetes
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
GitLab-gebruikers kunnen nu de versie van Kubernetes kiezen die door EKS wordt geleverd; u kunt kiezen tussen versies 1.14–1.17.
и .
Incidenten aanmaken als tickettypen
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Niet elk probleem dat zich voordoet, leidt onmiddellijk tot waarschuwingen: gebruikers melden storingen en teamleden onderzoeken prestatieproblemen. Incidenten zijn nu een soort ticket, zodat uw teams deze snel kunnen aanmaken als onderdeel van hun normale workflow. Klik овая адача overal in GitLab en in het veld Type kiezen Incident.
и .
GitLab-waarschuwingen vermelden in Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
We hebben GitLab-waarschuwingen verbeterd door een nieuw vermeldingstype specifiek voor hen toe te voegen in GitLab Markdown, waardoor het gemakkelijker wordt om waarschuwingen te delen en te vermelden. Gebruik ^alert#1234om de waarschuwing in elk Markdown-veld te vermelden: bij incidenten, tickets of samenvoegverzoeken. Dit helpt u ook bij het identificeren van vacatures die zijn gemaakt op basis van waarschuwingen in plaats van tickets of samenvoegverzoeken.
и .
Het bekijken van de alertlast per incident
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
De waarschuwingsbeschrijving bevat informatie die essentieel is voor probleemoplossing en herstel. Deze informatie moet gemakkelijk toegankelijk zijn, zodat u niet van tool of tabblad hoeft te wisselen terwijl u werkt aan het oplossen van een incident. Voor incidenten die op basis van waarschuwingen zijn gemaakt, wordt de volledige waarschuwingsbeschrijving op het tabblad weergegeven Waarschuwingsdetails.
75% sneller geavanceerd zoeken
(STARTER, PREMIUM, ULTIMATE, BRONS, ZILVER, GOUD)
GitLab heeft als enkele applicatie het unieke vermogen om snel content te ontdekken in uw gehele DevOps-workflow. In GitLab 13.4 levert geavanceerd zoeken 75% sneller resultaten op , zoals op GitLab.com.
и .
Verwijderde projecten bekijken voor beheerders
(KERN, STARTER, PREMIUM, ULTIEM)
Er was een optie om de verwijdering van het project uit te stellen . Voorheen was het echter niet mogelijk om alle projecten die op verwijdering wachtten op één plek te zien. GitLab-gebruikersinstantiebeheerders kunnen nu alle lopende verwijderingsprojecten op één plek bekijken, samen met knoppen om die projecten eenvoudig te herstellen.
Deze functie geeft beheerders meer controle over het verwijderen van projecten door alle relevante informatie op één plek te verzamelen en de mogelijkheid te bieden ongewenste verwijderingsacties ongedaan te maken.
Dank voor deze functie!
и .
Ondersteuning toegevoegd voor groepspushregels aan de API
(STARTER, PREMIUM, ULTIMATE, BRONS, ZILVER, GOUD)
Voorheen konden groepspushregels alleen worden geconfigureerd door elke groep afzonderlijk te bezoeken via de GitLab-gebruikersinterface en die regels toe te passen. U kunt deze regels nu beheren via een API ter ondersteuning van uw aangepaste tools en GitLab-automatisering.
и .
Persoonlijke toegangstokens intrekken voor zelfbeheerde opslag van inloggegevens
(ULTIEM)
Biedt beheerders de informatie die ze nodig hebben om gebruikersreferenties voor hun GitLab-instantie te beheren. Omdat op compliance gerichte organisaties variëren in de strengheid van hun beleid voor referentiebeheer, hebben we een knop toegevoegd waarmee beheerders optioneel het persoonlijke toegangstoken (PAT) van een gebruiker kunnen intrekken. Beheerders kunnen nu gemakkelijk potentieel gecompromitteerde PAT's intrekken. Deze functie is handig voor organisaties die flexibelere nalevingsopties willen om de verstoring voor hun gebruikers tot een minimum te beperken.
и .
Configuratiebestand voor de statische site-editor
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
In GitLab 13.4 introduceren we een nieuwe manier om de statische site-editor aan te passen. Hoewel het configuratiebestand in deze release geen instellingen opslaat of ontvangt, leggen we de basis voor toekomstige aanpassingen van het editorgedrag. In toekomstige releases zullen we het bestand aanvullen .gitlab/static-site-editor.yml parameters voor installatie waarop , waarbij de syntaxisinstellingen van Markdown en andere editorinstellingen worden overschreven.
и .
Het inleidende deel van een bestand bewerken met behulp van een statische site-editor
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Front Matter is een flexibele en handige manier om paginavariabelen in gegevensbestanden te definiëren voor verwerking door de statische sitegenerator. Het wordt meestal gebruikt om de paginatitel, lay-outsjabloon of auteur in te stellen, maar kan worden gebruikt om elk type metagegevens aan de generator door te geven bij het weergeven van de pagina in HTML. Het inleidende gedeelte, dat helemaal bovenaan elk gegevensbestand staat, is doorgaans opgemaakt als YAML of JSON en vereist een consistente en nauwkeurige syntaxis. Gebruikers die niet bekend zijn met specifieke syntaxisregels kunnen onbedoeld ongeldige markeringen invoeren, wat op zijn beurt opmaakproblemen of zelfs buildfouten kan veroorzaken.
De WYSIWYG-bewerkingsmodus van de statische site-editor verwijdert de intro al uit de editor om deze opmaakfouten te voorkomen. Dit voorkomt echter dat u de waarden die in dit deel zijn opgeslagen, kunt wijzigen zonder terug te keren naar het bewerken in de bronmodus. In GitLab 13.4 heb je toegang tot elk veld en kun je de waarde ervan bewerken in een vertrouwde, op formulieren gebaseerde interface. Wanneer de knop wordt ingedrukt Instellingen (Instellingen) wordt een paneel geopend met een formulierveld voor elke sleutel die aan het begin is gedefinieerd. De velden worden gevuld met de huidige waarde en het bewerken ervan is net zo eenvoudig als het invoeren ervan in het webformulier. Door de intro op deze manier te bewerken vermijdt u complexe syntaxis en krijgt u volledige controle over de inhoud, terwijl u ervoor zorgt dat het eindresultaat consistent wordt opgemaakt.
и .
GitLab voor Jira en DVCS Connector is nu in Core
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Voor Jira-gebruikers op GitLab: и kunt u informatie over GitLab-commits weergeven en verzoeken rechtstreeks in Jira samenvoegen. Gecombineerd met onze ingebouwde Jira-integratie kun je tijdens het werken eenvoudig tussen de twee apps schakelen.
Deze functies waren voorheen alleen beschikbaar in ons Premium-abonnement, maar zijn nu beschikbaar voor alle gebruikers!
и .
Meerderheidsstemming voor Gitaly-clustertransacties (bèta)
(KERN, STARTER, PREMIUM, ULTIEM)
Met een Gitaly-cluster kun je Git-opslagplaatsen repliceren naar meerdere ‘warme’ Gitaly-nodes. Dit verhoogt de fouttolerantie door het elimineren van enkele storingspunten. , geïntroduceerd in GitLab 13.3, zorgen ervoor dat wijzigingen worden uitgezonden naar alle Gitaly-knooppunten in het cluster, maar alleen Gitaly-knooppunten die in overeenstemming stemmen met het primaire knooppunt slaan de wijzigingen op schijf op. Als alle replicaknooppunten het er niet mee eens zijn, wordt er slechts één kopie van de wijziging op schijf opgeslagen, waardoor er één enkel storingspunt ontstaat totdat de asynchrone replicatie is voltooid.
Meerderheidsstemming verbetert de fouttolerantie door de toestemming van een meerderheid van de knooppunten (niet alle) te vereisen voordat wijzigingen op schijf worden opgeslagen. Als deze schakelfunctie is ingeschakeld, zou het schrijven op meerdere knooppunten moeten slagen. Afwijkende knooppunten worden automatisch gesynchroniseerd met behulp van asynchrone replicatie vanaf de knooppunten die een quorum hebben gevormd.
и .
Aangepaste schemaondersteuning voor JSON-validatie in Web IDE
(PREMIUM, ULTIEM, ZILVER, GOUD)
Projecten waarbij mensen configuraties in JSON of YAML schrijven, zijn vaak gevoelig voor problemen omdat het gemakkelijk is om een typefout te maken en iets kapot te maken. Het is mogelijk om inspectietools te schrijven om deze problemen in de CI-pijplijn op te sporen, maar het gebruik van een JSON-schemabestand kan handig zijn om documentatie en hints te bieden.
Projectdeelnemers kunnen in hun repository het pad naar een aangepast schema in een bestand definiëren .gitlab/.gitlab-webide.yml, waarin het schema en het pad naar de te controleren bestanden worden gespecificeerd. Wanneer u een specifiek bestand in de Web IDE laadt, ziet u aanvullende feedback en validatie om u te helpen het bestand te maken.
и .
Vertakkingslimiet voor gerichte acyclische grafieken (DAG) verhoogd naar 50
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Als u transportbanden gebruikt (Directed Acyclic Graph (DAG)), zou het kunnen zijn dat er een limiet van 10 taken is die een taak kan specificeren in needs:, te streng. In 13.4 is de standaardlimiet verhoogd van 10 naar 50 om complexere netwerken van relaties tussen taken in uw pijplijnen mogelijk te maken.
Als u beheerder bent van een aangepaste GitLab-instantie, kunt u deze limiet nog hoger verhogen door een schakelfunctie in te stellen, hoewel we hiervoor geen officiële ondersteuning bieden.
и .
Verbeterd gedrag needs voor gemiste opdrachten
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
In sommige gevallen kan een gemiste taak in een pijplijn ten onrechte als succesvol worden beschouwd voor de afhankelijkheden die zijn opgegeven in needs, waardoor daaropvolgende taken werden uitgevoerd, wat niet had mogen gebeuren. Dit gedrag is opgelost in versie 13.4 en needs behandelt nu correct gevallen van gemiste taken.
и .
Zet het laatste queeste-artefact vast om te voorkomen dat het wordt verwijderd
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
GitLab vergrendelt nu automatisch de laatste succesvolle taak en pijplijnartefact op elke actieve branch, merge-aanvraag of tag om te voorkomen dat deze na het verlopen wordt verwijderd. Het wordt gemakkelijker om agressievere vervalregels in te stellen om oude artefacten op te ruimen. Dit helpt het verbruik van schijfruimte te verminderen en zorgt ervoor dat u altijd over een kopie beschikt van het nieuwste artefact uit de pijplijn.
и .
CI/CD-gids voor pijplijnoptimalisatie
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Het optimaliseren van uw CI/CD-pijplijn kan de leveringssnelheid verbeteren en geld besparen. We hebben onze documentatie verbeterd met een korte handleiding waarmee u het meeste uit het optimaliseren van uw pijplijnen kunt halen.
и .
Testrapport gesorteerd op teststatus
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
is een eenvoudige manier om de resultaten van alle tests in een pijplijn te bekijken. Bij een groot aantal tests kan het vinden van mislukte tests echter lang duren. Andere problemen die het gebruik van het rapport lastig kunnen maken, zijn onder meer problemen bij het scrollen door lange trace-uitvoer en tijdafronding naar nul voor tests die in minder dan 1 seconde worden uitgevoerd. Bij het sorteren van een testrapport worden nu standaard mislukte tests eerst aan het begin van het rapport geplaatst en vervolgens worden de tests gesorteerd op duur. Dit maakt het gemakkelijker om fouten en lange tests te vinden. Bovendien worden de testduur nu weergegeven in milliseconden of seconden, waardoor ze veel sneller te lezen zijn, en eerdere scrollproblemen zijn ook opgelost.
и .
Limieten op de grootte van bestanden die naar het pakketregister worden geüpload
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Er zijn nu limieten voor de grootte van pakketbestanden die kunnen worden geüpload naar het GitLab-pakketregister. Er zijn beperkingen toegevoegd om de prestaties van het pakketregister te optimaliseren en misbruik te voorkomen. Limieten variëren afhankelijk van het pakketformaat. Voor GitLab.com zijn de maximale bestandsgroottes:
- Conan: 250 MB
- Maven: 3 GB
- NPM: 300 MB
- NuGet: 250 MB
- PyPI: 3 GB
Voor aangepaste GitLab-instanties zijn de standaardwaarden hetzelfde. De beheerder kan de beperkingen echter bijwerken met behulp van .
и .
Gebruik CI_JOB_TOKEN om PyPI-pakketten te publiceren
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
U kunt de GitLab PyPI-repository gebruiken om Python-pakketten samen met broncode en CI/CD-pijplijnen te maken, publiceren en delen. Voorheen kon u zich echter niet verifiëren bij de repository met behulp van een vooraf gedefinieerde omgevingsvariabele CI_JOB_TOKEN. Als gevolg hiervan moest u uw persoonlijke inloggegevens gebruiken om de PyPI-repository bij te werken, of heeft u besloten de repository helemaal niet te gebruiken.
Het is nu eenvoudiger om GitLab CI/CD te gebruiken om PyPI-pakketten te publiceren en te installeren met behulp van een vooraf gedefinieerde omgevingsvariabele CI_JOB_TOKEN.
и .
DAST-scannerprofielen op aanvraag
(ULTIEME, GOUD)
Tot de on-demand DAST-scan, dat was het , DAST-scannerprofielen zijn toegevoegd. Ze breiden de configuratiemogelijkheden van deze scans uit, waardoor u snel meerdere profielen kunt maken voor meerdere scantypen. In 13.4 bevat het crawlerprofiel standaard een crawlertime-outinstelling die bepaalt hoe lang de DAST-crawler moet draaien terwijl deze probeert alle pagina's van een gecrawlde site te ontdekken. Het profiel bevat ook een time-outinstelling voor de doelsite om in te stellen hoe lang de crawler moet wachten totdat een site toegankelijk wordt voordat de crawl wordt afgebroken als de site niet reageert met een statuscode 200 of 300. Naarmate we doorgaan met het verbeteren van deze functie, toegevoegd aan het scannerprofiel in toekomstige releases; aanvullende configuratieparameters zullen worden toegevoegd.
и .
Een eenvoudig omleidingsconfiguratiebestand voor GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Als u GitLab Pages gebruikt en URL-wijzigingen beter wilt beheren, is het u misschien opgevallen dat het beheren van omleidingen op uw GitLab Pages-site niet mogelijk was. Met GitLab kunt u nu regels configureren om de ene URL naar de andere om te leiden voor uw Pages-site door een configuratiebestand aan de repository toe te voegen. Deze functie wordt mogelijk gemaakt dankzij de bijdrage van Kevin Barnett (), onze Eric Eastwood () en GitLab-teams. Bedankt iedereen voor jullie input.
и .
Terraform-status beheerd door GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Toegang tot eerdere versies van de Terraform-status is noodzakelijk, zowel voor naleving als voor het opsporen van fouten, indien nodig. Ondersteuning voor versiebeheer Terraform-status beheerd door GitLab wordt geleverd vanaf GitLab 13.4. Versiebeheer wordt automatisch ingeschakeld voor nieuwe Terraform-statusbestanden. Bestaande Terraform-statusbestanden zullen dat zijn in een latere uitgave.
и .
Belangrijke details over incidentmeldingen
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Bij het verwerken van incidenten moet u eenvoudig kunnen bepalen hoe lang een waarschuwing open heeft gestaan en hoe vaak de gebeurtenis is geactiveerd. Deze details zijn vaak van cruciaal belang bij het bepalen van de impact op de klant en bij wat uw team als eerste moet aanpakken. In het nieuwe paneel Incidentdetails tonen we de starttijd van de waarschuwing, het aantal gebeurtenissen en een link naar de oorspronkelijke waarschuwing. Deze informatie is beschikbaar voor incidenten die worden gegenereerd op basis van waarschuwingen.
и .
De parameter voor de ernst van het incident instellen en bewerken
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Met de dimensie Incident Severity kunnen hulpverleners en belanghebbenden de impact van een storing bepalen, evenals de methode en urgentie van de reactie. Terwijl uw team resultaten deelt tijdens het oplossen en herstellen van incidenten, kunnen zij deze instelling wijzigen. U kunt nu de ernst van een incident bewerken in de rechterzijbalk van de pagina Incidentdetails. De ernst wordt weergegeven in de lijst met incidenten.
и .
Beveiligingsregels voor containernetwerken maken, bewerken en verwijderen
(ULTIEME, GOUD)
Met deze verbetering van de Container Network Security Rule Editor kunnen gebruikers eenvoudig hun regels rechtstreeks vanuit de GitLab-gebruikersinterface maken, bewerken en verwijderen. Editor-functies omvatten .yaml voor ervaren gebruikers en een regelseditor met een intuïtieve interface voor degenen die nieuw zijn op het gebied van netwerkregels. U kunt nieuwe opties voor regelbeheer vinden in de sectie Beveiliging en naleving > Bedreigingsbeheer > Regels (Beveiliging en compliance > Bedreigingsbeheer > Beleid).
и .
Ondersteuning voor Azure Blob-opslag
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONS, ZILVER, GOUD)
Zowel GitLab als GitLab Runner ondersteunen nu , waardoor het eenvoudiger wordt om GitLab-services op Azure uit te voeren.
GitLab-instanties ondersteunen Azure voor alle typen objectarchieven, inclusief LFS-bestanden, CI-artefacten en . Volg de installatie-instructies om Azure Blob-opslag in te stellen of .
GitLab-taakprocessors ondersteunen ook Azure voor opslag . Azure-opslag kan worden geconfigureerd met behulp van de sectie .
и .
Omnibus ARM64-pakketten voor Ubuntu en OpenSUSE
(KERN, STARTER, PREMIUM, ULTIEM)
Als antwoord op de groeiende vraag naar ondersteuning voor het draaien van GitLab op 64-bit ARM-architectuur, zijn we verheugd de beschikbaarheid aan te kondigen van het officiële ARM64 Ubuntu 20.04 Omnibus-pakket. Hartelijk dank aan Zitai Chen en Guillaume Gardet voor de enorme bijdragen die zij hebben geleverd - hun fusieverzoeken speelden hierin een sleutelrol!
Om het pakket voor Ubuntu 20.04 te downloaden en te installeren, gaat u naar onze en selecteer Ubuntu.
и .
Ondersteuning voor smartcardverificatie voor GitLab Helm-diagram
(PREMIUM, ULTIEM)
Smartcards, zoals Common Access Cards (CAC), kunnen nu worden gebruikt om te authenticeren bij een GitLab-instantie die via een Helm-diagram is geïmplementeerd. Smartcards worden geverifieerd tegen een lokale database met behulp van X.509-certificaten. Hiermee is smartcardondersteuning met Helm-diagram nu in lijn met de smartcardondersteuning die beschikbaar is in Omnibus-implementaties.
и .
Gedetailleerde release-opmerkingen en update-/installatie-instructies zijn te lezen in het originele Engelse bericht: .
We waren bezig met vertaling uit het Engels , , и .
Bron: www.habr.com