Die Version 13.4 mit dem HashiCorp-Speicher für CI-Variablen, dem Kubernetes-Agenten und dem Sicherheitszentrum sowie mit schaltbaren Features im Starter wurde veröffentlicht.
Bei GitLab denken wir ständig darüber nach, wie wir den Nutzern helfen können, Risiken zu minimieren, die Effizienz zu steigern und die Geschwindigkeit der Bereitstellung auf Ihrer bevorzugten Plattform zu erhöhen. In diesem Monat haben wir zahlreiche nützliche Neuerungen hinzugefügt, die die Sicherheitsmöglichkeiten erweitern, die Anzahl der Schwachstellen reduzieren, die Effizienz steigern, die Arbeit mit GitLab erleichtern und Ihrem Team helfen, Features noch schneller bereitzustellen. Wir hoffen, dass die Hauptfeatures dieses Releases Ihnen nützlich sein werden sowie 53 weitere neue Features, die in diesem Release hinzugefügt wurden.
Erweiterte Sicherheitsfunktionen
Wir bemühen uns, jeden Monat einige neue Features in GitLab DevSecOps hinzuzufügen, und dieses Release ist da keine Ausnahme. im Rahmen von Build und Deployment verwendet werden. Außerdem können Organisationen, die das Prinzip der Trennung von Aufgaben bei der Bereitstellung von Code unterstützen möchten, nun hinzufügen. Diese Rolle entspricht und ermöglicht es, Merge-Requests (in der deutschen Lokalisierung von GitLab „Merge-Anfragen“) zu genehmigen und Code in geschützten Umgebungen bereitzustellen, ohne dabei Zugriff auf die Änderung des Codes zu gewähren.
Ein weiterer Weg, um Risiken zu minimieren, ist die Verwendung des neuen Betriebsspezialisten können Kubernetes-Cluster aus GitLab bereitstellen, ohne den Zugriff auf ihr Cluster für das gesamte Internet zu öffnen. Wir stellen außerdem automatische Unterstützung für die Versionskontrolle neuer Terraform-Zustandsdateien mit zur Unterstützung von Compliance-Anforderungen und zur Vereinfachung der Fehlersuche bereit. Und schließlich hat sich das Sicherheitsdashboard in der Instanz in ein mit Berichten über Schwachstellen und Sicherheitseinstellungen verwandelt.
Bequemer und effizienter Arbeiten mit GitLab
Wir haben unsere globale Suche verbessert, indem wir ihr , die einen einfachen Zugriff auf die neuesten Tickets, Gruppen, Projekte, Einstellungen und Hilfeseiten ermöglicht, hinzugefügt haben. Wir freuen uns, bekanntzugeben, dass auf GitLab Pages für die Weiterleitung einzelner Seiten und Verzeichnisse innerhalb der Website, was den Nutzern ermöglicht, ihre Websites effizienter zu entwickeln. Außerdem können diejenigen, die erweiterte Informationen zur Bereitstellung erhalten möchten, mit diesem Release !
Open-Source-Quellen
Wir präsentieren , die hinzugefügt wurde von . Die Kennzeichnungen zur Abdeckung durch Unit-Tests des geänderten Codes geben den Entwicklern einen klaren Eindruck von der Codeabdeckung beim Review; diese Informationen helfen, das Review zu beschleunigen und die Zeit für das Mergen und Bereitstellen neuer Codes zu reduzieren. Zudem haben wir und planen .
Und das ist erst der Anfang!
Wie immer, es gibt in der allgemeinen Übersicht zu wenig Platz und die coolen Funktionen in der Version 13.4 sind sehr zahlreich. Hier sind noch einige:
- .
Wenn Sie wissen möchten, was Sie erwartet in der nächsten Version, schauen Sie sich .
.
diesen Monat an —
Fabio hat einen erheblichen in Beitrag geleistet — eine Funktion, die von der GitLab-Community lange erwartet wurde. Dies ist ein wirklich wichtiger Beitrag mit nicht trivialen Änderungen, die eine ständige Zusammenarbeit mit Mitgliedern des GitLab-Teams erforderten und viele Bereiche des Projekts betrafen, wie UX, Frontend und Backend.
Hauptfunktionen der GitLab-Version 13.4
Verwenden Sie HashiCorp Vault-Schlüssel in CI-Jobs
(PREMIUM, ULTIMATE, SILVER, GOLD)
In der Version 12.10 stellte GitLab die Möglichkeit vor, Schlüssel in CI-Jobs zu erhalten und zu übergeben, indem der GitLab-Job-Runner genutzt wird. Jetzt erweitern wir , indem wir eine neue Syntax hinzuzufügen secrets in die Datei .gitlab-ci.yml. Dies erleichtert die Konfiguration und Nutzung des HashiCorp-Stores mit GitLab.
und .
Wir präsentieren den GitLab Kubernetes-Agenten
(PREMIUM, ULTIMATE)
Die Integration von GitLab mit Kubernetes ermöglicht bereits seit geraumer Zeit das Deployen auf Kubernetes-Clustern, ohne dass eine manuelle Konfiguration erforderlich ist. Viele Benutzer schätzen die Benutzerfreundlichkeit dieser Kombination, während andere auf einige Schwierigkeiten gestoßen sind. Für die aktuelle Integration muss Ihr Cluster aus dem Internet zugänglich sein, damit GitLab darauf zugreifen kann. Für viele Organisationen ist dies nicht möglich, da sie den Zugriff auf Cluster aus Sicherheits-, Compliance- oder Regulierungsgründen einschränken. Um diese Einschränkungen zu umgehen, mussten Benutzer eigene Werkzeuge über GitLab erstellen, andernfalls könnten sie diese Funktion nicht nutzen.
Heute stellen wir den GitLab Kubernetes-Agenten vor – eine neue Methode zur Bereitstellung auf Kubernetes-Clustern. Der Agent arbeitet innerhalb Ihres Clusters, sodass Sie ihn nicht für das gesamte Internet öffnen müssen. Der Agent koordiniert das Deployment, 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 Agenten ist. Derzeit konzentrieren wir uns beim GitLab Kubernetes-Agenten auf die Konfiguration und Verwaltung des Deployments über Code. Einige bestehende Funktionen der Kubernetes-Integration, wie Deployment-Boards und von GitLab verwaltete Anwendungen, werden vorerst nicht unterstützt. , dass diese Funktionen in zukünftige Versionen des Agenten aufgenommen werden, sowie neue Integrationen, die auf Sicherheit und Compliance abzielen.
und .
Erteilen Sie Benutzern Berechtigungen zum Deployen ohne Zugriff auf den Code
(PREMIUM, ULTIMATE, SILVER, GOLD)
Früher erlaubte das Berechtigungssystem in GitLab nicht, die Verantwortlichkeiten in Ihrem Team effektiv zwischen den Entwicklern und denjenigen, die für das Deployment verantwortlich sind, zu trennen. Mit der Veröffentlichung von GitLab 13.4 können Sie Berechtigungen zum Genehmigen von Merge-Requests für die Bereitstellung sowie für das tatsächliche Deployment von Code an Personen erteilen, die keinen Code schreiben, ohne diesen dabei die Berechtigungen eines Maintainers (in der russischen Lokalisierung von GitLab „сопровождающий“) zu geben.
und .
Sicherheitszentrum
(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 bestand aus einer einzigen Seite, die Details zu Sicherheitsanfälligkeiten, Metriken und Einstellungen vereinte. Es gab nicht viel Raum für die Weiterentwicklung dieser Funktionen oder die Nutzung anderer Sicherheitsmittel.
Wir haben grundlegende Änderungen an der Sicherheitsverwaltung und deren Transparenz in GitLab vorgenommen. Das Sicherheitsdashboard der Instanz hat sich in ein umfassendes Sicherheitszentrum verwandelt. Die größte Veränderung ist die Einführung einer neuen Menüstruktur: Statt einer einzigen Seite sehen Sie jetzt separat das Sicherheitsdashboard, den Sicherheitsbericht und den Einstellungsbereich. Obwohl die Funktionalität gleich geblieben ist, wird die Aufteilung in Abschnitte die Verbesserung dieses Bereichs ermöglichen, was sonst schwierig gewesen wäre. Dies schafft auch eine Grundlage für die zukünftige Hinzufügung weiterer sicherheitsbezogener Funktionen.
Der spezielle Abschnitt für den Sicherheitsbericht hat nun mehr Platz für die Anzeige wichtiger Details. Hier sind die Sicherheitsanfälligkeiten gesammelt, die derzeit in der Liste der Sicherheitsanfälligkeiten des Projekts stehen. Das Verschieben der Widgets mit den Sicherheitsanfälligkeitsmetriken in einen separaten Abschnitt schafft ein praktisches Sicherheitsdashboard. Dies ist nun eine Leinwand für zukünftige Visualisierungen — nicht nur für das Management von Sicherheitsanfälligkeiten, sondern auch für alle sicherheitsrelevanten Metriken. Schließlich schafft ein separater Einstellungsbereich einen gemeinsamen Raum für alle sicherheitsbezogenen Einstellungen auf Instanzebene, nicht nur für das Management von Sicherheitsanfälligkeiten.
und .
Umsteuerbare Funktionen jetzt in GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
In GitLab 11.4 wurde die . In 12.2 haben wir Strategien für sie eingeführt. und , und in 13.1 haben wir hinzugefügt und für verschiedene Umgebungen.
Früher in diesem Jahr hat GitLab sich verpflichtet, in den Open Source. In diesem Release haben wir die Übertragung umschaltbarer Funktionen in den Starter-Plan abgeschlossen und werden sie weiterhin in den Core mit . Wir freuen uns, diese Möglichkeit einer größeren Anzahl von Nutzern zur Verfügung zu stellen und möchten wissen, wie Sie sie nutzen werden.
und .
Schnelle Navigation aus der Suchzeile
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Manchmal möchten Sie beim Navigieren in GitLab direkt zu einem bestimmten Projekt gelangen, anstatt zur Seite mit den Suchergebnissen zu gehen.
Mit der globalen Suchleiste können Sie schnell zu den letzten Tickets, Gruppen, Projekten, Einstellungen und Hilfeabschnitten wechseln. Sie können sogar die Tastenkombination verwenden /, um den Cursor auf die Suchleiste zu verschieben, um noch effizienter durch GitLab zu navigieren!
und .
Anzeige der Codeabdeckung in den Diff's von Merge-Requests
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bei der Überprüfung eines Merge-Requests kann es schwierig sein zu bestimmen, ob der geänderte Code durch Unit-Tests abgedeckt ist. Stattdessen können die Prüfer auf die allgemeine Abdeckung vertrauen und verlangen, dass diese erhöht wird, bevor sie den Merge-Request genehmigen. Dies kann zu einem systematischen Ansatz beim Schreiben von Tests führen, der tatsächlich die Qualität des Codes oder dessen Testabdeckung nicht verbessert.
Jetzt sehen Sie beim Betrachten der Diff eines Merge-Requests eine anschauliche Darstellung der Codeabdeckung. Neue Markierungen ermöglichen es Ihnen, schnell zu erkennen, ob der geänderte Code durch einen Unit-Test abgedeckt ist, was den Code-Review und die Merge- sowie Bereitstellungszeiten des neuen Codes beschleunigt.
Danke und Siemens für dieses Feature!
und .
Mehr Umgebungen und Projekte in der Umgebungstafel
(PREMIUM, ULTIMATE, SILVER, GOLD)
Seit der Veröffentlichung von GitLab 12.5 konnten Sie mit der den Status von Umgebungen verfolgen, jedoch nicht mehr als sieben Umgebungen in drei Projekten. Wir haben dieses Dashboard mit der Veröffentlichung 13.4 verbessert, indem wir es in Seiten unterteilt haben, um Ihnen zu helfen, Ihre Umgebungen zu pflegen und sie in größerem Maßstab zu verwalten. Jetzt können Sie mehr Umgebungen in mehr Projekten sehen.
und .
GitLab hat das Management des GitLab Terraform Providers übernommen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kürzlich haben wir und planen . In den letzten Monat haben wir 21 Merge-Requests angenommen und 31 Tickets geschlossen, darunter einige langanhaltende Fehler und fehlende Funktionen wie . Sie können in der Terraform-Dokumentation.
und .
Fuzzing-Tests der API mit OpenAPI-Spezifikationen oder HAR-Dateien
(ULTIMATE, GOLD)
Fuzzing-Tests für APIs sind eine hervorragende Möglichkeit, Fehler und Schwachstellen in Ihren Webanwendungen und APIs zu finden, die von anderen Scannern und Testmethoden möglicherweise übersehen werden.
API-Fuzzing-Tests in GitLab ermöglichen es, oder Ihrer Anwendung zu verwenden und dann automatisch zufällige Eingabedaten zu generieren, die dazu dienen, Grenzfälle zu überprüfen und Fehler aufzudecken. Die Ergebnisse werden sofort in Ihrem Pipeline angezeigt.
Dies ist unsere erste Veröffentlichung für API-Fuzzing-Tests, und wir sind gespannt auf Ihr Feedback. Für das Fuzzing-Testing haben wir noch , auf denen wir die Veröffentlichung dieser Funktion 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 in GitLab eine Herausforderung. Nachdem Sie eine Metrik in der YAML-Datei des Dashboards erstellt hatten, mussten Sie Änderungen vornehmen, master, ohne überprüfen zu können, ob das neu erstellte Diagramm so funktioniert, wie Sie es benötigt haben. Ab dieser Version können Sie Änderungen während der Erstellung des Diagramms in einer Vorschau anzeigen, um einen Eindruck vom Ergebnis zu erhalten, bevor Sie die Änderungen in die YAML-Datei des Dashboards senden.
und .
Tests zur Codeabdeckung über 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 darüber, wie sich die Codeabdeckung im Laufe der Zeit über alle Projekte ändert. Früher erforderte die Anzeige dieser Informationen mühsame und zeitraubende manuelle Arbeit: Sie mussten die Daten zur Codeabdeckung aus jedem Projekt herunterladen und in einer Tabelle kombinieren.
In Version 13.4 wurde die Möglichkeit eingeführt, einfach und schnell alle Daten zur Codeabdeckung über alle Projekte der Gruppe oder eine Auswahl von Projekten in .csv -Dateien zusammenzufassen. Diese Funktion ist ein MVP, auf den die Möglichkeit folgt, .
und .
Unterstützung neuer Sprachen für umfassende Fuzzing-Tests
(ULTIMATE, GOLD)
Diese Version bietet Unterstützung für mehrere neue Sprachen für Fuzzing-Tests, die auf vollständige Abdeckung abzielen.
Jetzt können Sie alle Möglichkeiten des Fuzzing-Tests in Ihren Anwendungen auf Java, Rust und Swift bewerten und Fehler sowie Schwachstellen finden, die andere Scanner und Testmethoden übersehen könnten.
und .
Benachrichtigungen auf der Übersichtsseite 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 der aufgetretenen Probleme zu ergreifen.
und .
Verschachtelte Pipelines können jetzt ihre eigenen verschachtelten Pipelines starten
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Mit der Verwendung von verschachtelten Pipelines ist es jetzt möglich, neue Pipelines innerhalb von Kind-Pipelines zu starten. Eine zusätzliche Ebene kann hilfreich sein, wenn Sie Flexibilität zur Generierung variabler Pipelines benötigen.
Früher benötigt jede Kind-Pipeline, die verschachtelte Pipelines verwendet, einen Trigger-Job, der manuell in der übergeordneten Pipeline festgelegt wurde. Jetzt können Sie verschachtelte Pipelines erstellen, die dynamisch beliebig viele neue verschachtelte Pipelines auslösen. Wenn Sie zum Beispiel ein Monorepo haben, können Sie dynamisch die erste verschachtelte Pipeline generieren, die selbst die erforderliche Anzahl neuer Pipelines basierend auf Änderungen im Branch erstellt.
und .
Verbesserte Navigation zwischen übergeordneten und verschachtelten Pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Die Navigation zwischen übergeordneten und verschachtelten Pipelines war früher nicht besonders benutzerfreundlich — es waren viele Klicks nötig, um zur gewünschten Pipeline zu gelangen. Es war auch nicht einfach zu erkennen, welches Projekt diese Pipeline ausgelöst hat. Jetzt ist es viel einfacher, die Verbindungen zwischen übergeordneten und verschachtelten Pipelines zu sehen.
und .
Parallele Matrix-Jobs zeigen relevante Variablen im Jobnamen an
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wenn Sie die verwendet haben, haben Sie vielleicht bemerkt, dass es schwierig war zu bestimmen, welche Matrix-Variable für einen bestimmten Job verwendet wurde, da die Jobnamen wie matrix 1/4. In der Version 13.4 werden Sie relevante Werte der Variablen sehen, die in dieser Aufgabe verwendet wurden, anstelle des allgemeinen Aufgabennamens. Zum Beispiel, wenn Ihr Ziel das Debugging für die x86-Architektur ist, wird die Aufgabe genannt matrix: debug x86.
und .
Weitere Verbesserungen in GitLab 13.4
Verknüpfung des Atlassian-Kontos
(CORE, STARTER, PREMIUM, ULTIMATE)
GitLab-Benutzer können jetzt ihre GitLab-Konten mit ihren Atlassian Cloud-Konten verknüpfen. Dies ermöglicht die Anmeldung in GitLab mit Atlassian-Anmeldedaten und legt den Grundstein für zukünftige Verbesserungen der Integration und mit anderen Produkten aus der Atlassian-Reihe.
und .
Exportliste aller Merge-Commits
(ULTIMATE, GOLD)
Organisationen, die auf Compliance ausgerichtet sind, benötigen eine Möglichkeit, Auditoren ein vollständiges Bild der Komponenten zu zeigen, die mit einer bestimmten Änderung in der Produktion verbunden sind. Innerhalb von GitLab bedeutet dies, dass alles an einem Ort gesammelt werden muss: Merge-Requests, Tickets, Pipelines, Sicherheitsanalysen und andere Commit-Daten. Bis jetzt mussten Sie entweder alles manuell in GitLab sammeln oder Ihre eigenen Tools zur Informationssammlung einrichten, was nicht sehr effizient war.
Jetzt können Sie diese Daten programmgesteuert sammeln und exportieren, um die Anforderungen der 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 zu gehen und auf die Schaltfläche Liste aller Merge-Commitsklicken. Die resultierende Datei enthält alle Commits des Merge-Requests, deren Autor, die ID des zugehörigen Merge-Requests, die Gruppe, das Projekt, die Bestätiger und weitere Informationen.
und .
Ausgabe der Liste und Verwaltung persönlicher Zugriffstoken über die API
(ULTIMATE, GOLD)
Die Verwaltung des Zugriffs auf den GitLab-Namensraum ist ein wichtiger Teil der Compliance-Aktivitäten. Von den Grundsätzen der minimalen Privilegien bis zur zeitgesteuerten Zugriffssperre können mehrere Anforderungen an persönliche Zugriffstoken in GitLab bestehen. Um es einfacher zu machen, all diese Benutzeranmeldeinformationen in Ihrem Namensraum zu verwalten, haben wir die Möglichkeit bereitgestellt, alle persönlichen Zugriffstoken anzuzeigen und optional über die API.
Diese Verbesserungen in der GitLab API ermöglichen es Benutzern, ihre eigenen persönlichen Zugriffstoken aufzulisten und zu widerrufen, während Administratoren die Tokens ihrer Benutzer auflisten und widerrufen können. Nun wird es Administratoren leichter fallen, zu sehen, wer Zugriff auf ihren Namespace hat, Entscheidungen über die Gewährung von Zugriff basierend auf Benutzerdaten zu treffen und persönliche Zugriffstoken zu widerrufen, die möglicherweise kompromittiert wurden oder die über die Unternehmensrichtlinien zur Zugriffsverwaltung hinausgehen.
und .
Verknüpfte Tickets und andere Funktionen jetzt im 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 russischen Lokalisierung von GitLab „Diskussionsboard“) im Core-Plan verfügbar. Dies betrifft nur die Beziehungen vom Typ „verknüpft mit“; die Beziehungen vom Typ „blockiert“ und „wird blockiert“ bleiben in kostenpflichtigen Plänen.
und .
Anzeigen des Namens des Ursprungszweigs in der Seitenleiste des Merge-Requests
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bei der Überprüfung von Codeänderungen, Diskussionen und Commits des Merge-Requests ist es häufig wünschenswert, ein lokales Checkout des Branches für eine tiefere Überprüfung durchzuführen. Es wird jedoch zunehmend schwieriger, den Namen des Branches zu finden, je mehr Inhalt zur Beschreibung des Merge-Requests hinzugefügt wird, und man muss weiter nach unten scrollen.
Wir haben den Branch-Namen in die Seitenleiste des Merge-Requests aufgenommen, so dass er jederzeit verfügbar ist und das Blättern durch die gesamte Seite überflüssig macht. Wie der Link zum Merge-Request enthält der Abschnitt mit dem Ursprungszweig einen praktischen Button „Kopieren“.
Danke für seinen enormen Beitrag zur Entwicklung dieser Funktion!
und .
Hinweis auf das Vorhandensein ausgeklappter Dateien in den Diffs des Merge-Requests
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Merge-Requests, die Änderungen an mehreren Dateien hinzufügen, klappen manchmal die Diffs großer Dateien ein, um die Anzeigeleistung zu verbessern. Wenn dies passiert, kann es vorkommen, dass beim Review eine Datei übersehen wird, insbesondere bei Merge-Requests mit einer großen Anzahl an Dateien. Ab Version 13.4 werden Merge-Requests Diffs kennzeichnen, die eingeklappten Dateien enthalten, sodass Sie diese Dateien im Code-Review-Prozess nicht übersehen. Um noch mehr Klarheit zu schaffen, planen wir, in einer zukünftigen Version die Hervorhebung dieser Dateien hinzuzufügen. Halten Sie sich über die Updates in .
und .
Warnung über das Vorhandensein eingeklappten Dateien im Diff des Merge-Requests
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Im Bereich mit Diffs von Merge-Requests werden große Dateien eingeklappt, um die Leistung zu steigern. Wenn jedoch der Code überprüft wird, können einige Dateien übersehen werden, wenn der Reviewer die Dateiliste durchblättert, da alle großen Dateien eingeklappt 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 Abschnitt eine eingeklappte Datei vorhanden ist. So übersehen Sie beim Review keine Änderungen im Merge-Request.
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 ausgefallen ist, wurden die Repositorys auf diesem Knoten als nur lesbar gekennzeichnet. Dies verhinderte Datenverluste, wenn auf dem Knoten Änderungen vorgenommen wurden, die noch nicht repliziert waren. Wenn der Knoten wieder verbunden wurde, stellte GitLab sich nicht automatisch wieder her, und Administratoren mussten den Synchronisierungsprozess manuell starten oder mit Datenverlust rechnen. Auch andere Situationen, wie ein fehlgeschlagenes Replikationsaufgaben auf einem sekundären Knoten, könnten zu veralteten oder nur lesbaren Repositorys geführt haben. In diesem Fall blieb das Repository veraltet, bis die nächste Schreiboperation ausgeführt wurde, die die Replikationsaufgabe starten würde.
Um dieses Problem zu lösen Jetzt plant er eine Replikationsaufgabe, wenn er ein veraltetes Repository auf einem Knoten entdeckt und die neueste Version des Repositories auf einem anderen. Diese Replikationsaufgabe macht das Repository automatisch aktuell, was die Notwendigkeit eliminiert, Daten manuell wiederherzustellen. Die automatische Wiederherstellung sorgt auch für eine schnelle Aktualisierung sekundärer 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 zum Cluster hinzugefügt wird, was die manuelle Arbeit beim Hinzufügen neuer Knoten eliminiert.
und .
Markieren Sie die To-Do-Aufgabe als erledigt auf der Designseite
(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, zur Aufgabe zu navigieren und entweder etwas zu tun oder sie als bereits erledigt zu kennzeichnen. Es ist auch wichtig, die Möglichkeit zu haben, sich die Aufgabe zuzuweisen, wenn Sie an etwas arbeiten oder später darauf zurückkommen müssen.
Früher konnten Sie bei der Arbeit an Designs keine Aufgaben hinzufügen oder diese als erledigt markieren. Dies hat die Effizienz der Kommunikation zwischen den Produktteams erheblich beeinträchtigt, da To-Do-Aufgaben ein entscheidendes Element im Arbeitsablauf in GitLab darstellen.
In Release 13.4 holen Designs bei den Kommentaren zu Tickets im Einsatz 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 sein wird, die Ihnen hilft, GitLab CI/CD schnell und einfach einzurichten und zu starten.
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 sich ein Merge-Request bereits in der Warteschlange befand und jemand einen Kommentar hinzufügte, der eine neue ungeklärte Diskussion auslöste, wurde der Merge-Request als ungeeignet für das Mergen angesehen und fiel aus der Warteschlange. Jetzt, nachdem ein Merge-Request zur Merge-Warteschlange hinzugefügt wurde, können neue Kommentare hinzugefügt werden, ohne den Merge-Prozess zu stören.
und .
Anzeigen des Codeabdeckungswerts im Merge-Request für Aufgaben
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Entwickler müssen die Möglichkeit haben, den Codeabdeckungswert nach Abschluss der Pipeline zu sehen — selbst in komplexen Szenarien, wie z.B. wenn die Pipeline mehrere Aufgaben verarbeiten muss, um den Codeabdeckungswert zu berechnen. Früher zeigte das Merge-Request-Widget nur den Durchschnitt dieser Werte an, was bedeutete, dass man zur Aufgaben-Seite und zurück zum Merge-Request navigieren 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 Durchschnittswertes der Abdeckung, dessen Änderung zwischen Ziel- und Quellbranch sowie ein Tooltipp eingeführt, der den Abdeckungswert für jede Aufgabe anzeigt, auf deren Grundlage der Durchschnittswert berechnet wurde.
und .
Entfernen von Paketen aus dem Paket-Registry beim Durchsuchen der Gruppe
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Das GitLab-Paket-Registry ist ein Ort zum Speichern und Verteilen von Paketen in verschiedenen Formaten. Wenn Ihr Projekt oder Ihre Gruppe viele Pakete hat, müssen Sie ungenutzte Pakete schnell identifizieren und entfernen, damit sie nicht heruntergeladen werden. Sie können Pakete aus Ihrem Registry über oder über die Benutzeroberfläche des Paket-Registrys entfernen. Bis jetzt konnten Sie jedoch keine Pakete beim Durchsuchen der Gruppe über die Benutzeroberfläche entfernen. Daher mussten Sie überflüssige Pakete einzeln für jedes Projekt entfernen, was ineffizient war.
Jetzt können Sie Pakete beim Durchsuchen des Gruppen-Paket-Registrys entfernen. Gehen Sie einfach zur Seite des Gruppen-Paket-Registrys, filtern Sie die Pakete nach Namen 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 verwenden, um C/C++-Abhängigkeiten zu veröffentlichen und zu verteilen. Zuvor konnten Pakete nur auf Instanzebene skaliert werden, da der Paketname von Conan maximal 51 Zeichen lang sein konnte. Wenn Sie beispielsweise ein Paket aus einer Untergruppe veröffentlichen wollten, gitlab-org/ci-cd/package-stage/feature-testing/conan, war das fast unmöglich.
Jetzt können Sie Conan-Pakete auf Projektebene skalieren, was das Veröffentlichen und Verteilen der Abhängigkeiten Ihrer Projekte erheblich erleichtert.
und .
Unterstützung neuer Paketmanager und Sprachen zum Scannen von Abhängigkeiten
(ULTIMATE, GOLD)
Wir freuen uns, das Scannen von Abhängigkeiten für Projekte mit C-, C++-, C#- und .Net-Code, die NuGet 4.9+ oder die Paketmanager von Conan verwenden, in unsere Liste aufzunehmen . Jetzt können Sie das Scannen von Abhängigkeiten als Teil der Secure-Phase einfügen, um auf bekannte Sicherheitsanfälligkeiten der über Paketmanager hinzugefügten Abhängigkeiten zu überprüfen. Gefundene Sicherheitsanfälligkeiten werden in Ihrem Merge-Request zusammen mit dem Grad ihrer Gefährlichkeit angezeigt, damit Sie vor dem Merge wissen, welche Risiken die neue Abhängigkeit mit sich bringt. Sie können Ihr Projekt auch so konfigurieren, dass es für Abhängigkeiten mit sicherheitsrelevanten Problemen mit kritischem (Critical), hohem (High) oder unbekanntem (Unknown) Gefährlichkeitsgrad.
und .
Benachrichtigungen bei Änderungen der Merge-Request-Einstellungen auf „Merge, wenn der Pipeline erfolgreich ist“
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Früher wurde bei der Einstellung der Merge-Request-Option Merge, wenn der Pipeline abgeschlossen ist (Merge When Pipeline Succeeds, MWPS) keine E-Mail-Benachrichtigung gesendet. Sie mussten manuell den Status überprüfen oder auf eine Benachrichtigung über den vollständigen Merge warten. In diesem Release freuen wir uns, den Beitrag des Nutzers , der dieses Problem gelöst hat, indem er automatische Benachrichtigungen an alle, die auf den Merge-Request abonniert sind, hinzufügte, wenn der Reviewer die Merge-Einstellung auf MWPS ändert.
und .
Erstellung von EKS-Clustern mit benutzerdefinierter Kubernetes-Version
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab-Benutzer können jetzt die Kubernetes-Version auswählen, die auf EKS bereitgestellt werden soll; Sie können zwischen den Versionen 1.14–1.17 wählen.
und .
Erstellung von Vorfällen als Tickettypen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nicht jedes aufkommende Problem löst sofort die Auslösung von Benachrichtigungen: Benutzer melden Ausfälle, während Teammitglieder sich mit Leistungsproblemen befassen. Jetzt sind Vorfälle eine Art Ticket, sodass Ihre Teams sie schnell im gewohnten Arbeitsablauf erstellen können. Klicken Sie Neue Aufgabe von überall in GitLab und im Feld Typ wählen Sie Vorfälle.
und .
Erwähnung von GitLab-Benachrichtigungen in Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wir haben die GitLab-Benachrichtigungen verbessert, indem wir einen neuen Typ der Erwähnung speziell für sie in der GitLab-Version von Markdown hinzugefügt haben, der es einfacher macht, Benachrichtigungen zu teilen und zu erwähnen. Verwenden Sie ^alert#1234, um eine Benachrichtigung in jedem Markdown-fähigen Feld zu erwähnen: in Vorfällen, Tickets oder Merge-Requests. Dies hilft Ihnen auch, Aufgaben zu identifizieren, die aus Benachrichtigungen und nicht aus Tickets oder Merge-Requests erstellt werden.
und .
Einsichtnahme auf die Last 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 nicht zwischen Tools oder Tabs wechseln müssen, während Sie an der Lösung eines Vorfalls arbeiten. Vorfälle, die aus Benachrichtigungen erstellt wurden, zeigen die vollständige Beschreibung der Benachrichtigung im Tab Alert Details.
75 % schnellere erweiterte Suche
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab hat als eine Anwendung die einzigartige Möglichkeit, die Suche nach Inhalten in gesamten DevOps-Workflows schnell zu gestalten. In GitLab 13.4 liefert die erweiterte Suche Ergebnisse 75 % schneller, wenn sie , wie auf GitLab.com.
und .
Ansicht gelöschter Projekte für Administratoren
(CORE, STARTER, PREMIUM, ULTIMATE)
Die Möglichkeit, das Löschen eines Projekts hinauszuzögern, wurde . Es gab jedoch früher keine Möglichkeit, alle Projekte, die auf die Löschung warten, an einem Ort zu sehen. Jetzt können Administratoren benutzerdefinierter GitLab-Instanzen alle Projekte, die auf die Löschung warten, an einem Ort einsehen – zusammen mit Schaltflächen zum einfachen Wiederherstellen 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 besteht, unerwünschte Löschvorgänge rückgängig zu machen.
Danke für diese Funktion!
und .
Im API wurde Unterstützung für Gruppen-Push-Regeln hinzugefügt
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Früher konnten Gruppen-Push-Regeln nur konfiguriert werden, indem man jede Gruppe einzeln über die Benutzeroberfläche von GitLab besuchte und diese Regeln anwendete. Jetzt können Sie diese Regeln über die API verwalten, um Ihre benutzerdefinierten Tools und Automatisierungen für GitLab zu unterstützen.
und .
Widerruf von persönlichen Zugriffstoken für selbstverwaltetes Geheimnis-Management
(ULTIMATE)
stellt Administratoren die Informationen zur Verfügung, die sie benötigen, um die Anmeldeinformationen der Benutzer ihrer GitLab-Instanz zu verwalten. Da Compliance-orientierte Organisationen unterschiedliche Strenge in ihren Richtlinien für die Verwaltung von Anmeldeinformationen aufweisen, haben wir eine Schaltfläche hinzugefügt, mit der Administratoren auf Wunsch das persönliche Zugriffstoken eines Benutzers (PAT) widerrufen können. Jetzt können Administratoren leicht potenziell kompromittierte PAT widerrufen. Diese Funktion ist nützlich für Organisationen, die flexiblere Optionen zur Einhaltung von Anforderungen benötigen, um Ablenkungen ihrer Benutzer zu minimieren.
und .
Konfigurationsdatei für den statischen Website-Editor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 13.4 führen wir eine neue Möglichkeit zur Konfiguration des statischen Website-Editors ein. Obwohl die Konfigurationsdatei in diesem Release keine Parameter speichert oder erhält, legen wir den Grundstein für künftige Anpassungen des Verhaltens des Editors. In zukünftigen Releases werden wir dem Datei .gitlab/static-site-editor.yml Parameter hinzufügen, um festzulegen, an der , Überschreibung der Markdown-Syntaxeinstellungen und anderer Editor-Einstellungen.
und .
Bearbeitung des einleitenden Teils der Datei mit dem Statikseiten-Editor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Der einleitende Teil (front matter) ist eine flexible und bequeme Möglichkeit, Variablen der Seite in Daten-Dateien, die für den Statikseiten-Generator gedacht sind, zu definieren. Er wird üblicherweise verwendet, um den Seitentitel, das Layout-Template oder den Autor festzulegen, kann jedoch auch verwendet werden, um jegliche Art von Metadaten an den Generator zu übermitteln, wenn die Seite in HTML gerendert wird. An der obersten Stelle jeder Datendatei enthalten, wird der einleitende Teil normalerweise als YAML oder JSON formatiert und erfordert konsistente und präzise Syntax. Benutzer, die mit den spezifischen Syntaxregeln nicht vertraut sind, können unbeabsichtigt ungültige Markups eingeben, was wiederum zu Formatierungsproblemen oder sogar Build-Fehlern führen kann.
Der WYSIWYG-Bearbeitungsmodus des Statikseiten-Editors entfernt bereits den einleitenden Teil aus dem Editor, um diese Formatierungsfehler zu vermeiden. Dies ermöglicht jedoch nicht, die in diesem Teil gespeicherten Werte zu ändern, ohne in den Quellcode-Bearbeitungsmodus zurückzukehren. In GitLab 13.4 können Sie auf jedes Feld zugreifen und dessen Wert in einer vertrauten formularbasierten Oberfläche bearbeiten. Wenn Sie auf die Schaltfläche Einstellungen (Einstellungen) klicken, öffnet sich ein Panel, das ein Formularfeld für jeden im Vorfeld definierten Schlüssel anzeigt. Die Felder sind mit dem aktuellen Wert gefüllt, und um eines davon zu bearbeiten, müssen Sie nur den gewünschten Wert in das Webformular eingeben. Diese Bearbeitung des einleitenden Teils vermeidet Syntaxprobleme und gibt Ihnen die vollständige Kontrolle über den Inhalt, während sie gleichzeitig ein einheitliches Format des Endprodukts gewährleistet.
und .
GitLab für Jira und DVCS Connector jetzt in Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Für Jira-Benutzer in GitLab: und ermöglichen die Anzeige von Informationen zu Commits und Merge-Requests von GitLab direkt in Jira. In Kombination mit unserer integrierten Jira-Integration können Sie problemlos zwischen den beiden Anwendungen während Ihrer Arbeit wechseln.
Diese Funktionen waren früher nur in unserem Premium-Plan verfügbar, sind jetzt aber für alle Benutzer zugänglich!
und .
Abstimmung mit Mehrheit für Gitaly-Clustertransaktionen (Beta-Version)
(CORE, STARTER, PREMIUM, ULTIMATE)
Das Gitaly-Cluster ermöglicht die Replikation von Git-Repositories auf mehrere "warme" Gitaly-Knoten. Dies erhöht die Fehlertoleranz, indem es einzelne Ausfallpunkte beseitigt. , die in GitLab 13.3 eingeführt wurden, führen zu einer breit gefächerten Übermittlung von Änderungen an alle Knoten im Gitaly-Cluster, aber nur die Gitaly-Knoten, die mit dem primären Knoten abstimmen, speichern die Änderungen auf der Festplatte. Wenn sich alle Replikatknoten nicht einigen, wird nur ein Exemplar der Änderung auf der Festplatte gespeichert, was bis zum Abschluss der asynchronen Replikation einen einzelnen Ausfallpunkt schafft.
Die Abstimmung mit Mehrheit erhöht die Fehlertoleranz, indem sie die Zustimmung der Mehrheit der Knoten (und nicht aller) vor dem Speichern von Änderungen auf der Festplatte erfordert. Wenn dieses schaltbare Feature aktiviert ist, muss die Speicherung erfolgreich auf mehreren Knoten durchgeführt werden. Unstimmige Knoten synchronisieren sich automatisch durch asynchrone Replikation mit den Knoten, die das Quorum bilden.
und .
Unterstützung für benutzerdefinierte Schema-Validierung von JSON im Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Projekte, in denen Menschen Konfigurationen im JSON- oder YAML-Format schreiben, sind häufig anfällig für Probleme, da es leicht ist, einen Tippfehler zu machen und etwas zu brechen. Es können Prüfwerkzeuge geschrieben werden, die diese Probleme im CI-Pipeline erfassen, aber die Verwendung einer JSON-Schema-Datei kann hilfreich sein, um Dokumentation und Hinweise bereitzustellen.
Projektteilnehmer können den Pfad zur benutzerdefinierten Schema-Datei in ihrem Repository angeben .gitlab/.gitlab-webide.yml, die das Schema und den Pfad zu den zu prüfenden Dateien angibt. Beim Hochladen einer bestimmten Datei in die Web IDE wird zusätzliches Feedback und eine Prüfung sichtbar, die beim Erstellen der Datei helfen.
und .
Die Grenze für das Verzweigen des 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 die Begrenzung von 10 Jobs, die ein Job in needs:, zu strikt. In 13.4 wurde die Standardgrenze 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 noch weiter erhöhen, indem Sie eine schaltbare Funktion aktivieren, obwohl wir dafür keine offizielle Unterstützung anbieten.
und .
Verbesserte Funktionalität needs für übersprungene Jobs
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In einigen Fällen konnte ein übersprungener Job in der Pipeline fälschlicherweise als erfolgreich für die in needs, angegebenen Abhängigkeiten betrachtet werden, weshalb nachfolgende Jobs gestartet wurden, was nicht der Fall sein sollte. Dieses Verhalten wurde in Version 13.4 korrigiert, und needs verarbeitet nun korrekt Fälle von übersprungenen Jobs.
und .
Sichern Sie den letzten Job-Artefakt, um dessen Löschung zu verhindern
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab blockiert nun automatisch den letzten Artefakt eines erfolgreichen Jobs und einer Pipeline in jedem aktiven Branch, Merge-Request oder Tag, um dessen Löschung nach Ablauf der Frist zu verhindern. Es wird einfacher, aggressivere Ablaufregeln für die Bereinigung alter Artefakte festzulegen. Dies hilft, den Speicherplatzbedarf zu reduzieren und stellt sicher, dass Sie immer eine Kopie des letzten Artefakts der Pipeline haben.
und .
Leitfaden für CI/CD zur Optimierung von Pipelines
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Die Optimierung von CI/CD-Pipelines 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)
— dies 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, gescheiterte Tests zu finden. Weitere Probleme, die die Verwendung des Berichts erschweren können, sind Schwierigkeiten beim Scrollen durch lange Ausgaben von Tracebacks und das Runden der Zeit auf null für Tests, die in weniger als 1 Sekunde durchgeführt werden. Der Testbericht sortiert jetzt standardmäßig zuerst gescheiterte Tests an den Anfang des Berichts und sortiert dann die Tests nach Dauer. Dies erleichtert das Finden von Fehlgeschlagenen und langwierigen Tests. Darüber hinaus wird die Dauer der Tests jetzt in Millisekunden oder Sekunden angezeigt, sodass sie viel schneller gelesen werden können, und auch die vorherigen Scrollprobleme wurden behoben.
und .
Dateigrößenbeschränkungen für das Hochladen in das Paket-Repository
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Es gibt jetzt Einschränkungen für die Dateigrößen von Paketen, die in das GitLab-Paket-Repository hochgeladen werden können. Die Einschränkungen wurden eingeführt, um die Leistung des Paket-Repositorys zu optimieren und Missbrauch zu verhindern. Die Einschränkungen hängen vom Paketformat ab. Für GitLab.com gelten die maximalen Dateigrößen:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Für benutzerdefinierte GitLab-Instanzen sind die Standardwerte dieselben. Der Administrator kann jedoch die Einschränkungen mit .
und .
Verwenden Sie CI_JOB_TOKEN, um Pakete in PyPI zu veröffentlichen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sie können das GitLab PyPI-Repository nutzen, um Python-Pakete zusammen mit dem Quellcode und CI/CD-Pipelines zu erstellen, zu veröffentlichen und zu teilen. Vorher konnten Sie sich jedoch nicht mit einer vordefinierten Umgebungsvariablen 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 gar nicht zu verwenden.
Jetzt ist es einfacher, GitLab CI/CD für die Veröffentlichung und Installation von PyPI-Paketen mit einer vordefinierten Umgebungsvariablen zu verwenden. CI_JOB_TOKEN.
und .
DAST-Scanner-Profile auf Anfrage
(ULTIMATE, GOLD)
Das anforderbare DAST-Scanning, das , es wurden Scannerprofile für DAST hinzugefügt. Sie erweitern die Konfigurationsmöglichkeiten dieses Scans, sodass mehrere Profile schnell erstellt werden können, um verschiedene Scanntypen abzudecken. In 13.4 umfasst das Scannerprofil zunächst den Timeout-Parameter des Crawlers, der festlegt, wie lange der DAST-Crawler arbeiten soll, wenn er versucht, alle Seiten der gescannten Website zu entdecken. Das Profil enthält auch den Timeout-Parameter der Zielwebsite, um festzulegen, wie lange der Scanner warten soll, bis die Website verfügbar ist, bevor er den Scan abbricht, falls die Website nicht mit dem Statuscode 200 oder 300 reagiert. Während wir dieses Feature in zukünftigen Releases immer weiter verbessern werden, werden dem Scannerprofil zusätzliche Konfigurationsparameter hinzugefügt.
und .
Einfache Konfigurationsdatei für Weiterleitungen für GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wenn Sie GitLab Pages verwenden und URL-Änderungen besser verwalten möchten, haben Sie vielleicht festgestellt, dass es nicht möglich war, Weiterleitungen auf Ihrer GitLab Pages-Website zu verwalten. GitLab ermöglicht es Ihnen jetzt, Regeln zum Weiterleiten einer URL auf eine andere für Ihre Pages-Website zu konfigurieren, indem Sie eine Konfigurationsdatei in das Repository hinzufügen. Diese Funktion wurde durch die Mitwirkung von Kevin Barnett (), unserem Eric Eastwood () und dem GitLab-Team möglich. Vielen Dank an alle für Ihren Beitrag.
und .
Terraform-Status, verwaltet durch GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Der Zugriff auf frühere Versionen des Terraform-Status ist sowohl aus Compliance-Gründen als auch zur Fehlersuche erforderlich. Die Unterstützung für die Versionsverwaltung des durch GitLab verwalteten Terraform-Status wird ab GitLab 13.4 bereitgestellt. Die Versionsverwaltung wird automatisch für neue Terraform-Zustandsdateien aktiviert. Bestehende Terraform-Zustandsdateien werden in einer späteren Veröffentlichung.
und .
Wichtige Details zur Vorfallbenachrichtigung
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bei der Bearbeitung von Vorfällen müssen Sie leicht feststellen können, wie lange die Warnung offen war und wie oft das Ereignis ausgelöst wurde. Diese Details sind oft entscheidend für die Beurteilung der Auswirkungen auf den Kunden und was Ihr Team zuerst angehen sollte. Auf dem neuen Detail-Dashboard für Vorfälle zeigen wir die Startzeit der Warnung, die Anzahl der Ereignisse und einen Link zur ursprünglichen Warnung an. Diese Informationen stehen für Vorfälle zur Verfügung, die aus Warnungen erstellt werden.
und .
Festlegen und Bearbeiten der Schweregradoption für Vorfälle
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Die Schweregradoption für Vorfälle ermöglicht es den Reaktionsspezialisten und Interessengruppen, die Folgen eines Ausfalls sowie die Methoden und Dringlichkeit der Reaktion festzulegen. Während Ihr Team während der Bearbeitung des Vorfalls Fortschritte teilt und die Betriebsbereitschaft wiederherstellt, kann es dieser Option Änderungen vornehmen. Jetzt können Sie den Schweregrad des Vorfalls im rechten Seitenbereich der Seite "Details zu Vorfällen" bearbeiten, und der Schweregrad wird in der Vorfallsliste angezeigt.
und .
Erstellen, Bearbeiten und Löschen von Sicherheitsregeln für Container
(ULTIMATE, GOLD)
Diese Verbesserung des Editors für Sicherheitsregeln für Container ermöglicht es den Benutzern, ihre Regeln direkt aus der 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 Regel-Editor mit intuitiver Benutzeroberfläche für diejenigen, die nicht gut mit Netzwerkregeln vertraut sind. Neue Regelverwaltungsfunktionen finden Sie im Abschnitt Sicherheit und Compliance > Bedrohungsmanagement > Richtlinien (Security & Compliance > Bedrohungsmanagement > Richtlinien).
und .
Unterstützung für Azure Blob-Speicher
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Sowohl GitLab als auch GitLab Runner unterstützen jetzt , was das Einrichten von GitLab-Diensten in Azure vereinfacht.
GitLab-Instanzen unterstützen Azure für alle Arten von Objektspeichern, einschließlich LFS-Dateien, CI-Artefakten und . Um den Azure Blob-Speicher einzurichten, folgen Sie den Installationsanleitungen für oder .
GitLab-Job-Handler unterstützen ebenfalls Azure für die Speicherung von Das Azure-Speicher kann über den Abschnitt konfiguriert werden .
und .
Omnibus ARM64-Pakete für Ubuntu und OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
Als Reaktion auf die wachsende Nachfrage nach Unterstützung für die Ausführung von GitLab auf 64-Bit-ARM-Architektur freuen wir uns, die Verfügbarkeit des offiziellen ARM64 Ubuntu 20.04 Omnibus-Pakets bekannt zu geben. Ein riesiges Dankeschön an Zitai Chen und Guillaume Gardet für ihren großartigen Beitrag – ihre Merge-Requests spielten eine Schlüsselrolle dabei!
Um das Paket für Ubuntu 20.04 herunterzuladen und zu installieren, besuchen Sie unsere und wählen Sie Ubuntu.
und .
Unterstützung der Authentifizierung mit Smartcards für das GitLab Helm-Chart
(PREMIUM, ULTIMATE)
Smartcards, wie z.B. Common Access Cards (CAC), können jetzt zur Authentifizierung in einer über das Helm-Chart bereitgestellten GitLab-Instanz verwendet werden. Smartcards authentifizieren sich in einer lokalen Datenbank mit X.509-Zertifikaten. Damit ist die Unterstützung von Smartcards im Helm-Chart nun mit der Unterstützung von Smartcards in Omnibus-Bereitstellungen kompatibel.
und .
Detaillierte Versionshinweise und Installations-/Upgrade-Anleitungen finden Sie im originalen englischen Beitrag: .
Die Übersetzung aus dem Englischen wurde durchgeführt von , , und .
Quelle: habr.com
