GitLab 11.10 met dashboardpijplijnen, samengevoegde resultatenpijplijnen en suggesties voor meerdere regels in samenvoegverzoeken.
Handige informatie over de prestaties van pijpleidingen in verschillende projecten
GitLab blijft de zichtbaarheid in de DevOps-levenscyclus vergroten. In dit nummer op controlepaneel een overzicht van de pijplijnstatus toegevoegd.
Dit is handig, zelfs als u de pijplijn van een enkel project bestudeert, maar het is vooral handig als u de pijplijn van een enkel project bestudeert meerdere projecten, - en dit gebeurt meestal als u microservices gebruikt en een pijplijn wilt uitvoeren voor het testen en leveren van code uit verschillende projectopslagplaatsen. Nu kun je de uitvoering meteen zien pijpleidingen op het bedieningspaneel, waar ze ook worden uitgevoerd.
Pijplijnen uitvoeren voor samengevoegde resultaten
In de loop van de tijd gaan de bron- en de doelbranche uiteenlopen en kan er een situatie ontstaan waarin ze afzonderlijk van elkaar omgaan, maar niet samenwerken. Nu kan je voer pijplijnen uit voor samengevoegde resultaten voordat u samenvoegt. Op deze manier zult u snel fouten opmerken die alleen zouden verschijnen als wijzigingen regelmatig tussen vestigingen zouden worden verplaatst, wat betekent dat u pijplijnfouten veel sneller corrigeert en de GitLab Runner.
Optimaliseer de samenwerking verder
GitLab 11.10 voegt nog meer functies toe voor naadloze samenwerking en vereenvoudigde workflows. IN vorig nummer we hebben suggesties geïntroduceerd voor samenvoegverzoeken, waarbij een revisor een wijziging in één regel in een opmerking bij een samenvoegverzoek kon voorstellen, en deze direct rechtstreeks vanuit de commentaarthread kon worden vastgelegd. Onze gebruikers vonden het leuk en vroegen om deze functie uit te breiden. Nu kunt u bieden wijzigingen voor meerdere lijnen, waarmee wordt aangegeven welke regels moeten worden verwijderd en welke moeten worden toegevoegd.
Het dashboard in GitLab geeft informatie weer over projecten in uw gehele GitLab-instantie. U voegt individuele projecten één voor één toe en kunt kiezen welk project u interesseert.
In deze release hebben we informatie over pijplijnstatussen aan het dashboard toegevoegd. Nu zien ontwikkelaars de functionaliteit van pijpleidingen in alle noodzakelijke projecten - in één interface.
Pijplijnen voor samengevoegde resultaten
PREMIUM, ULTIEM, ZILVER, GOUD
Het is gebruikelijk dat de bronvertakking in de loop van de tijd afwijkt van de doelvertakking, tenzij u voortdurend wijzigingen daartussen pusht. Als gevolg hiervan zijn de bron- en doeltakpijplijnen “groen” en zijn er geen samenvoegingsconflicten, maar mislukt de samenvoeging vanwege incompatibele wijzigingen.
Wanneer de pijplijn met samenvoegverzoeken automatisch een nieuwe link creëert die het gecombineerde resultaat bevat van het samenvoegen van de bron- en doelvertakkingen, kunnen we de pijplijn op die link uitvoeren en ervoor zorgen dat het algehele resultaat werkt.
Als u pijplijnen voor samenvoegverzoeken gebruikt (in welke hoedanigheid dan ook) en privé GitLab-runners versie 11.8 of ouder gebruikt, moet u deze bijwerken om dit probleem te voorkomen gitlab-ee#11122. Dit heeft geen invloed op gebruikers van openbare GitLab-runners.
Als je samen aan fusieverzoeken werkt, signaleer je vaak problemen en stel je oplossingen voor. Sinds GitLab 11.6 ondersteunen wij voorstel tot wijziging voor één lijn.
In versie 11.10 kunnen merge request diff commentaren wijzigingen in meerdere regels voorstellen, waarna iedereen met schrijfrechten voor de originele branch deze met één klik kan accepteren. Dankzij de nieuwe functie kunt u kopiëren en plakken vermijden, net als in eerdere versies.
Snelkoppelingen in één gebied
PREMIUM, ULTIEM, ZILVER, GOUD
Met labels binnen hetzelfde bereik kunnen teams elkaar uitsluitende labels (binnen hetzelfde bereik) toepassen op een probleem, samenvoegverzoek of episch scenario in scenario's met aangepaste velden of aangepaste workflowstatussen. Ze worden geconfigureerd met behulp van een speciale dubbele punt-syntaxis in de labeltitel.
Stel dat u een aangepast veld in taken nodig heeft om het besturingssysteem bij te houden van het platform waarop uw functies zich richten. Elke taak mag slechts betrekking hebben op één platform. U kunt snelkoppelingen maken platform::iOS, platform::Android, platform::Linux en anderen indien nodig. Als u een dergelijke snelkoppeling op een taak toepast, wordt automatisch een andere bestaande snelkoppeling verwijderd die begint met platform::.
Stel dat u snelkoppelingen heeft workflow::development, workflow::review и workflow::deployed, die de status van de workflow van uw team aangeeft. Als de taak al een snelkoppeling heeft workflow::development, en de ontwikkelaar wil de taak naar het podium verplaatsen workflow::review, het past alleen de nieuwe sneltoets en de oude toe (workflow::development) wordt automatisch verwijderd. Dit gedrag bestaat al wanneer u taken verplaatst tussen lijsten met snelkoppelingen op het takenbord die de workflow van uw team vertegenwoordigen. Nu kunnen teamleden die niet rechtstreeks met het taakbord werken, de workflowstatus in de taken zelf wijzigen.
Wanneer u doorgaans een containerregister met CI-pijplijnen gebruikt, pusht u meerdere afzonderlijke wijzigingen naar één tag. Vanwege de distributie-implementatie van Docker is het standaardgedrag het opslaan van alle wijzigingen in het systeem, maar deze nemen uiteindelijk veel geheugen in beslag. Als u de parameter -m с registry-garbage-collect, kunt u snel alle eerdere wijzigingen verwijderen en kostbare ruimte vrijmaken.
Extra CI Runner-minuten kopen
BRONS, ZILVER, GOUD
Gebruikers met betaalde GitLab.com-abonnementen (Gold, Silver, Bronze) kunnen nu extra CI Runner-minuten kopen. Voorheen was het noodzakelijk om te voldoen aan de quota waarin het plan voorziet. Met deze verbetering kunt u minuten boven het quotum vooraf kopen om onderbrekingen als gevolg van pijplijnsluitingen te voorkomen.
Nu kosten 1000 minuten $ 8, en je kunt er zoveel kopen als je wilt. Extra minuten worden gebruikt wanneer u uw volledige maandelijkse quotum heeft besteed, en de rest van de extra minuten wordt meegenomen naar de volgende maand. IN toekomstige uitgave we willen deze functie ook toevoegen aan gratis abonnementen.
Met Auto DevOps kunnen teams vrijwel moeiteloos overstappen naar moderne DevOps-praktijken. Vanaf GitLab 11.10 wordt elke taak in Auto DevOps geleverd als onafhankelijk sjabloon. Gebruikers kunnen gebruiken функцию includes in GitLab CI om individuele fasen van Auto DevOps in te schakelen en tegelijkertijd uw aangepaste bestand te gebruiken gitlab-ci.yml. Op deze manier kunt u alleen de taken inschakelen die u nodig hebt en profiteren van upstream-updates.
Beheer automatisch groepsleden op GitLab.com met behulp van SCIM
ZILVER GOUD
Voorheen moest je het groepslidmaatschap op GitLab.com handmatig beheren. U kunt nu SAML SSO gebruiken en het lidmaatschap beheren met SCIM om gebruikers op GitLab.com aan te maken, te verwijderen en bij te werken.
Dit is vooral handig voor bedrijven met grote aantallen gebruikers en gecentraliseerde identiteitsproviders. Nu beschikt u over één enkele bron van waarheid, zoals Azure Active Directory, en worden gebruikers automatisch aangemaakt en verwijderd via de identiteitsprovider in plaats van handmatig.
Log in op GitLab.com via SAML-provider
ZILVER GOUD
Bij het gebruik van SAML SSO voor groepen moest de gebruiker voorheen inloggen met GitLab-inloggegevens en een identiteitsprovider. Je kunt nu direct via SSO inloggen als GitLab-gebruiker gekoppeld aan een geconfigureerde groep.
Gebruikers hoeven niet tweemaal in te loggen, waardoor het voor bedrijven gemakkelijker wordt om SAML SSO voor GitLab.com te gebruiken.
Andere verbeteringen in GitLab 11.10
Episch schema voor kinderen
ULTIEM, GOUD
In de vorige release hebben we onderliggende epics (epics van epics) toegevoegd om je te helpen bij het beheren van je taakverdelingsstructuur. Kind-eposs verschijnen op de pagina van het ouder-epos.
In deze release wordt op de bovenliggende epische pagina een overzicht van onderliggende epics weergegeven, zodat teams de tijdlijn van onderliggende epics kunnen zien en de timingafhankelijkheden kunnen beheren.
In deze release introduceren we informatieve schermen die verschijnen wanneer u de muisaanwijzer op een koppeling voor een samenvoegverzoek plaatst. Voorheen lieten we alleen de titel van het samenvoegverzoek zien, maar nu tonen we ook de status van het samenvoegverzoek, de status van de CI-pijplijn en de korte URL.
Git-workflows voor het vrijgeven of verzenden van software omvatten vaak meerdere lange termijn vertakkingen – om reparaties aan eerdere versies aan te brengen (bijv. stable-11-9) of de overstap van kwaliteitstesten naar productie (bijv. integration), maar het is niet eenvoudig om samenvoegverzoeken voor deze branches te vinden tussen de vele openstaande samenvoegverzoeken.
De lijst met samenvoegverzoeken voor projecten en groepen kan nu worden gefilterd op de doelvertakking van het samenvoegverzoek, zodat u gemakkelijker de gewenste vertakking kunt vinden.
Als we de op Trunk gebaseerde ontwikkelmethode gebruiken, moeten we langlevende vestigingen vermijden ten gunste van kleine, tijdelijke vestigingen met één eigenaar. Kleine veranderingen worden vaak rechtstreeks naar de doelvertakking gepusht, maar als u dit doet, loopt u het risico dat de build kapot gaat.
Met deze release ondersteunt GitLab nieuwe Git-pushopties om automatisch samenvoegverzoeken te openen, de doelvertakking in te stellen en een samenvoeging af te dwingen op een succesvolle pijplijn vanaf de opdrachtregel op het moment van push naar de vertakking.
GitLab heeft toegang tot meerdere Prometheus-servers (omgeving, project en groepen (verwacht)), maar het hebben van meerdere eindpunten kan de complexiteit vergroten of wordt mogelijk niet ondersteund door standaarddashboards. Met deze release kunnen teams één enkele Prometheus API gebruiken, waardoor de integratie met diensten als Grafana veel eenvoudiger wordt.
In een projectwiki kunnen teams documentatie en andere belangrijke informatie delen, samen met broncode en taken. Met deze release kun je de lijst met Wiki-pagina's sorteren op aanmaakdatum en titel om snel recent gemaakte inhoud te vinden.
Het bewaken van bronnen die door het cluster zijn aangevraagd
ULTIEM, GOUD
GitLab helpt u bij het monitoren van uw Kubernetes-cluster voor ontwikkelings- en productietoepassingen. Vanaf deze release controleert u de CPU- en geheugenaanvragen van uw cluster om potentiële problemen op te sporen voordat deze problemen worden.
Bekijk Load Balancer-statistieken in het Grafana Dashboard
CORE, STARTER, PREMIUM, ULTIEM
Het is erg belangrijk om de gezondheid van uw GitLab-instantie te controleren. Voorheen leverden we standaarddashboards via een ingebedde Grafana-instantie. Vanaf deze release hebben we extra dashboards toegevoegd voor het monitoren van NGINX-load balancers.
SAST voor Elixir
ULTIEM, GOUD
We blijven de taalondersteuning uitbreiden en de veiligheidscontroles verdiepen. In deze release hebben we veiligheidscontroles voor projecten ingeschakeld Elixer en projecten die zijn gemaakt Phoenix-platform.
Meerdere query's in één diagram
PREMIUM, ULTIEM, ZILVER, GOUD
In GitLab kunt u grafieken maken om de statistieken die u verzamelt te visualiseren. Als u bijvoorbeeld naar de maximale of gemiddelde waarde van een metriek moet kijken, wilt u vaak meerdere waarden in één diagram weergeven. Vanaf deze release heb je deze mogelijkheid.
We hebben Dynamic Application Security Testing (DAST)-resultaten toegevoegd aan het beveiligingsdashboard van het team, naast SAST, containerscans en afhankelijkheidsscans.
Metagegevens toevoegen aan een containerscanrapport
ULTIEM, GOUD
In deze release bevat het Container Scan Report meer metadata - we hebben toegevoegd getroffen onderdeel (een Clair-functie) in bestaande metadata: prioriteit, ID (met verwijzing naar mitre.org) en betrokken niveau (bijv. debian:8).
Een metrisch rapporttype toevoegen om verzoeken samen te voegen
PREMIUM, ULTIEM, ZILVER, GOUD
GitLab biedt al verschillende soorten rapporten die direct kunnen worden opgenomen in samenvoegverzoeken: van rapporten tot codekwaliteit и testen van een eenheid in de verificatiefase tot SAST и DAST in de beschermingsfase.
Hoewel dit belangrijke rapporten zijn, is er ook basisinformatie nodig die geschikt is voor verschillende scenario's. In GitLab 11.10 bieden we rapportage van statistieken rechtstreeks in het samenvoegverzoek, waarbij een eenvoudig sleutel-waardepaar wordt verwacht. Op deze manier kunnen gebruikers wijzigingen in de loop van de tijd volgen, inclusief aangepaste statistieken, en wijzigingen in statistieken voor een specifiek samenvoegverzoek. Geheugengebruik, gespecialiseerde werklasttests en gezondheidsstatussen kunnen worden omgezet in eenvoudige statistieken die direct kunnen worden bekeken in samenvoegverzoeken, samen met andere ingebouwde rapporten.
Ondersteuning voor Maven-projecten met meerdere modules voor het scannen van afhankelijkheid
ULTIEM, GOUD
Met deze release ondersteunen Maven-projecten met meerdere modules GitLab-afhankelijkheidsscans. Als een submodule voorheen afhankelijk was van een andere submodule van hetzelfde niveau, kon deze het laden vanuit de centrale Maven-repository niet toestaan. Nu wordt een Maven-project met meerdere modules gemaakt met twee modules en een afhankelijkheid tussen de twee modules. Afhankelijkheden tussen modules op hetzelfde niveau zijn nu beschikbaar in de lokale Maven-repository, zodat de build kan doorgaan.
Standaard kloont GitLab Runner het project naar een uniek subpad in $CI_BUILDS_DIR. Maar voor sommige projecten, zoals Golang, moet de code naar een specifieke map worden gekloond voordat deze kan worden gebouwd.
In GitLab 11.10 hebben we de variabele geïntroduceerd GIT_CLONE_PATH, waarmee u een specifiek pad kunt opgeven waar GitLab Runner het project kloont voordat de taak wordt uitgevoerd.
Eenvoudige maskering van beschermde variabelen in logboeken
GitLab biedt verschillende manieren beschermen и beperk het gebied variabelen in GitLab CI/CD. Maar variabelen kunnen nog steeds, opzettelijk of per ongeluk, in buildlogboeken terechtkomen.
GitLab neemt risicobeheer en auditing serieus en blijft compliance-functies toevoegen. In GitLab 11.10 hebben we de mogelijkheid geïntroduceerd om bepaalde soorten variabelen in taaktraceringslogboeken te maskeren, waardoor een beschermingsniveau wordt toegevoegd tegen het per ongeluk opnemen van de inhoud van deze variabelen in de logs. En nu GitLab automatisch maskeren veel ingebouwde tokenvariabelen.
Met Auto DevOps op een GitLab.com-project kunt u probleemloos moderne DevOps-workflows van build tot oplevering uitvoeren.
Vanaf GitLab 11.10 kunt u Auto DevOps in- of uitschakelen voor alle projecten in dezelfde groep.
Vereenvoudigde en verbeterde licentiepagina
STARTER, PREMIUM, ULTIEM
Om het beheer van licentiesleutels handiger en eenvoudiger te maken, hebben we de licentiepagina in het beheerdersdashboard opnieuw ontworpen en de belangrijkste elementen gemarkeerd.
Update de snelkoppelingskiezer voor Kubernetes-implementaties
Implementatiepanelen geven informatie weer over alle Kubernetes-implementaties.
In deze release hebben we de manier gewijzigd waarop we snelkoppelingen naar implementaties toewijzen. Wedstrijden zijn nu beschikbaar via app.example.com/app и app.example.com/env of app. Hierdoor worden filterconflicten en het risico van onjuiste implementaties in verband met het project vermeden.
Dankzij Kubernetes-integratie met GitLab kunt u de RBAC-functie gebruiken met behulp van een serviceaccount en een speciale naamruimte voor elk GitLab-project. Vanaf deze release worden deze bronnen voor maximale efficiëntie alleen aangemaakt als ze nodig zijn voor de implementatie.
Bij de implementatie van Kubernetes zal GitLab CI deze bronnen vóór de implementatie creëren.
Clusters op groepsniveau ondersteunen nu de installatie van GitLab Runner. Kubernetes-lopers op groepsniveau worden voor onderliggende projecten weergegeven als groepslopers met het label cluster и kubernetes.
Functies geïmplementeerd met GitLab serverloos, toont nu het aantal ontvangen oproepen voor een bepaalde functie. Om dit te doen, moet u Prometheus installeren op het cluster waarop Knative is geïnstalleerd.
Parametercontrole git clean voor GitLab CI/CD-taken
Standaard wordt GitLab Runner uitgevoerd git clean tijdens het proces van het uploaden van code bij het uitvoeren van een taak in GitLab CI/CD. Vanaf GitLab 11.10 kunnen gebruikers de parameters beheren die aan een team worden doorgegeven git clean. Dit is handig voor teams met toegewijde hardlopers, maar ook voor teams die projecten verzamelen uit grote monorepository's. Nu kunnen ze het ontlaadproces controleren voordat ze scripts uitvoeren. Nieuwe variabele GIT_CLEAN_FLAGS standaardwaarde is -ffdx en accepteert alle mogelijke opdrachtparameters [git clean](https://git-scm.com/docs/git-clean).
Voor beveiligde omgevingen is mogelijk een extra externe autorisatiebron nodig om toegang te krijgen tot het project. We hebben ondersteuning toegevoegd voor een extra niveau van toegangscontrole in 10.6 en ontving veel verzoeken om deze functionaliteit in Core te openen. We zijn blij dat we externe autorisatie en een extra beveiligingslaag voor Core-instanties kunnen introduceren, omdat deze functie nodig is voor individuele deelnemers.
Mogelijkheid om projecten in groepen te maken in Core
De rol Ontwikkelaar kan projecten in groepen maken sinds versie 10.5, en nu is dit mogelijk in Core. Het maken van projecten is een belangrijke functie voor de productiviteit in GitLab, en door deze functie in Core op te nemen, is het nu gemakkelijker voor bijvoorbeeld leden om iets nieuws te doen.
Vandaag hebben we GitLab Runner 11.10 uitgebracht! GitLab Runner is een open source-project dat wordt gebruikt om CI/CD-taken uit te voeren en de resultaten terug te sturen naar GitLab.
De volledige lijst met wijzigingen is te vinden in de GitLab Runner changelog: CHANGELOG.
Correctie van de geretourneerde project_id in de blob-zoek-API in Elasticsearch
STARTER, PREMIUM, ULTIEM
We hebben een bug opgelost in de Elasticsearch blob-zoek-API die ten onrechte 0 retourneerde voor project_id. Het zal nodig zijn Elasticsearch opnieuw indexerenom de juiste waarden te krijgen project_id na het installeren van deze versie van GitLab.
Omnibus-verbeteringen
CORE, STARTER, PREMIUM, ULTIEM
We hebben de volgende verbeteringen aangebracht in Omnibus in GitLab 11.10:
GitLab 11.10 bevat Matig 5.9.0, open source Slack-alternatief, waarvan de nieuwste release een nieuwe integratiedirectory bevat voor het eenvoudig migreren van gegevens uit Hipchat en nog veel meer. Deze versie bevat beveiligingsupdatesen we raden aan om te updaten.
GitLab Geo zal gehashte opslag bieden in GitLab 12.0
GitLab Geo vereist gehashte opslag om de concurrentie op secundaire knooppunten te verminderen. Dit werd opgemerkt in gitlab-ce#40970.
In GitLab 11.5 we hebben deze vereiste toegevoegd aan de Geo-documentatie: gitlab-ee#8053.
In GitLab 11.6sudo gitlab-rake gitlab:geo:check controleert of gehashte opslag is ingeschakeld en of alle projecten zijn gemigreerd. Cm. gitlab-ee#8289. Als u Geo gebruikt, voer dan deze controle uit en migreer zo snel mogelijk.
In GitLab 11.8 waarschuwing permanent uitgeschakeld gitlab-ee!8433 wordt op de pagina weergegeven Beheergebied > geo- > Nodes, als de bovenstaande controles niet zijn toegestaan.
In GitLab 12.0 Geo zal gehashte opslagvereisten gebruiken. Cm. gitlab-ee#8690.
Canonical kondigde het einde aan van de standaardondersteuning voor Ubuntu 14.04 2019-jaar april. Wij adviseren gebruikers om te upgraden naar een ondersteunde LTS-versie: Ubuntu 16.04 of Ubuntu 18.04.
Datum van verwijdering: 22 mei 2019 stad
Beperking van het maximale aantal pijplijnen dat per inzending wordt gemaakt
Voorheen maakte GitLab pijplijnen voor HEAD elke tak in de inzending. Dit is handig voor ontwikkelaars die meerdere wijzigingen tegelijk doorvoeren (bijvoorbeeld naar een feature branch en naar een branch). develop).
Maar wanneer u een grote opslagplaats met veel actieve vertakkingen pusht (bijvoorbeeld verplaatsen, spiegelen of vertakken), hoeft u niet voor elke vertakking een pijplijn te maken. Beginnend met GitLab 11.10 zijn we aan het creëren maximaal 4 leidingen bij het verzenden.
Datum van verwijdering: 22 mei 2019 stad
Verouderde oude codepaden van GitLab Runner
Vanaf Gitlab 11.9 gebruikt GitLab Runner nieuwe methode klonen/aanroepen van de repository. Momenteel gebruikt GitLab Runner de oude methode als de nieuwe niet wordt ondersteund. Zie meer details in deze opdracht.
In GitLab 11.0 hebben we het uiterlijk van de metrische serverconfiguratie voor GitLab Runner gewijzigd. metrics_server ten gunste zal worden verwijderd listen_address in GitLab 12.0. Zie meer details in deze opdracht.
In versie 11.3 begon GitLab Runner ondersteuning te bieden meerdere cacheproviders; wat leidde tot nieuwe instellingen voor specifieke S3-configuratie. In documentatie, biedt een tabel met wijzigingen en instructies voor het migreren naar de nieuwe configuratie. Zie meer details in deze opdracht.
Deze paden zullen niet beschikbaar zijn in GitLab 12.0. Als gebruiker hoef je niets anders te veranderen dan ervoor te zorgen dat je GitLab-instantie versie 11.9+ draait wanneer je upgradet naar GitLab Runner 12.0.
Datum van verwijdering: 22 2019 Juni, de
Verouderde parameter voor de toegangspuntfunctie voor GitLab Runner
In GitLab 12.0 schakelen we over naar het juiste gedrag alsof de functie-instelling is uitgeschakeld. Zie meer details in deze opdracht.
Datum van verwijdering: 22 2019 Juni, de
Verouderde ondersteuning voor Linux-distributie die EOL bereikt voor GitLab Runner
Sommige Linux-distributies waarop GitLab Runner kan worden geïnstalleerd, hebben hun doel gediend.
In GitLab 12.0 zal GitLab Runner niet langer pakketten distribueren naar dergelijke Linux-distributies. Een volledige lijst met distributies die niet langer worden ondersteund, vindt u in onze documentatie. Met dank aan Javier Ardo (Javier Jardon) achter zijn bijdrage!
Datum van verwijdering: 22 2019 Juni, de
Oude GitLab Runner Helper-opdrachten verwijderen
Als onderdeel van onze inspanningen om te ondersteunen Windows Docker-uitvoerder moest een aantal oude commando's opgeven die hiervoor worden gebruikt helper afbeelding.
Het oude git clean-mechanisme verwijderen uit GitLab Runner
In GitLab Runner 11.10 wij bieden de mogelijkheid configureren hoe Runner een opdracht uitvoert git clean. Bovendien elimineert de nieuwe opruimstrategie het gebruik git reset en plaatst het commando git clean na de losstap.
Omdat deze gedragsverandering van invloed kan zijn op sommige gebruikers, hebben we een parameter opgesteld FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Als u de waarde instelt true, zal het de oude opruimstrategie herstellen. Meer over het gebruik van functieparameters in GitLab Runner vindt u bij documentatie.
In GitLab Runner 12.0 verwijderen we de ondersteuning voor de verouderde opschoonstrategie en de mogelijkheid om deze te herstellen met behulp van een functieparameter. Zie meer details in deze opdracht.
Datum van verwijdering: 22 2019 Juni, de
Systeeminfo-sectie in het beheerderspaneel
GitLab presenteert informatie over uw GitLab-instantie in admin/system_info, maar deze informatie is mogelijk niet nauwkeurig.
Gratis: Onbeperkte privérepository's en een onbeperkt aantal projectbijdragers. Gesloten projecten hebben toegang tot niveaufuncties GratisHebben geopende projecten toegang hebben tot niveaufuncties Tijdloos goud.
Brons: voor teams die toegang nodig hebben tot geavanceerde workflowfuncties.
Zilver: Voor teams die robuustere DevOps-mogelijkheden, compliance en snellere ondersteuning nodig hebben.
Tijdloos goud: Geschikt voor veel CI/CD-taken. Alle open projecten kunnen gratis gebruikmaken van de Gold-functies, ongeacht het abonnement.