Release 13.4 mit HashiCorp-Speicher für CI-Variablen, Kubernetes-Agent und Sicherheitszentrale sowie umschaltbaren Funktionen in Starter ist erschienen.
Bei GitLab denken wir immer darüber nach, wie wir Nutzern helfen können, Risiken zu minimieren, die Effizienz zu steigern und die Lieferung auf Ihrer bevorzugten Plattform zu beschleunigen. In diesem Monat haben wir eine Reihe nützlicher Neuerungen hinzugefügt, die die Sicherheitsfunktionen erweitern, die Anzahl der Schwachstellen verringern, die Effizienz erhöhen und die Bedienung von GitLab erleichtern, damit Ihr Team Funktionen noch schneller liefern kann. Wir hoffen, dass die wichtigsten Funktionen des Releases sowie 53 weitere neue Funktionen, die in diesem Release hinzugefügt wurden.
Erweiterte Sicherheitsfunktionen
Wir bemühen uns, jeden Monat mehrere neue Funktionen zu GitLab DevSecOps hinzuzufügen, und dieses Release bildet da keine Ausnahme. im Rahmen von Build- und Deployment-Prozessen. Darüber hinaus können Organisationen, die das Trennungsprinzip für die Bereitstellung von Code unterstützen möchten, jetzt . Diese Rolle entspricht und ermöglicht es, Merge-Requests (in der deutschen GitLab-Lokalisierung als „Merge-Anfragen“ bezeichnet) zu bestätigen und Code in geschützten Umgebungen bereitzustellen, ohne dabei Zugriff auf den Code selbst zu gewähren.
Ein weiterer Weg, um Risiken zu minimieren, ist die Nutzung des neuen . Betriebsteams können Kubernetes-Cluster direkt aus GitLab bereitstellen, ohne den Zugang zu ihrem Cluster für das gesamte Internet zu öffnen. Zudem bieten wir automatisierte Unterstützung für die Versionskontrolle neuer Terraform-Zustandsdateien mit zur Unterstützung der Compliance-Anforderungen und zur Verbesserung der Debugging-Möglichkeiten. Schließlich hat sich das Sicherheits-Dashboard in der Instanz in ein mit Berichten zu Schwachstellen und Sicherheitskonfigurationen verwandelt.
Eine benutzerfreundlichere und effizientere Nutzung von GitLab
Wir haben unsere globale Suche verbessert, indem wir hinzugefügt haben, die einen einfachen Zugriff auf die neuesten Tickets, Gruppen, Projekte, Einstellungen und Hilfeseiten ermöglicht. Wir freuen uns, bekannt zu geben, dass in GitLab Pages für die Weiterleitung einzelner Seiten und Verzeichnisse innerhalb der Website, was es den Nutzern ermöglicht, ihre Websites effizienter zu gestalten. Für diejenigen, die umfassendere Informationen zur Bereitstellung wünschen, bietet dieses Release !
Open-Source-Engagements
Wir präsentieren , die hinzugefügt wurde von . Hinweise zur Codeabdeckung der geänderten Codes geben Entwicklern einen visuellen Überblick über die Abdeckung während der Überprüfung; diese Informationen helfen, die Überprüfung zu beschleunigen und die Zeit für das Mergen und Bereitstellen neuen Codes zu reduzieren. Außerdem haben wir und planen .
Und das ist erst der Anfang!
Wie immer gibt es im Überblick zu wenig Platz, und im Release 13.4 gibt es viele tolle Features. Hier sind noch einige:
- .
Wenn Sie im Voraus wissen möchten, was Sie erwartet in der nächsten Version, schauen Sie sich .
.
dieses Monats —
Fabio hat einen erheblichen in — eine Funktion, auf die die GitLab-Community lange gewartet hat. Dies ist ein wirklich bedeutender Beitrag mit nicht trivialen Änderungen, die ständige Zusammenarbeit mit den Mitgliedern des GitLab-Teams erforderten und viele Bereiche des Projekts betrafen, wie UX, Frontend und Backend.
Die Hauptfunktionen der GitLab Version 13.4
Verwenden Sie HashiCorp Vault-Schlüssel in CI-Jobs
(PREMIUM, ULTIMATE, SILVER, GOLD)
In der Version 12.10 hat GitLab die Möglichkeit eingeführt, Schlüssel in CI-Jobs mithilfe des GitLab-Runners zu erhalten und zu übergeben. Jetzt erweitern wir die , indem wir eine neue Syntax secrets in die Datei .gitlab-ci.yml. Dies wird die Einrichtung und Nutzung des HashiCorp-Speichers mit GitLab erleichtern.
und .
Präsentation des GitLab Kubernetes Agenten
(PREMIUM, ULTIMATE)
Die Integration von GitLab mit Kubernetes ermöglicht es seit langem, Anwendungen in Kubernetes-Clustern zu deployen, ohne dass eine manuelle Konfiguration erforderlich ist. Viele Benutzer schätzen die Benutzerfreundlichkeit dieser Kombination, während andere auf einige Herausforderungen gestoßen sind. Damit GitLab auf die aktuelle Integration zugreifen kann, muss Ihr Cluster aus dem Internet erreichbar sein. Für viele Organisationen ist dies aus Sicherheits-, Compliance- oder Regulierungsgründen nicht möglich, da der Zugriff auf die Cluster eingeschränkt wird. Um diese Einschränkungen zu umgehen, waren Benutzer gezwungen, eigene Tools auf GitLab-Basis zu entwickeln, da sie sonst diese Funktion nicht nutzen konnten.
Heute stellen wir den GitLab Kubernetes Agent vor – eine neue Methode zur Bereitstellung in Kubernetes-Clustern. Der Agent arbeitet innerhalb Ihres Clusters, sodass Sie es nicht für das gesamte Internet öffnen müssen. Der Agent koordiniert die Bereitstellung, indem er neue Änderungen von GitLab anfordert, anstatt dass GitLab Updates an das Cluster sendet. Egal, welche GitOps-Methode Sie verwenden, GitLab ist die richtige Wahl für Sie.
Bitte beachten Sie, dass dies die erste Version des Agents ist. Momentan liegt der Fokus des GitLab Kubernetes Agents auf der Konfiguration und Verwaltung der Bereitstellung über Code. Einige bestehende Funktionen der Kubernetes-Integration, wie Bereitstellungsboards und von GitLab verwaltete Anwendungen, werden derzeit noch nicht unterstützt. , dass diese Funktionen in zukünftigen Versionen des Agents hinzugefügt werden, sowie neue Integrationen, die sich auf Sicherheit und Compliance konzentrieren.
und .
Erteilen Sie Benutzern Berechtigungen zur Bereitstellung ohne Zugang zum Code.
(PREMIUM, ULTIMATE, SILVER, GOLD)
Früher bot das Berechtigungssystem in GitLab keine adäquate Möglichkeit, die Aufgaben in Ihrem Team zwischen denjenigen, die für die Entwicklung verantwortlich sind, und denen, die für die Bereitstellung zuständig sind, zu trennen. Mit der Veröffentlichung von GitLab 13.4 können Sie Personen, die keinen Code schreiben, die Genehmigung für das Bestätigen von Merge-Requests zur Bereitstellung sowie für die tatsächliche Bereitstellung von Code erteilen, ohne ihnen die Berechtigungen eines Maintainers (in der deutschen Lokalisierung von GitLab "Betreuer") zu gewähren.
und .
Sicherheitszentrale
(ULTIMATE, GOLD)
Früher war das Management von Sicherheitsanfälligkeiten auf Instanzebene sowohl in der Funktionalität als auch in der Flexibilität eingeschränkt. Die Benutzeroberfläche stellte eine einzige Seite dar, die die Details der Sicherheitsanfälligkeiten, Metrikdiagramme und Einstellungen vereinte. Es gab nicht viel Raum für die Weiterentwicklung dieser Funktionen oder die Nutzung anderer Sicherheitslösungen.
Wir haben grundlegende Änderungen im Sicherheitsmanagement und der Transparenz bei GitLab vorgenommen. Das Sicherheits-Dashboard der Instanz hat sich in ein vollwertiges Sicherheitszentrum verwandelt. Die größte Änderung ist die Einführung einer neuen Menüstruktur: Statt einer einzigen Seite sehen Sie jetzt getrennt das Sicherheits-Dashboard, den Bericht über Schwachstellen und den Einstellungsbereich. Obwohl die Funktionalität unverändert bleibt, ermöglicht die Aufteilung eine kontinuierliche Verbesserung dieses Bereichs, was vorher schwierig gewesen wäre. Dies schafft auch die Grundlage für die zukünftige Integration weiterer sicherheitsrelevanter Funktionen.
Der spezielle Abschnitt für den Sicherheitsbericht bietet jetzt mehr Platz, um wichtige Details anzuzeigen. Hier sind die Schwachstellen zusammengefasst, die derzeit in der Liste der Projektanfälligkeiten stehen. Das Verschieben der Widgets mit Schwachstellenmetriken in einen separaten Bereich schafft ein benutzerfreundliches Sicherheitsdashboard. Jetzt wird es zur Leinwand für zukünftige Visualisierungen – nicht nur für das Schwachstellenmanagement, sondern auch für alle sicherheitsrelevanten Metriken. Schließlich schafft ein separater Einstellungsbereich einen gemeinsamen Raum für alle Sicherheitskonfigurationen auf Instanzebene, nicht nur für das Schwachstellenmanagement.
und .
Optional verfügbare Funktionen jetzt in GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
In GitLab 11.4 wurde die In 12.2 haben wir für sie Strategien eingeführt und , und in 13.1 haben wir und für verschiedene Umgebungen hinzugefügt.
Früher in diesem Jahr hat GitLab sich verpflichtet, im Open Source. In dieser Version haben wir die Übertragung der schaltbaren Funktionen in den Starter-Plan abgeschlossen und werden diesen weiterhin ins Core übertragen. . Wir freuen uns, diese Möglichkeit einer größeren Anzahl von Nutzern zur Verfügung zu stellen und möchten erfahren, wie Sie diese nutzen werden.
und .
Schnelle Navigation über die Suchleiste
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Manchmal möchten Sie bei der Navigation in GitLab sofort zu einem bestimmten Projekt wechseln, anstatt auf die Suchergebnisseite zu gelangen.
Mit der globalen Suchleiste können Sie schnell zu den letzten Tickets, Gruppen, Projekten, Einstellungen und Hilfethemen navigieren. Sie können sogar die Tastenkombination /, verwenden, um den Cursor auf die Suchleiste zu setzen und noch effektiver durch GitLab zu navigieren!
und .
Anzeige der Codeabdeckung in den Diffs von Merge-Requests
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bei der Überprüfung von Merge-Requests kann es schwierig sein zu erkennen, ob der geänderte Code durch Unit-Tests abgedeckt ist. Stattdessen können Reviewer sich auf die allgemeine Abdeckung verlassen und deren Erhöhung verlangen, bevor sie den Merge-Request bestätigen. Dies kann zu einem planlosen Ansatz beim Schreiben von Tests führen, der die Codequalität oder dessen Testabdeckung tatsächlich nicht verbessert.
Jetzt sehen Sie beim Betrachten des Diff eines Merge-Requests eine anschauliche Darstellung der Code-Abdeckung. Neue Markierungen ermöglichen es Ihnen, schnell zu erkennen, ob der geänderte Code durch einen Unit-Test abgedeckt ist, was die Code-Überprüfung und die Zeit bis zum Merge sowie das Deployment neuen Codes beschleunigt.
Danke und Siemens für dieses Feature!
und .
Mehr Umgebungen und Projekte im Umgebungs-Dashboard
(PREMIUM, ULTIMATE, SILVER, GOLD)
Seit der Veröffentlichung von GitLab 12.5 können Sie mit den Status von Umgebungen verfolgen, allerdings nicht mehr als sieben Umgebungen in drei Projekten. Wir haben dieses Dashboard in der Version 13.4 verbessert, indem wir es in Seiten unterteilt haben, um Ihnen zu helfen, Ihre Umgebungen besser zu verwalten und in größerem Maßstab zu betreuen. Jetzt können Sie mehr Umgebungen in mehr Projekten sehen.
und .
GitLab hat die Verwaltung des GitLab Terraform Providers übernommen.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kürzlich haben wir und planen Im letzten Monat haben wir 21 Merge-Requests angenommen und 31 Tickets geschlossen, darunter einige lang bestehende Fehler und fehlende Funktionen wie Sie können in der Terraform-Dokumentation.
und .
Fuzzing-Tests für APIs mit OpenAPI-Spezifikationen oder HAR-Dateien.
(ULTIMATE, GOLD)
Fuzzing-Tests für APIs sind eine hervorragende Methode zur Erkennung von Fehlern und Sicherheitsanfälligkeiten in Ihren Webanwendungen und APIs, die von anderen Scannern und Testmethoden möglicherweise übersehen werden.
API-Fuzzing-Tests in GitLab ermöglichen es Ihnen, oder Ihres Programms bereitzustellen und anschließend automatisch zufällige Eingabewerte zu generieren, die dazu dienen, Grenzfälle zu überprüfen und Fehler zu finden. Die Ergebnisse werden sofort in Ihrem Pipeline angezeigt.
Dies ist unser erster Release für API-Fuzzing-Tests, und wir sind gespannt auf Ihr Feedback. Für Fuzzing-Tests haben wir noch , die wir auf der Veröffentlichung dieses Features basieren werden.
und .
Vorschau neuer Diagramme im Metrik-Dashboard
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Früher war das Erstellen eines Diagramms im Metrik-Dashboard von GitLab eine Herausforderung. Nachdem Sie eine Metrik in der YAML-Datei des Dashboards erstellt hatten, mussten Sie Änderungen in master, vornehmen, ohne überprüfen zu können, ob das neu erstellte Diagramm wie gewünscht funktionierte. Ab dieser Veröffentlichung können Sie Änderungen in Echtzeit beim Erstellen des Diagramms in der Vorschau anzeigen und erhalten Einblicke in das Ergebnis, bevor Sie die Änderungen in die YAML-Datei des Dashboards senden.
und .
Daten zur Testabdeckung des Codes für alle Projekte der Gruppe
(PREMIUM, ULTIMATE, SILVER, GOLD)
Wenn Sie eine große Anzahl von Projekten in GitLab verwalten, benötigen Sie eine zentrale Informationsquelle, um zu verfolgen, wie sich die Testabdeckung des Codes im Laufe der Zeit über alle Projekte hinweg verändert. Früher erforderte die Anzeige dieser Informationen mühsame manuelle Arbeit: Sie mussten die Daten zur Testabdeckung aus jedem Projekt herunterladen und in einer Tabelle zusammenführen.
In Version 13.4 wurde die Möglichkeit eingeführt, ganz einfach und schnell alle Daten zur Codeabdeckung in .csv zu exportieren, sowohl für alle Projekte der Gruppe als auch für eine Auswahl bestimmter Projekte. Dieses Feature ist MVC-basiert und wird von der Möglichkeit gefolgt, .
und .
Unterstützung neuer Sprachen für vollständige Fuzzing-Tests
(ULTIMATE, GOLD)
Dieser Release bringt die Unterstützung mehrerer neuer Sprachen für Fuzzing-Tests, die auf vollständige Abdeckung abzielen.
Nun können Sie alle Möglichkeiten des Fuzzing-Tests in Ihren Anwendungen auf Java, Rust und Swift bewerten und Fehler sowie Schwachstellen finden, die von anderen Scannern und Testmethoden möglicherweise übersehen werden.
und .
Benachrichtigungen auf der Hauptseite der Umgebungen
(PREMIUM, ULTIMATE, SILVER, GOLD)
Die Seite der Umgebungen zeigt den Gesamtstatus Ihrer Umgebungen an. In diesem Release haben wir diese Seite verbessert, indem wir die Anzeige von Benachrichtigungen hinzugefügt haben. Ausgelöste Benachrichtigungen zusammen mit dem Status Ihrer Umgebungen helfen Ihnen, schneller Maßnahmen zur Behebung von Problemen zu ergreifen.
und .
Eingebettete Pipelines können jetzt ihre eigenen eingebetteten Pipelines starten.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Durch die Verwendung von eingebetteten Pipelines ist es nun möglich, neue Pipelines innerhalb von untergeordneten Pipelines zu starten. Diese zusätzliche Tiefe kann nützlich sein, wenn Sie Flexibilität zur Generierung einer variablen Anzahl von Pipelines benötigen.
Früher benötigte jede untergeordnete Pipeline bei der Verwendung von eingebetteten Pipelines einen Auslöser, der manuell im übergeordneten Pipeline festgelegt wurde. Jetzt können Sie eingebettete Pipelines erstellen, die dynamisch eine beliebige Anzahl neuer eingebetteter Pipelines starten. Wenn Sie beispielsweise ein Monorepo haben, können Sie dynamisch die erste eingebettete Pipeline generieren, die selbst die erforderliche Anzahl neuer Pipelines basierend auf Änderungen im Branch erstellt.
und .
Verbesserte Navigation zwischen übergeordneten und eingebetteten Pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Früher war es nicht sehr komfortabel, zwischen übergeordneten und untergeordneten Pipelines zu wechseln – es waren viele Klicks nötig, um zur gewünschten Pipeline zu gelangen. Zudem war es schwierig zu erkennen, welches spezifische Job diese Pipeline ausgelöst hat. Jetzt wird es viel einfacher sein, die Zusammenhänge zwischen übergeordneten und untergeordneten Pipelines zu sehen.
und .
Parallele Matrixjobs zeigen die relevanten Variablen im Jobnamen an.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wenn Sie die verwendet haben, ist Ihnen vielleicht aufgefallen, dass es schwierig war zu erkennen, welche Matrixvariable für einen bestimmten Job verwendet wurde, da die Jobnamen wie matrix 1/4aussahen. In der Version 13.4 werden Sie relevante Werte der Variablen sehen, die in diesem Job verwendet wurden, anstatt des allgemeinen Jobnamens. Wenn Ihr Ziel beispielsweise Debugging für die x86-Architektur ist, wird der Job den Namen matrix: debug x86.
und .
Dokumentation zu parallelen Matrixjobs
Weitere Verbesserungen in GitLab 13.4
Verbindung des Atlassian-Kontos
DevOps-Zyklusphase: Manage und mit anderen Produkten aus der Atlassian-Reihe.
und .
Exportieren der Liste aller Merge-Commits
(ULTIMATE, GOLD)
Organisationen, die auf Compliance ausgerichtet sind, benötigen eine Möglichkeit, den Auditoren eine umfassende Übersicht über die Komponenten zu zeigen, die mit jeder spezifischen Änderung in der Produktionsumgebung verbunden sind. In GitLab bedeutet dies, dass alles an einem Ort zusammengeführt werden muss: Merge-Requests, Tickets, Pipelines, Sicherheits-Scans und andere Commitedaten. Bisher mussten Sie entweder diese Informationen manuell in GitLab sammeln oder Ihre eigenen Tools zur Informationsbeschaffung einrichten, was nicht sehr effizient war.
Jetzt können Sie diese Daten programmgesteuert sammeln und exportieren, um die Anforderungen an Audits zu erfüllen oder andere Analysen durchzuführen. Um die Liste aller Merge-Commits für die aktuelle Gruppe zu exportieren, müssen Sie zum gehen und auf die Schaltfläche klicken. Liste aller Merge-Commits. Die resultierende Datei enthält alle Commits des Merge-Requests, deren Autor, die ID des zugehörigen Merge-Requests, die Gruppe, das Projekt, Bestätigungen und weitere Informationen.
und .
Ausgeben von Listen und Verwalten von persönlichen Zugriffstoken über die API
(ULTIMATE, GOLD)
Die Verwaltung des Zugriffs auf den Namespace in GitLab ist ein wichtiger Bestandteil der Compliance. Von den Grundsätzen der minimalen Berechtigungen bis hin zur zeitgesteuerten Deaktivierung des Zugriffs gibt es mehrere Anforderungen in Bezug auf persönliche Zugriffstoken in GitLab. Um die Verwaltung aller dieser Benutzerdaten in Ihrem Namespace zu erleichtern, bieten wir die Möglichkeit, eine Liste aller persönlichen Zugriffstoken auszugeben und optional über die API.
Diese Verbesserungen der GitLab-API ermöglichen es den Nutzern, ihre eigenen persönlichen Zugriffstoken aufzulisten und zu widerrufen, während Administratoren die Token ihrer Benutzer auflisten und widerrufen können. Administratoren wird es jetzt leichter fallen, diejenigen zu sehen, die Zugriff auf ihren Namensraum haben, Zugriffsentscheidungen basierend auf Benutzerdaten zu treffen und persönliche Zugriffstoken, die möglicherweise kompromittiert wurden oder die Unternehmensrichtlinien zur Zugriffsverwaltung überschreiten, zu widerrufen.
und .
Verknüpfte Tickets und weitere Funktionen jetzt in GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vor einigen Monaten haben wir einen Plan angekündigt, Während wir daran arbeiten, dieses Versprechen zu erfüllen, haben wir , und (in der deutschen Lokalisierung von GitLab „Diskussionsboard“) im Core-Plan verfügbar. Dies gilt nur für Beziehungen vom Typ „verknüpft mit“, während Beziehungen vom Typ „blockiert“ und „blockiert von“ in kostenpflichtigen Plänen bleiben.
und .
Anzeige des ursprünglichen Branch-Namens in der Seitenleiste des Merge-Requests
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beim Überprüfen von Codeänderungen, Diskussionen und Commits eines Merge-Requests ist es oft sinnvoll, einen lokalen Checkout des Branches für eine eingehendere Überprüfung durchzuführen. Allerdings wird es immer schwieriger, den Branch-Namen zu finden, je mehr Inhalte zur Beschreibung des Merge-Requests hinzugefügt werden, sodass man weiter durch die Seite blättern muss.
Wir haben den Branch-Namen in die Seitenleiste des Merge-Requests eingefügt, sodass er jederzeit verfügbar ist und das Durchblättern der gesamten Seite entfällt. Wie der Link zum Merge-Request enthält der Abschnitt mit dem ursprünglichen Branch eine praktische „Kopieren“-Schaltfläche.
Danke für seinen enormen Beitrag zur Entwicklung dieser Funktion!
und .
Hinweis auf das Vorhandensein von zusammengeklappten Dateien in den Diffs des Merge-Requests
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Mergerequests, die Änderungen an mehreren Dateien hinzufügen, falten manchmal die Diffs großer Dateien, um die Anzeigeleistung zu verbessern. Wenn das passiert, kann es passieren, dass eine Datei bei der Überprüfung versehentlich übersprungen wird, insbesondere bei Mergerequests mit vielen Dateien. Ab Version 13.4 werden Mergerequests Diffs markieren, die gefaltete Dateien enthalten, sodass Sie diese Dateien während der Codeüberprüfung nicht übersehen. Für noch mehr Klarheit planen wir, in einem zukünftigen Release eine Hervorhebung dieser Dateien hinzuzufügen. Bleiben Sie über Aktualisierungen informiert in .
und .
Hinweis auf gefaltete Dateien im Diff eines Mergerequests
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Im Abschnitt mit den Diffs der Mergerequests werden große Dateien zur Verbesserung der Leistung gefaltet. Bei der Überprüfung von Code können jedoch einige Dateien übersehen werden, wenn der Prüfer die Dateiliste durchgeht, da alle großen Dateien gefaltet sind.
Wir haben eine sichtbare Warnung oben auf der Seite des Merge-Request-Diffs hinzugefügt, um die Benutzer darüber zu informieren, dass in diesem Bereich eine ausgeblendete Datei vorhanden ist. So verpassen Sie keine Änderungen im Merge-Request während der Überprüfung.
und .
Automatische Wiederherstellung des Gitaly-Cluster-Repositorys
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Früher, wenn der primäre Knoten des Gitaly-Clusters offline ging, wurden die Repositories auf diesem Knoten als nur lesbar gekennzeichnet. Dies verhinderte den Datenverlust in Situationen, in denen auf dem Knoten Änderungen vorgenommen wurden, die noch nicht repliziert waren. Wenn der Knoten wieder verbunden wurde, startete GitLab nicht automatisch und die Administratoren mussten den Synchronisierungsprozess manuell starten oder mit Datenverlust leben. Auch andere Situationen, wie ein fehlerhaftes Ende eines Replikationsauftrags auf einem sekundären Knoten, konnten dazu führen, dass Repositories als veraltet oder nur lesbar gekennzeichnet wurden. In diesem Fall blieb das Repository veraltet, bis die nächste Schreiboperation durchgeführt wurde, die den Replikationsauftrag auslöste.
Um dieses Problem zu lösen Jetzt plant die Aufgabe zur Replikation, wenn ein veraltetes Repository auf einem Knoten und die neueste Version des Repositories auf einem anderen entdeckt wird. Diese Replikationsaufgabe hält das Repository automatisch aktuell, was die manuelle Wiederherstellung von Daten überflüssig macht. Die automatische Wiederherstellung sorgt auch für ein schnelles Aktualisieren der sekundären Knoten, falls die Replikationsaufgabe fehlschlägt, anstatt auf die nächste Schreiboperation zu warten. Da viele Gitaly-Cluster eine große Anzahl von Repositories speichern, reduziert dies erheblich die Zeit, die Administratoren und Ingenieure für die Wiederherstellung von Daten nach einem Fehler aufwenden.
Darüber hinaus startet die automatische Reparatur die Replikation von Repositories auf jedem neuen Gitaly-Knoten, der dem Cluster hinzugefügt wird, was die manuelle Arbeit beim Hinzufügen neuer Knoten überflüssig macht.
und .
Markieren Sie die To-Do-Aufgabe als erledigt auf der Design-Seite.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Effektive Kommunikation in GitLab basiert auf To-Do-Listen. Wenn Sie in einem Kommentar erwähnt werden, ist es entscheidend, die Möglichkeit zu haben, zu der Aufgabe zu navigieren und entweder etwas zu tun oder sie als erledigt zu markieren. Ebenso wichtig ist es, die Aufgabe sich selbst zuzuweisen, wenn Sie an etwas arbeiten oder später darauf zurückkommen möchten.
Zuvor konnten Sie bei der Arbeit mit Designs keine Aufgaben hinzufügen oder als erledigt markieren. Dies hat die Effizienz der Kommunikation zwischen den Produktteams erheblich beeinträchtigt, da To-Do-Aufgaben ein kritischer Bestandteil des Arbeitsprozesses in GitLab sind.
Mit dem Release 13.4 holen Designs bei den Kommentaren zu Tickets im Hinblick auf die Nutzung von Aufgaben auf, was die Arbeit mit ihnen konsistenter und effizienter macht.
und .
Verbessertes Troubleshooting-Handbuch für CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wir haben das Troubleshooting-Handbuch für GitLab CI/CD verbessert, indem wir zusätzliche Informationen zu häufigen Problemen hinzugefügt haben, mit denen Sie möglicherweise konfrontiert werden. Wir hoffen, dass die verbesserte Dokumentation eine wertvolle Ressource ist, die Ihnen hilft, GitLab CI/CD schnell und einfach einzurichten und zu nutzen.
und .
Merge-Requests fallen nicht mehr aus der Merge-Warteschlange
(PREMIUM, ULTIMATE, SILVER, GOLD)
Früher konnten Merge-Requests zufällig aus der Merge-Warteschlange fallen, wenn späte Kommentare hinzugefügt wurden. Wenn ein Merge-Request bereits in der Warteschlange war und jemand einen Kommentar hinzufügte, der eine neue ungelöste Diskussion auslöste, wurde der Merge-Request als nicht geeignet zum Mergen betrachtet und fiel aus der Warteschlange. Jetzt können neue Kommentare hinzugefügt werden, ohne dass das Mergen des bereits in der Warteschlange befindlichen Merge-Requests beeinträchtigt wird.
und .
Anzeige des Code-Coverage-Werts im Merge-Request für das Job
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Entwickler sollten in der Lage sein, den Codeabdeckungswert nach Abschluss des Workflows zu sehen – selbst in komplexen Szenarien, wie etwa bei Workflows mit mehreren Aufgaben, die geparst werden müssen, um den Abdeckungswert zu berechnen. Früher zeigte das Merge-Request-Widget nur den Durchschnittswert dieser Werte, was bedeutete, dass man zur Aufgabenseite wechseln und dann zurück zum Merge-Request gehen musste, um die Zwischenwerte der Abdeckung zu erhalten. Um Ihnen Zeit zu sparen und diese unnötigen Schritte zu vermeiden, haben wir im Widget die Anzeige des Durchschnitts der Abdeckung, deren Änderung zwischen Ziel- und Quellzweigen sowie ein Tooltip eingeführt, das den Abdeckungswert für jede Aufgabe zeigt, auf deren Basis der Durchschnittswert berechnet wurde.
und .
Entfernen von Paketen aus dem Paket-Repository beim Ansehen der Gruppe
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Das GitLab-Paketregister ist der Ort, an dem Pakete in verschiedenen Formaten gespeichert und verteilt werden. Wenn Ihr Projekt oder Ihre Gruppe viele Pakete enthält, müssen Sie ungenutzte Pakete schnell identifizieren und löschen, damit diese nicht heruntergeladen werden. Sie können Pakete über oder über die Benutzeroberfläche des Paketregisters löschen. Bisher war es jedoch nicht möglich, Pakete beim Durchsehen der Gruppe über die Benutzeroberfläche zu löschen. Daher mussten Sie zusätzliche Pakete einzeln für jedes Projekt entfernen, was ineffizient war.
Jetzt können Sie Pakete direkt beim Durchsehen des Gruppen-Paketregisters löschen. Gehen Sie einfach zur Seite des Gruppen-Paketregisters, filtern Sie die Pakete nach Name und entfernen Sie alle unnötigen.
und .
Skalierung von Conan-Paketen auf Projektebene
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sie können das Conan-Repository in GitLab zur Veröffentlichung und Verbreitung von C/C++-Abhängigkeiten nutzen. Früher konnten Pakete jedoch nur bis zur Instanz-Ebene skaliert werden, da der Paketname von Conan maximal 51 Zeichen lang sein durfte. Wenn Sie ein Paket aus einer Untergruppe veröffentlichen wollten, wie zum Beispiel gitlab-org/ci-cd/package-stage/feature-testing/conan, war das nahezu unmöglich.
Jetzt können Sie Conan-Pakete bis zur Projektebene skalieren, was die Veröffentlichung und Verbreitung der Abhängigkeiten Ihrer Projekte erheblich erleichtert.
und .
Unterstützung neuer Paketmanager und Sprachen für die Abhängigkeitsscans
(ULTIMATE, GOLD)
Wir freuen uns, Abhängigkeitsscans für Projekte mit Code in C, C++, C# und .Net, die NuGet 4.9+ oder den Paketmanager Conan verwenden, zu unserer Liste . Jetzt können Sie das Scannen von Abhängigkeiten als Teil der Secure-Phase aktivieren, um bekannte Schwachstellen in über Paketmanager hinzugefügten Abhängigkeiten zu überprüfen. Die gefundenen Schwachstellen werden in Ihrem Merge-Request angezeigt, zusammen mit ihrem Gefährdungsgrad, damit Sie vor der Durchführung des Mergers wissen, welche Risiken neue Abhängigkeiten mit sich bringen. Sie können Ihr Projekt auch so konfigurieren, dass es eine für Abhängigkeiten mit kritischen (Critical), hohen (High) oder unbekannten (Unknown) Gefährdungsgraden erfordert.
und .
Benachrichtigungen bei Änderung der Merge-Request-Einstellung auf 'Merge bei erfolgreichem Abschluss des Pipelines'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Früher, bei Festlegung der Merge-Request-Einstellung Merge, wenn Pipeline abgeschlossen ist (Merge When Pipeline Succeeds, MWPS) wurde keine E-Mail-Benachrichtigung gesendet. Sie mussten den Status manuell überprüfen oder auf eine Benachrichtigung über den Merge warten. In diesem Release freuen wir uns, den Benutzerbeitrag , der dieses Problem gelöst hat, indem er die automatische Benachrichtigung aller, die sich für den Merge-Request angemeldet haben, aktiviert hat, wenn der Reviewer die Merge-Einstellungen auf MWPS ändert.
und .
Erstellen von EKS-Clustern mit einer benutzerspezifizierten Kubernetes-Version
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab-Nutzer können jetzt selbst die Kubernetes-Version auswählen, die für EKS bereitgestellt wird; Sie können zwischen den Versionen 1.14–1.17 wählen.
und .
Erstellen von Incidents als Tickettypen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nicht jedes auftretende Problem löst sofort eine Benachrichtigung aus: Nutzer berichten über Störungen, während Teammitglieder Leistungsprobleme untersuchen. Jetzt sind Incidents eine Art Ticket, sodass Ihre Teams diese schnell im Rahmen ihres gewohnten Arbeitsablaufs erstellen können. Klicken Sie Neue Aufgabe von überall in GitLab aus, und im Feld Typ wählen Sie Incident.
und .
GitLab-Benachrichtigungen in Markdown erwähnen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wir haben die GitLab-Benachrichtigungen verbessert, indem wir einen neuen Erwähnungstyp speziell für diese in der GitLab-Version von Markdown hinzugefügt haben, der das Teilen von Benachrichtigungen und deren Erwähnung erleichtert. Nutzen Sie ^alert#1234, um die Benachrichtigung in jedem Feld mit Markdown-Marking zu erwähnen: in Vorfällen, Tickets oder Merge-Anfragen. Das hilft Ihnen auch, Aufgaben zu identifizieren, die aus Benachrichtigungen und nicht aus Tickets oder Merge-Anfragen entstehen.
und .
Überblick über die Belastung von Benachrichtigungen zu Vorfällen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Die Beschreibung der Benachrichtigung enthält Informationen, die für die Diagnose von Ausfällen und die Wiederherstellung entscheidend sind, und diese Informationen sollten leicht zugänglich sein, damit Sie beim Arbeiten an der Lösung eines Vorfalls nicht zwischen Werkzeugen oder Tabs wechseln müssen. Vorfälle, die aus Benachrichtigungen erstellt wurden, zeigen die vollständige Beschreibung der Benachrichtigung im Tab Alert Details.
Um 75 % schnellere erweiterte Suche
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab hat als einheitliche Anwendung die einzigartige Möglichkeit, die Suche nach Inhalten über den gesamten DevOps-Arbeitsablauf hinweg zügig zu gestalten. In GitLab 13.4 liefert die erweiterte Suche Ergebnisse 75 % schneller, wenn sie , wie auf GitLab.com.
und .
Ansicht von entfernten Projekten für Administratoren
Verbindung des Atlassian-Kontos
Die Möglichkeit, die Löschung eines Projektes zu verschieben, wurde . Früher gab es jedoch keine Möglichkeit, alle Projekte, die auf die Löschung warten, an einem Ort zu sehen. Jetzt können Administratoren von benutzerdefinierten GitLab-Instanzen alle wartenden Projekte an einem Ort einsehen – zusammen mit Schaltflächen für eine einfache Wiederherstellung dieser Projekte.
Diese Funktion ermöglicht es Administratoren, die Löschung von Projekten besser zu kontrollieren, indem alle notwendigen Informationen an einem Ort gesammelt werden und die Möglichkeit geboten wird, unerwünschte Löschaktionen rückgängig zu machen.
Danke für dieses Feature!
und .
Die API hat Unterstützung für Push-Regeln für Gruppen hinzugefügt.
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Früher konnten Gruppenrichtlinien für Push-Nachrichten nur durch den individuellen Zugriff auf jede Gruppe über die Benutzeroberfläche von GitLab eingerichtet werden. Jetzt können Sie diese Regeln über die API verwalten, um Ihre benutzerdefinierten Tools und die Automatisierung von GitLab zu unterstützen.
und .
Widerruf von persönlichen Zugriffstoken für selbstverwaltete Credential-Storage
(ULTIMATIV)
stellt Administratoren die notwendigen Informationen zur Verfügung, um die Anmeldeinformationen der Benutzer ihrer GitLab-Instanz zu verwalten. Da compliance-orientierte Organisationen in Bezug auf ihre Richtlinien zur Verwaltung von Anmeldeinformationen unterschiedlich streng sind, haben wir eine Schaltfläche hinzugefügt, die es Administratoren ermöglicht, auf Wunsch das persönliche Zugriffstoken des Benutzers (PAT) zu widerrufen. Jetzt können Administratoren potenziell kompromittierte PATs einfach widerrufen. Diese Funktion ist nützlich für Organisationen, die flexiblere Optionen benötigen, um die Einhaltung von Anforderungen sicherzustellen und die Ablenkung ihrer Benutzer zu minimieren.
und .
Konfigurationsdatei für den statischen Site-Editor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 13.4 stellen wir eine neue Möglichkeit vor, den statischen Site-Editor zu konfigurieren. Obwohl die Konfigurationsdatei in dieser Version keine Parameter speichert oder erhält, legen wir den Grundstein für die zukünftige Anpassung des Verhaltens des Editors. In den kommenden Versionen werden wir dem Datei .gitlab/static-site-editor.yml Parameter zur Festlegung , auf der , sowie die Anpassung von Markdown-Syntax und weiteren Einstellungen des Editors.
und .
Bearbeiten des Einleitungsteils der Datei mit dem statischen Site-Editor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Der Header (Front Matter) ist eine flexible und benutzerfreundliche Methode zur Definition von Seitenvariablen in Datendateien, die für den statischen Website-Generator bestimmt sind. Er wird typischerweise verwendet, um den Seitentitel, das Layout-Template oder den Autor festzulegen, kann jedoch auch zur Übertragung jeglicher Art von Metadaten an den Generator beim Rendern der Seite in HTML dienen. An oberster Stelle jeder Datendatei formatiert, wird der Header üblicherweise in YAML oder JSON geschrieben und erfordert eine konsistente und präzise Syntax. Benutzer, die mit den spezifischen Syntaxregeln nicht vertraut sind, könnten unbeabsichtigt ungültige Markups eingeben, was wiederum Formatierungsprobleme oder sogar Build-Fehler verursachen kann.
Der WYSIWYG-Editor für statische Webseiten entfernt bereits den Einleitungsteil des Editors, um Formatierungsfehler zu vermeiden. Allerdings erlaubt dies nicht, die dort gespeicherten Werte zu ändern, ohne zum Quellcode-Editor zurückzukehren. In GitLab 13.4 können Sie auf jedes Feld zugreifen und dessen Wert in einer vertrauten, formularbasierten Benutzeroberfläche bearbeiten. Mit einem Klick auf den Button Einstellungen (Einstellungen) öffnet sich ein Panel, das ein Eingabefeld für jeden Schlüssel anzeigt, der zu Beginn definiert wurde. Die Felder sind mit dem aktuellen Wert gefüllt, und um eines davon zu bearbeiten, müssen Sie lediglich den Wert im Webformular eingeben. Diese Bearbeitung des Einleitungsteils ermöglicht es, Syntaxprobleme zu vermeiden und gibt Ihnen vollständige Kontrolle über den Inhalt, während gleichzeitig eine konsistente Formatierung des Endergebnisses gewährleistet wird.
und .
GitLab für Jira und DVCS Connector jetzt im Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Für Jira-Nutzer in GitLab: und zeigen Informationen zu Commits und Merge-Requests von GitLab direkt in Jira an. In Kombination mit unserer integrierten Jira-Integration können Sie während der Arbeit problemlos zwischen den beiden Anwendungen wechseln.
Diese Funktionen waren früher nur in unserem Premium-Plan verfügbar, sind jetzt jedoch für alle Benutzer zugänglich!
und .
Mehrheitliche Abstimmung für Gitaly-Cluster-Transaktionen (Beta-Version)
Verbindung des Atlassian-Kontos
Der Gitaly-Cluster ermöglicht die Replikation von Git-Repositories auf mehrere "warme" Gitaly-Nodes. Dies erhöht die Fehlertoleranz, indem einzelne Fehlerquellen beseitigt werden. , eingeführt in GitLab 13.3, initiieren eine Broadcast-Übertragung von Änderungen an alle Gitaly-Nodes im Cluster, aber nur die Gitaly-Nodes, die mit der primären Node übereinstimmen, speichern die Änderungen auf der Festplatte. Wenn sich alle Replikatsknoten nicht einigen, wird nur eine Kopie der Änderung auf der Festplatte gespeichert, wodurch ein einzelner Fehlerpunkt bis zum Abschluss der asynchronen Replikation entsteht.
Eine Abstimmung mit Mehrheitsbeschluss erhöht die Ausfallsicherheit, indem sie die Zustimmung der Mehrheit der Knoten (nicht aller) vor dem Speichern von Änderungen auf der Festplatte erfordert. Wenn diese optional verfügbare Funktion aktiviert ist, müssen die Aufzeichnungen erfolgreich auf mehreren Knoten erfolgen. Nicht übereinstimmende Knoten synchronisieren sich automatisch über asynchrone Replikation mit den Knoten, die das Quorum gebildet haben.
und .
Unterstützung für benutzerdefinierte Schemata zur Validierung von JSON im Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Projekte, in denen Personen Konfigurationen im JSON- oder YAML-Format schreiben, sind oft anfällig für Probleme, weil es leicht ist, einen Tippfehler zu machen und etwas zu beschädigen. Es können Prüfwerkzeuge entwickelt werden, die diese Probleme in der CI-Pipeline aufspüren, aber die Verwendung einer JSON-Schemadatei kann hilfreich sein, um Dokumentation und Hinweise bereitzustellen.
Projektmitglieder können in ihrem Repository den Pfad zur benutzerdefinierten Schema-Datei im .gitlab/.gitlab-webide.yml, der das Schema und den Pfad zu den zu prüfenden Dateien angibt. Beim Hochladen einer bestimmten Datei in das Web IDE wird zusätzliches Feedback und eine Überprüfung angezeigt, die beim Erstellen der Datei helfen.
und .
Das Limit für die Verzweigung von gerichteten azyklischen Graphen (DAG) wurde auf 50 erhöht
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wenn Sie Pipelines verwenden (Directed Acyclic Graph (DAG)), haben Sie möglicherweise festgestellt, dass das Limit von 10 Jobs, die ein Job in needs:, angeben kann, zu streng ist. In Version 13.4 wurde das Standardlimit von 10 auf 50 erhöht, um komplexere Netzwerke von Abhängigkeiten zwischen den Jobs in Ihren Pipelines zu ermöglichen.
Wenn Sie Administrator einer benutzerdefinierten GitLab-Instanz sind, können Sie dieses Limit sogar noch weiter erhöhen, indem Sie eine umschaltbare Funktion aktivieren, obwohl wir dafür keinen offiziellen Support anbieten.
und .
Verbessertes Verhalten von needs bei übersprungenen Jobs
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In einigen Fällen könnte ein übersprungener Job in einer Pipeline fälschlicherweise als erfolgreich für die Abhängigkeiten, die in von needs, angegeben sind, angesehen werden, was dazu führt, dass nachfolgende Jobs gestartet werden, was nicht geschehen sollte. Dieses Verhalten wurde in Version 13.4 behoben, und von needs nun werden Fälle von übersprungenen Jobs korrekt behandelt.
und .
Sichern Sie das letzte Artefakt des Jobs, um dessen Löschung zu verhindern
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab sperrt jetzt automatisch das letzte Artefakt eines erfolgreichen Jobs und Pipelines in jedem aktiven Branch, Merge-Request oder Tag, um dessen Löschung nach Ablauf der Frist zu verhindern. Es ist einfacher geworden, aggressivere Ablaufregeln für die Bereinigung alter Artefakte festzulegen. Dies hilft, den Speicherplatzverbrauch zu reduzieren und sicherzustellen, dass Sie immer eine Kopie des letzten Artefakts aus der Pipeline haben.
und .
Leitfaden zur Optimierung der CI/CD-Pipeline
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Die Optimierung der CI/CD-Pipeline kann die Liefergeschwindigkeit erhöhen und Kosten sparen. Wir haben unsere Dokumentation verbessert, indem wir einen kurzen Leitfaden zur Maximierung der Effizienz Ihrer Pipelines hinzugefügt haben.
und .
Der Testbericht ist nach Teststatus sortiert
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— ist eine einfache Möglichkeit, die Ergebnisse aller Tests in der Pipeline zu sehen. Bei einer großen Anzahl von Tests kann es jedoch viel Zeit in Anspruch nehmen, fehlgeschlagene Tests zu finden. Weitere Probleme, die die Verwendung des Berichts erschweren können, sind Schwierigkeiten beim Scrollen durch lange Trace-Ausgaben und die Rundung der Zeit auf null für Tests, die weniger als 1 Sekunde dauern. Ab sofort platziert der Testbericht bei der Sortierung standardmäßig fehlgeschlagene Tests am Anfang des Berichts und sortiert danach die Tests nach Dauer. Das vereinfacht die Suche nach Fehlern und lang laufenden Tests. Zudem wird die Dauer der Tests jetzt in Millisekunden oder Sekunden angezeigt, was die Lesbarkeit erheblich verbessert, und frühere Probleme mit dem Scrollen wurden ebenfalls behoben.
und .
Dateigrößenbeschränkungen für Dateien, die im Paketregister hochgeladen werden
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Jetzt gibt es Beschränkungen für die Dateigröße von Paketen, die im GitLab-Paket-Repository hochgeladen werden können. Diese Beschränkungen wurden eingeführt, um die Leistung des Paket-Repositorys zu optimieren und Missbrauch zu verhindern. Die Beschränkungen hängen vom Paketformat ab. Für GitLab.com gelten folgende maximale Dateigrößen:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Für benutzerdefinierte GitLab-Instanzen sind die Standardwerte gleich. Der Administrator kann die Beschränkungen jedoch über die .
und .
Verwenden Sie CI_JOB_TOKEN zur Veröffentlichung von PyPI-Paketen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sie können das GitLab-PyPI-Repository verwenden, um Python-Pakete zusammen mit dem Quellcode und CI/CD-Pipelines zu erstellen, zu veröffentlichen und gemeinsam zu nutzen. Zuvor konnten Sie sich jedoch nicht mit einer vordefinierten Umgebungsvariable im Repository authentifizieren. CI_JOB_TOKEN. Daher mussten Sie Ihre persönlichen Anmeldeinformationen verwenden, um das PyPI-Repository zu aktualisieren, oder Sie haben möglicherweise beschlossen, das Repository überhaupt nicht zu verwenden.
Jetzt ist es einfacher, GitLab CI/CD zur Veröffentlichung und Installation von PyPI-Paketen mit einer vordefinierten Umgebungsvariablen zu verwenden. CI_JOB_TOKEN.
und .
DAST-Scannerprofile auf Anfrage.
(ULTIMATE, GOLD)
Zu den DAST-Scans auf Anfrage, die eingeführt wurden, , wurden DAST-Scannerprofile hinzugefügt. Diese erweitern die Konfigurationsmöglichkeiten dieses Scans und ermöglichen es, schnell mehrere Profile zu erstellen, um verschiedene Scan-Typen abzudecken. In Version 13.4 enthält das Scannerprofil ursprünglich einen Timeout-Parameter für den Spider, der festlegt, wie lange der DAST-Scanner laufen soll, während er versucht, alle Seiten der gescannten Website zu entdecken. Das Profil umfasst auch einen Timeout-Parameter für die Zielwebsite, um festzulegen, wie lange der Scanner warten soll, bis die Website verfügbar ist, bevor das Scannen abgebrochen wird, wenn die Website keinen Statuscode 200 oder 300 zurückgibt. Während wir diese Funktion in zukünftigen Versionen weiter verbessern werden, werden dem Scannerprofil zusätzliche Konfigurationsparameter hinzugefügt.
und .
Einfache Konfigurationsdatei für Redirects in GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wenn Sie GitLab Pages nutzen und die URL-Änderungen besser verwalten möchten, haben Sie möglicherweise festgestellt, dass es unmöglich war, Redirects auf Ihrer GitLab Pages-Website zu verwalten. GitLab ermöglicht es Ihnen jetzt, Regeln für die Weiterleitung einer URL zu einer anderen für Ihre Pages-Website zu konfigurieren, indem Sie eine Konfigurationsdatei in das Repository hinzufügen. Diese Funktion wurde durch die Beteiligung von Kevin Barnett (), unserem Eric Eastwood () und dem GitLab-Team möglich gemacht. Vielen Dank an alle für Ihren Beitrag.
und .
Zustand von Terraform, verwaltet durch GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Der Zugriff auf frühere Versionen des Terraform-Zustands ist sowohl für die Einhaltung von Anforderungen als auch für die Fehlersuche erforderlich. Die Unterstützung für die Versionierung des von GitLab verwalteten Terraform-Zustands ist ab GitLab 13.4 verfügbar. Die Versionierung wird automatisiert für neue Terraform-Zustandsdateien aktiviert. Bestehende Terraform-Zustandsdateien werden in einer späteren Version.
und .
Wichtige Details zu Incident-Benachrichtigungen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bei der Bearbeitung von Vorfällen müssen Sie leicht erkennen können, wie lange eine Warnung geöffnet war und wie oft ein Ereignis ausgelöst wurde. Diese Details sind oft entscheidend, um die Auswirkungen auf den Kunden zu bestimmen und festzulegen, worauf Ihr Team sich zuerst konzentrieren sollte. Auf dem neuen Vorfall-Detail-Dashboard zeigen wir die Startzeit der Warnung, die Anzahl der Ereignisse und einen Link zur ursprünglichen Warnung an. Diese Informationen sind für Vorfälle verfügbar, die aus Warnungen erstellt wurden.
und .
Einrichtung und Bearbeitung des Schweregrads eines Vorfalls
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Der Parameter „Schweregrad eines Vorfalls“ ermöglicht es den Reaktionsteams und Interessengruppen, die Auswirkungen von Betriebsunterbrechungen sowie die Reaktionsmethoden und die Dringlichkeit zu bestimmen. Während Ihr Team während der Störungsbehebung Informationen austauscht und die Betriebsbereitschaft wiederherstellt, kann es diesen Parameter anpassen. Jetzt können Sie den Schweregrad des Vorfalls im rechten Bereich der Seite „Vorfallinformationen“ bearbeiten, und der Schweregrad wird in der Vorfallliste angezeigt.
und .
Erstellen, Bearbeiten und Löschen von Netzwerksicherheitsregeln für Container
(ULTIMATE, GOLD)
Dieses Upgrade des Editors für Netzwerksicherheitsregeln für Container ermöglicht es Benutzern, ihre Regeln direkt über die Benutzeroberfläche von GitLab einfach zu erstellen, zu bearbeiten und zu löschen. Die Funktionen des Editors umfassen den Modus .yaml für erfahrene Benutzer und einen regelbasierten Editor mit einer intuitiven Benutzeroberfläche für diejenigen, die mit Netzwerksicherheitsregeln weniger vertraut sind. Neue Möglichkeiten zur Verwaltung von Regeln finden Sie unter Sicherheit und Compliance > Bedrohungsmanagement > Richtlinien (Security & Compliance > Threat Management > Policies).
und .
Unterstützung für Azure Blob Storage
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sowohl GitLab als auch GitLab Runner unterstützen jetzt , was das Starten von GitLab-Diensten in Azure erleichtert.
GitLab-Instanzen unterstützen Azure für alle Arten von Objektspeichern, einschließlich LFS-Dateien, CI-Artefakten und . Um Azure Blob Storage zu konfigurieren, folgen Sie den Installationsanweisungen für oder .
GitLab-Jobhandler unterstützen ebenfalls Azure für die Speicherung Das Azure-Speicher kann über den Abschnitt .
und .
Omnibus ARM64-Pakete für Ubuntu und OpenSUSE
Verbindung des Atlassian-Kontos
Als Antwort auf die steigende Nachfrage nach Unterstützung für den Start von GitLab auf der 64-Bit-ARM-Architektur freuen wir uns, die Verfügbarkeit des offiziellen ARM64 Omnibus-Pakets für Ubuntu 20.04 bekannt zu geben. Ein großes Dankeschön an Zitai Chen und Guillaume Gardet für ihren erheblichen Beitrag – ihre Merge-Requests haben eine entscheidende Rolle gespielt!
Um das Paket für Ubuntu 20.04 herunterzuladen und zu installieren, besuchen Sie bitte unsere und wählen Sie Ubuntu.
und .
Unterstützung der Authentifizierung mit Smartcards für GitLab Helm-Chart
(PREMIUM, ULTIMATE)
Smartcards, wie z.B. Common Access Cards (CAC), können jetzt zur Authentifizierung im GitLab-Instanz verwendet werden, die über das Helm-Chart bereitgestellt wurde. Smartcards werden mit X.509-Zertifikaten in der lokalen Datenbank authentifiziert. Dadurch ist die Unterstützung von Smartcards mit dem Helm-Chart jetzt in Übereinstimmung mit der Unterstützung von Smartcards, die in Omnibus-Bereitstellungen verfügbar ist.
und .
Detailierte Release-Notizen und Anweisungen zur Aktualisierung/Installation finden Sie im ursprünglichen englischen Beitrag: .
An der Übersetzung aus dem Englischen haben gearbeitet , , und .
Quelle: habr.com
