Schnelle Erkennung von Geheimnislecks
Es scheint ein kleiner Fehler zu sein – aus Versehen Anmeldeinformationen in ein öffentliches Repository zu übertragen. Die Folgen können jedoch ernst sein. Sobald ein Angreifer Ihr Passwort oder Ihren API-Schlüssel erhält, kann er Ihr Konto übernehmen, Sie sperren und Ihr Geld betrügerisch verwenden. Außerdem kann es einen Domino-Effekt geben: Der Zugriff auf ein Konto eröffnet den Zugriff auf andere. Die Einsätze sind hoch, daher ist es äußerst wichtig, so schnell wie möglich über Geheimnislecks informiert zu werden.
In diesem Release stellen wir die Option vor im Rahmen unserer SAST-Funktionalität. Jeder Commit wird im CI/CD-Job auf Geheimnisse gescannt. Gibt es ein Geheimnis, erhält der Entwickler eine Warnung im Merge-Request. Er annulliert vor Ort die kompromittierten Anmeldeinformationen und erstellt neue.
Sichere Änderungsverwaltung
Mit dem Wachstum und der Komplexität wird es zunehmend schwieriger, die Konsistenz zwischen verschiedenen Teilen der Organisation aufrechtzuerhalten. Je mehr Benutzer die Anwendung nutzen und je höher der Umsatz ist, desto schwerwiegender sind die Folgen von Merge von fehlerhaftem oder unsicheren Code. Für viele Organisationen ist die Gewährleistung eines ordnungsgemäßen Prüfprozesses vor dem Merge von Code eine strenge Anforderung, da die Risiken sehr hoch sind.
In GitLab 11.9 gibt es mehr Kontrolle und eine effektivere Struktur – dank . Früher reichte es aus, eine einzelne Person oder Gruppe anzugeben (deren jedes Mitglied die Genehmigung erteilen kann), um eine Genehmigung zu erhalten. Jetzt können mehrere Regeln hinzugefügt werden, sodass der Merge-Request die Genehmigung von bestimmten Personen oder sogar von mehreren Mitgliedern einer bestimmten Gruppe erfordert. Darüber hinaus ist die Code Owners-Funktion in die Genehmigungsregeln integriert, die es einfach macht, die Genehmigung erteilende Person zu bestimmen.
Das ermöglicht es Organisationen, komplexe Genehmigungsprozesse zu implementieren, während die Einfachheit der einzigen GitLab-Anwendung erhalten bleibt, in der Aufgaben, Code, Pipelines und Überwachungsdaten sichtbar und verfügbar sind, um Entscheidungsprozesse zu unterstützen und den Genehmigungsprozess zu beschleunigen.
ChatOps ist jetzt Open Source.
GitLab ChatOps ist ein effektives Automatisierungstool, das es ermöglicht, jeden CI/CD-Job auszuführen und seinen Status direkt in Chat-Anwendungen wie Slack und Mattermost abzufragen. , war ChatOps Teil des GitLab Ultimate-Abonnements. Ausgehend von und , verlagern wir manchmal Funktionen nach unten und niemals nach oben.
Im Fall von ChatOps haben wir erkannt, dass diese Funktion für alle nützlich sein kann und dass das Mitwirken der Community dem Feature zugutekommen kann.
In GitLab 11.9 haben wir , und somit ist es jetzt kostenlos verfügbar für die Nutzung in selbstverwalteten GitLab Core und auf GitLab.com und offen für die Community.
Und vieles mehr!
In diesem Release gibt es so viele großartige Funktionen: zum Beispiel , und , — dass wir es kaum erwarten können, darüber zu berichten!
Mitarbeiter des Monats () ist Marcel Amirault ()
Marcel hat uns ständig geholfen, die Dokumentation von GitLab zu verbessern. Er um die Qualität und Benutzerfreundlichkeit unserer Dokumente zu verbessern. Domo arigato [vielen Dank (jp.) — Anmerkung der Übersetzer] Marcel, wir wissen das wirklich zu schätzen!
Die Hauptfunktionen, die in das GitLab 11.9-Release aufgenommen wurden
Erkennung von Geheimnissen und Anmeldedaten im Repository
(ULTIMATE, GOLD)
Entwickler übermitteln bisweilen unbeabsichtigt Geheimnisse und Anmeldedaten in entfernte Repositories. Wenn andere Personen Zugang zu dieser Quelle haben oder das Projekt öffentlich ist, wird vertrauliche Information offengelegt und kann von Angreifern genutzt werden, um auf Ressourcen wie Bereitstellungsumgebungen zuzugreifen.
GitLab 11.9 hat einen neuen Test — „Secret Detection“. Er scannt den Inhalt des Repositories nach API-Schlüsseln und anderen Informationen, die hier nicht sein sollten. GitLab zeigt die Ergebnisse im SAST-Bericht im Merge-Request-Widget, in den Pipeline-Berichten und auf den Sicherheitsdashboards an.
Wenn Sie SAST bereits für Ihre Anwendung aktiviert haben, müssen Sie nichts tun, genießen Sie einfach die Vorteile dieser neuen Funktion. Sie ist auch in der Konfiguration enthalten von Haus aus.
Regeln für das Genehmigen von Merge-Requests
(PREMIUM, ULTIMATE, SILVER, GOLD)
Code-Reviews sind ein wesentlicher Bestandteil jedes erfolgreichen Projekts, aber es ist oft unklar, wer für die Überprüfung der Änderungen verantwortlich sein sollte. Häufig ist die Teilnahme von Reviewern aus verschiedenen Teams wünschenswert: dem Entwicklerteam, dem User Interaction Team und dem Produktionsteam.
Genehmigungsregeln verbessern den Interaktionsprozess zwischen den Personen, die am Code-Review beteiligt sind: Es wird festgelegt, wer berechtigt ist, Genehmigungen zu erteilen und wie viele Genehmigungen erforderlich sind. Die Genehmigungsregeln werden im Merge-Request-Widget angezeigt, sodass der nächste Reviewer schnell ausgewählt werden kann.
In GitLab 11.8 waren die Genehmigungsregeln standardmäßig deaktiviert. Ab Version GitLab 11.9 sind sie standardmäßig verfügbar. In GitLab 11.3 führten wir die Option ein , um Mitglieder eines Teams zu benennen, die für bestimmte Codes innerhalb des Projekts verantwortlich sind. Die Funktion "Code Owners" ist in die Genehmigungsregeln integriert, sodass man die benötigten Personen für die Überprüfung von Änderungen schnell finden kann.
ChatOps in den Core verschieben
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ursprünglich in GitLab Ultimate 10.6 eingeführt, zieht ChatOps in GitLab Core um. GitLab ChatOps ermöglicht das Ausführen von GitLab CI-Jobs über Slack mit Hilfe von .
Wir öffnen den Quellcode dieser Funktion gemäß unserem Je mehr die Community sie nutzt, desto mehr wird sie beitragen.
Audit von Funktionsparametern
(PREMIUM, ULTIMATE, SILVER, GOLD)
Aktionen wie das Hinzufügen, Entfernen oder Ändern von Funktionseinstellungen werden jetzt im Audit-Log von GitLab protokolliert, sodass Sie sehen können, was und wann geändert wurde. Gab es einen Vorfall und Sie möchten wissen, was sich in letzter Zeit geändert hat? Oder müssen Sie im Rahmen eines Audits überprüfen, wie die Funktionseinstellungen geändert wurden? Das ist jetzt ganz einfach.
Behebung von Sicherheitsanfälligkeiten in Merge-Requests
(ULTIMATE, GOLD)
Um Sicherheitsanfälligkeiten im Code schnell zu beheben, muss der Prozess unkompliziert sein. Es ist wichtig, dass Sicherheitskorrekturen vereinfacht werden, damit sich die Entwickler auf ihre primären Aufgaben konzentrieren können. In GitLab 11.7 haben wir , die jedoch heruntergeladen, lokal angewendet und anschließend in das Remote-Repository übertragen werden musste.
In GitLab 11.9 ist dieser Prozess automatisiert. Beheben Sie Schwachstellen, ohne die Weboberfläche von GitLab zu verlassen. Der Merge-Request wird direkt aus dem Informationsfenster zu den Schwachstellen erstellt, und dieser neue Branch wird bereits die Korrektur enthalten. Überprüfen Sie, ob das Problem gelöst ist, und fügen Sie die Korrektur in den ursprünglichen Branch ein, wenn der Pipeline in Ordnung ist.
Anzeige der Scanning-Ergebnisse von Containern im Sicherheits-Dashboard der Gruppe
(ULTIMATE, GOLD)
Das Sicherheits-Dashboard der Gruppe ermöglicht es Fachleuten, sich auf die für die Arbeit wichtigsten Fragen zu konzentrieren und bietet einen klaren und detaillierten Überblick über alle potenziellen Schwachstellen, die Auswirkungen auf Anwendungen haben können. Deshalb ist es wichtig, dass das Dashboard alle notwendigen Informationen an einem Ort enthält und es den Benutzern ermöglicht, Daten im Detail zu prüfen, bevor sie Schwachstellen beheben.
In GitLab 11.9 wurden die Ergebnisse des Container-Scannings zum Dashboard hinzugefügt, zusätzlich zu den bereits vorhandenen SAST- und Abhängigkeits-Scan-Ergebnissen. Jetzt ist die gesamte Übersicht an einem Ort, unabhängig von der Quelle des Problems.
CI/CD-Vorlagen für Sicherheitsjobs
(ULTIMATE, GOLD)
Die Sicherheitsfunktionen von GitLab entwickeln sich sehr schnell weiter und erfordern ständig Aktualisierungen, um die Effizienz und den Schutz des Codes aufrechtzuerhalten. Die Definition von Jobs zu ändern ist schwierig, wenn man mehrere Projekte verwaltet. Und wir verstehen auch: Niemand möchte das Risiko eingehen, die neueste Version von GitLab zu verwenden, ohne sicherzustellen, dass sie vollständig mit der aktuellen Instanz von GitLab kompatibel ist.
Aus diesem Grund haben wir in GitLab 11.7 einen neuen Mechanismus zur Definition von Jobs mit .
Ab GitLab 11.9 werden wir integrierte Vorlagen für alle Sicherheitsjobs anbieten: beispielsweise sast und dependency_scanning, die mit der entsprechenden Version von GitLab kompatibel sind.
Binden Sie sie direkt in Ihre Konfiguration ein, und sie werden bei jedem Upgrade auf eine neue Version von GitLab zusammen mit dem System aktualisiert. Die Pipeline-Konfiguration bleibt dabei unverändert.
Die neue Methode zur Definition von Sicherheitsjobs ist offiziell und unterstützt keine anderen früheren Jobdefinitionen oder Codefragmente. Die Definition sollte so schnell wie möglich aktualisiert werden, um das neue Schlüsselwort
template. Die Unterstützung für andere Syntax kann in GitLab 12.0 oder in anderen zukünftigen Versionen entfernt werden.
Weitere Verbesserungen in GitLab 11.9
Antwort auf den Kommentar
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab gibt es Diskussionen zu Themen. Bisher musste der Benutzer, der den ursprünglichen Kommentar verfasst, von Anfang an entscheiden, ob er eine Diskussion benötigt.
Wir haben diese Einschränkung gelockert. Nehmen Sie beliebige Kommentare in GitLab (zu Aufgaben, Merge-Requests und Epics) und antworten Sie darauf, um damit die Diskussion zu beginnen. So interagieren die Teams organisierter.
Projektvorlagen für .NET, Go, iOS und Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Um es den Benutzern zu erleichtern, neue Projekte zu erstellen, bieten wir mehrere neue Projektvorlagen an:
- Starter , die eine grundlegende Anwendung mit CI umfasst.
- Eine betriebsbereite Vorlage, die kombiniert und GitLab CI/CD.
- , bereit für die erste Anpassung in GitLab. Bitte beachten Sie, dass zum Erstellen von iOS ein dedizierter MacOS-Runner erforderlich ist, daher müssen Sie Ihren eigenen Build-Server bereitstellen, wenn Sie ihn mit GitLab CI/CD verwenden möchten.
- sind für die Arbeit mit Netlify konfiguriert.
Fordern Sie die Genehmigung von Merge-Requests von Code Owners an
(PREMIUM, ULTIMATE, SILVER, GOLD)
Es ist nicht immer offensichtlich, wer einen Merge-Request genehmigt.
Jetzt unterstützt GitLab die Anforderung zur Genehmigung eines Merge-Requests, abhängig davon, welche Dateien die Anfrage ändert, mithilfe von . Code Owners werden über eine Datei namens CODEOWNERS, das Format ähnelt gitattributes.
Die Unterstützung für die automatische Zuweisung von Code Owners als für die Genehmigung von Merge-Requests Verantwortlichen wurde bereits in .
Verschieben von Dateien im Web-IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Jetzt können Sie, indem Sie eine Datei oder ein Verzeichnis umbenennen, es im Web-IDE an einen neuen Ort im Repository verschieben.
Labels in alphabetischer Reihenfolge
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab-Labels sind unglaublich vielseitig, und Teams finden ständig neue Verwendungszwecke dafür. Dementsprechend fügen Benutzer oft viele Labels zu einer Aufgabe, einem Merge-Request oder einem Epic hinzu.
In GitLab 11.9 haben wir die Verwendung von Labels etwas vereinfacht. In Aufgaben, Merge-Requests und Epics werden die die Sidebar anzeigenden Labels alphabetisch sortiert. Dies gilt auch für die Anzeige der Liste dieser Objekte.
Schnelle Kommentare beim Filtern der Aktionen zu einer Aufgabe
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kürzlich haben wir eine Funktion eingeführt, mit der Benutzer ihren Aktivitäten-Feed nach Aufgaben, Merge-Requests oder Epics filtern können, um sich ausschließlich auf Kommentare oder Systemnotizen zu konzentrieren. Diese Einstellung wird für jeden Benutzer im System gespeichert, und es kann vorkommen, dass ein Benutzer nicht versteht, dass er beim Durchsehen einer Aufgabe mehrere Tage später einen gefilterten Feed sieht. Er hat den Eindruck, dass er keinen Kommentar hinterlassen kann.
Wir haben diese Interaktion verbessert. Jetzt können Benutzer schnell in den Modus wechseln, der es ihnen ermöglicht, Kommentare zu hinterlassen, ohne den Feed wieder ganz nach oben scrollen zu müssen. Dies betrifft Aufgaben, Merge-Requests und Epics.
Änderung der Reihenfolge von untergeordneten Epics
(ULTIMATE, GOLD)
Kürzlich haben wir , die es ermöglichen, Epics von Epics zu verwenden (neben den untergeordneten Aufgaben von Epics).
Jetzt können die Reihenfolge der untergeordneten Epics von Epics einfach durch Drag-and-Drop geändert werden, so wie dies auch bei den untergeordneten Aufgaben der Fall ist. Teams können die Reihenfolge nutzen, um Prioritäten widerzuspiegeln oder den Arbeitsablauf zu bestimmen.
Benutzerdefinierte Systemnachrichten für Kopf- und Fußzeilen im Web und in E-Mails
(CORE, STARTER, PREMIUM, ULTIMATE)
Früher haben wir eine Funktion hinzugefügt, die es benutzerdefinierten Kopf- und Fußzeilen-Nachrichten ermöglicht, auf jeder Seite in GitLab angezeigt zu werden. Diese wurde positiv aufgenommen, und Teams nutzen sie, um wichtige Informationen auszutauschen: beispielsweise Systemnachrichten, die sich auf ihre Instanz von GitLab beziehen.
Wir freuen uns, diese Funktion im Core einzuführen, sodass jetzt noch mehr Menschen sie nutzen können. Außerdem ermöglichen wir Benutzern, dass sie auf Wunsch dieselben Nachrichten in allen über GitLab gesendeten E-Mails anzeigen lassen, um Konsistenz mit anderen Punkten der Benutzerinteraktion mit GitLab zu gewährleisten.
Filter für vertrauliche Aufgaben
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vertrauliche Aufgaben sind ein nützliches Tool für Teams, das es ermöglicht, in einem offenen Projekt geschlossene Diskussionen über sensible Themen zu führen. Insbesondere sind sie ideal zur Bearbeitung von Sicherheitsanfälligkeiten. Bisher war das Management von vertraulichen Aufgaben nicht besonders einfach.
In GitLab 11.9 wird die Liste der GitLab-Aufgaben jetzt nach vertraulichen oder nicht vertraulichen Aufgaben gefiltert. Dies betrifft auch die API-Suche nach Aufgaben.
Vielen Dank für den Beitrag von Robert Schilling ()!
Bearbeitung der Knative-Domain nach der Bereitstellung
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Die Angabe einer benutzerdefinierten Domain bei der Installation von Knative ermöglicht es, verschiedene serverlose Anwendungen/Funktionen mit einem einzigartigen Endpunkt bereitzustellen.
Nun ermöglicht die Kubernetes-Integration in GitLab, die benutzerdefinierte Domain nach der Bereitstellung von Knative im Kubernetes-Cluster zu ändern/aktualisieren.
Überprüfung des Formats des Kubernetes CA-Zertifikats
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beim Hinzufügen eines bestehenden Kubernetes-Clusters überprüft GitLab nun, ob das eingegebene CA-Zertifikat ein gültiges PEM-Format hat. Dies verhindert mögliche Fehler bei der Kubernetes-Integration.
Erweiterung des Vergleichswerkzeugs für Merge-Requests auf die gesamte Datei
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beim Durchsehen von Änderungen in einem Merge-Request kann das Vergleichswerkzeug jetzt für jede Datei erweitert werden, um die gesamte Datei für mehr Kontext anzuzeigen und Kommentare in unveränderten Zeilen zu hinterlassen.
Ausführung spezifischer Jobs für Merge-Requests nur bei Änderungen bestimmter Dateien
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab 11.6 wurde die Möglichkeit hinzugefügt, für Pipeline-Jobs zu definieren, damit Benutzer spezifische Aufgaben nur bei der Erstellung eines Merge-Requests ausführen können.
Nun erweitern wir diese Funktionalität: Es wurde eine Logik zur Verknüpfung hinzugefügt, , und Benutzer können bestimmte Jobs nur für Merge-Requests ausführen und nur bei Änderungen bestimmter Dateien.
Danke für den Beitrag von Hiroyuki Sato ()!
Automatisiertes Monitoring von GitLab mit Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana ist jetzt Teil unseres Omnibus-Pakets, was das Verständnis der Funktionsweise Ihrer Instanz vereinfacht.
Konfigurieren Sie grafana['enable'] = true in gitlab.rb, und Grafana wird verfügbar sein unter: https://your.gitlab.instance/-/grafana. In naher Zukunft werden wir auch das GitLab-Dashboard Anzeigen von Haupt-Epics in der Seitenleiste der Epics
Kürzlich haben wir
(ULTIMATE, GOLD)
, die es ermöglichen, Epics von Epics zu verwenden. In GitLab 11.9 haben wir den Mechanismus zum Anzeigen dieser Beziehung vereinfacht. Jetzt wird nicht nur der übergeordnete Epic des angegebenen Epics angezeigt, sondern der gesamte Baum der Epics in der rechten Seitenleiste. Es ist ersichtlich, ob diese Epics abgeschlossen oder nicht, und man kann sogar direkt zu ihnen navigieren.
Link zur neuen Aufgabe aus der verschobenen und geschlossenen Aufgabe
Link zur neuen Aufgabe aus der verschobenen und geschlossenen Aufgabe
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab können Aufgaben einfach über die Seitenleiste oder eine Schnellaktion in ein anderes Projekt verschoben werden. Im Hintergrund wird die bestehende Aufgabe geschlossen, und im Zielprojekt wird eine neue Aufgabe mit allen kopierten Daten erstellt, einschließlich systemweiter Notizen und Seitenleistenattributen. Das ist ein großartiges Feature.
Da es eine systemweite Notiz über die Verschiebung gibt, sind Benutzer, wenn sie eine geschlossene Aufgabe ansehen, verwirrt: Sie können nicht verstehen, dass die Aufgabe aufgrund ihrer Verschiebung geschlossen wurde.
In dieser Version weisen wir direkt auf dem Icon an der Oberseite der geschlossenen Aufgabe darauf hin, dass sie verschoben wurde, und fügen einen eingebetteten Link zur neuen Aufgabe hinzu, damit jeder, der auf die alte Aufgabe stößt, schnell zur neuen wechseln kann.
YouTrack-Integration
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab integriert sich mit vielen externen Ticketing-Systemen, was es Teams erleichtert, GitLab für andere Funktionen zu nutzen und gleichzeitig das von ihnen gewählte Task-Management-Tool beizubehalten.
In dieser Version haben wir die Möglichkeit hinzugefügt, YouTrack von JetBrains zu integrieren.
Wir danken Kotau Yauhen für seinen Beitrag ()!
Ändern der Dateibaumgröße im Merge-Request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beim Anzeigen von Änderungen im Merge-Request kann nun die Größe des Dateibaums geändert werden, um lange Dateinamen anzuzeigen oder Platz auf kleinen Bildschirmen zu sparen.
Wechsel zu den letzten Task-Boards
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Task-Boards sind sehr praktisch, und Teams erstellen mehrere Boards für jedes Projekt und jede Gruppe. Kürzlich haben wir ein Suchfeld hinzugefügt, um schnell alle interessierenden Boards zu filtern.
In GitLab 11.9 haben wir auch den Abschnitt Aktuell zum Dropdown-Menü hinzugefügt. So können Sie schnell zu den Boards wechseln, mit denen Sie kürzlich interagiert haben.
Möglichkeit für Entwickler, geschützte Branches zu erstellen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Geschützte Branches erlauben es nicht, unbegutachteten Code zu verschieben oder zu mergen. Wenn jedoch niemand berechtigt ist, geschützte Branches zu verschieben, kann auch niemand eine neue geschützte Branch erstellen, beispielsweise einen Release-Branch.
In GitLab 11.9 können Entwickler geschützte Branches aus bereits geschützten Branches über GitLab oder die API erstellen. Die Verwendung von Git zum Verschieben eines neuen geschützten Branches ist jedoch weiterhin eingeschränkt, um nicht versehentlich neue geschützte Branches zu erstellen.
Deduplication von Git-Objekten für öffentliche Branches (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Branching ermöglicht es jedem, an Projekten mit offenem Quellcode teilzunehmen: ohne Schreibberechtigung, einfach indem das Repository in ein neues Projekt kopiert wird. Das Speichern von vollständigen Kopien oft verzweigter Git-Repositories ist ineffizient. Nun, mit Git Alternativen teilen sich Zweige gemeinsame Objekte aus dem übergeordneten Projekt im Objektspeicher, um die Anforderungen an den Speicherplatz zu reduzieren.
Objekt-Pools für Branches werden nur für öffentliche Projekte erstellt, wenn ein gehashtes Speicherlager verbunden ist. Objekt-Pools werden mit Hilfe der Funktion object_pools.
Filterung der Merge-Requests nach zugewiesenen Genehmigenden
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Code-Review ist eine gängige Praxis für jedes erfolgreiche Projekt, aber es kann für den Reviewer schwierig sein, die Merge-Requests im Blick zu behalten.
In GitLab 11.9 wird die Liste der Merge-Requests nach dem zugewiesenen Genehmigenden gefiltert. So können Sie Merge-Requests finden, die Ihnen als Reviewer zugewiesen wurden.
Vielen Dank für den Beitrag von Glavin Wiechert ()!
Tastenkombinationen für die nächste und vorherige Datei im Merge-Request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beim Durchsehen der Änderungen im Merge-Request können Sie schnell zwischen Dateien wechseln mit ]oder j um zur nächsten Datei zu gelangen und [ oder k um zur vorherigen Datei zu gelangen.
Vereinfachung .gitlab-ci.yml für serverless Projekte
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Basierend auf der Funktionalität GitLab CI, das serverless Template gitlab-ci.yml wurde erheblich vereinfacht. Um in zukünftigen Releases neue Funktionen einzuführen, sind keine Änderungen an dieser Datei erforderlich.
Unterstützung für Hostnamen von Ingress
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Während des Deployments des Kubernetes Ingress Controllers kehren einige Plattformen zur IP-Adresse zurück (zum Beispiel GKE von Google), während andere auf den DNS-Namen (zum Beispiel EKS von AWS) zurückgreifen.
Unsere Kubernetes-Integration unterstützt nun beide Arten von Endpunkten zur Anzeige im Abschnitt clusters Projekt.
Vielen Dank für den Beitrag von Aaron Walker ()!
Zugangsbeschränkung für den Zugang zu JupyterHub nur für Gruppen-/Projektmitglieder
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Die Bereitstellung von JupyterHub mithilfe der GitLab-Integration mit Kubernetes ist eine großartige Möglichkeit, Jupyter Notebooks in großen Gruppen bereit zu stellen und zu nutzen. Außerdem ist es nützlich, den Zugang zu diesen zu kontrollieren, wenn vertrauliche oder persönliche Daten übertragen werden.
In GitLab 11.9 ist der Zugriff auf JupyterHub-Instanzen, die über Kubernetes bereitgestellt werden, auf Projektmitglieder mit der Zugriffsberechtigung „Entwickler“ (über Gruppe oder Projekt) beschränkt.
Anpassbare Zeiträume für Sicherheitsdashboard-Schemata
(ULTIMATE, GOLD)
Das Sicherheitsdashboard der Gruppe enthält ein Schwachstellenschema zur Überprüfung des aktuellen Sicherheitsstatus der Projekte der Gruppe. Dies ist sehr hilfreich für Sicherheitsleiter, um Prozesse anzupassen und das Team zu verstehen.
In GitLab 11.9 kann jetzt der Zeitraum dieses Schwachstellenschemas ausgewählt werden. Standardmäßig sind dies die letzten 90 Tage, es können jedoch auch Intervalle von 60 oder 30 Tagen festgelegt werden, je nach benötigtem Detaillierungsgrad.
Dies hat keinen Einfluss auf die Daten in Zählern oder Listen, sondern nur auf die angezeigten Datenpunkte im Diagramm.
Hinzufügen eines Auto DevOps-Bau-Jobs für Tags
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Der Auto DevOps-Bauprozess erstellt eine Version Ihrer Anwendung mithilfe des Dockerfiles des Projekts oder des Heroku-Baupakets.
In GitLab 11.9 erhält das erstellte Docker-Image, das in den Tagged-Pipeline integriert ist, einen Namen, der traditionell durch den Tag-Commit anstelle des SHA-Commits bezeichnet wird.
Danke für den Beitrag von Aaron Walker!
Update von Code Climate auf Version 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab verwendet um zu überprüfen, wie sich Änderungen auf den Zustand Ihres Codes und Projekts auswirken.
In GitLab 11.9 haben wir die Engine auf die neueste Version aktualisiert (), um die Vorteile zusätzlicher Sprache und Unterstützung für statische Analyse für GitLab Code Quality zu bieten.
Danke für den Beitrag von GitLab Core Teammitglied Takuiya Noguchi ()!
Skalierung und Scrollen des Metriken-Dashboards
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wenn man Performance-Anomalien untersucht, ist es oft hilfreich, sich bestimmte Teile einer bestimmten Metrik genauer anzusehen.
Mit GitLab 11.9 können Benutzer spezifische Zeiträume im Metriken-Dashboard skalieren, den gesamten Zeitraum scrollen und leicht zur Ansicht des ursprünglichen Zeitintervalls zurückkehren. Dies ermöglicht eine schnelle und einfache Untersuchung relevanter Ereignisse.
SAST für TypeScript
(ULTIMATE, GOLD)
— ist eine relativ neue Programmiersprache, die auf .
In GitLab 11.9 analysiert die Funktion für statische Anwendungssicherheitstests (SAST) TypeScript-Code und erkennt Sicherheitsanfälligkeiten, die im Merge-Requests-Widget, auf Pipeline-Ebene und im Sicherheits-Dashboard angezeigt werden. Die aktuelle Job-Definition sast muss nicht geändert werden und ist auch automatisch in .
SAST für mehrmodulige Maven-Projekte
(ULTIMATE, GOLD)
Maven-Projekte sind oft so organisiert, dass sie in einem Repository bündeln. Früher konnte GitLab solche Projekte nicht korrekt scannen, und Entwickler sowie Sicherheitsspezialisten erhielten keine Berichte über Schwachstellen.
GitLab 11.9 bietet erweiterte Unterstützung für die SAST-Funktion für diese spezifische Projektkonfiguration, wodurch die Möglichkeit besteht, sie hinsichtlich Schwachstellen im ursprünglichen Zustand zu testen. Dank der Flexibilität der Scanner wird die Konfiguration automatisch festgelegt, und es ist nicht notwendig, etwas zu ändern, um Ergebnisse für mehrmodulige Maven-Anwendungen anzuzeigen. Wie gewohnt sind auch ähnliche Verbesserungen im Rahmen von .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Heute haben wir auch GitLab Runner 11.9 veröffentlicht! GitLab Runner ist ein Open-Source-Projekt und wird verwendet, um CI/CD-Jobs auszuführen und die Ergebnisse an GitLab zurückzusenden.
Im Folgenden finden Sie einige Änderungen in GitLab Runner 11.9:
- .
- und .
- . Dies schließt auch .
- um zu unterstützen , die in GitLab 11.10 erscheinen werden.
- .
- .
- Verschieben mehrerer Skripte — einschließlich und — nach Go.
- .
- .
- .
Die vollständige Liste der Änderungen finden Sie im Änderungsprotokoll von GitLab Runner: .
Verbesserungen des GitLab-Schemas
(CORE, STARTER, PREMIUM, ULTIMATE)
Im GitLab-Chart wurden folgende Verbesserungen vorgenommen:
- Unterstützung für Google Cloud Memorystore hinzugefügt.
- Cron-Job-Einstellungen , da sie von mehreren Diensten genutzt werden.
- Das Repository wurde auf Version 2.7.1 aktualisiert.
- Ein neuer Parameter wurde hinzugefügt, der die Kompatibilität des GitLab-Registrierungsdienstes mit Docker-Versionen bis 1.10 gewährleistet. Um ihn zu aktivieren, setzen Sie
registry.compatibility.schema1.enabled: true.
Leistungsverbesserung
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wir verbessern die Leistung von GitLab mit jeder Veröffentlichung für Instanzen beliebiger Größen. Hier sind einige Verbesserungen in GitLab 11.9:
- .
- .
- .
- .
Verbesserungen von Omnibus
(CORE, STARTER, PREMIUM, ULTIMATE)
In GitLab 11.9 wurden folgende Omnibus-Verbesserungen implementiert:
- GitLab 11.9 umfasst , , dessen neueste Version MFA für die Team Edition, verbesserte Abbildungsperformance und vieles mehr bietet. Diese Version enthält ebenfalls ; ein Upgrade wird empfohlen.
- Ein neuer Parameter wurde hinzugefügt, der die Kompatibilität des GitLab-Registrierungsdienstes mit Docker-Versionen bis 1.10 gewährleistet. Um ihn zu aktivieren, setzen Sie
registry['compatibility_schema1_enabled'] = true in gitlab.rb. - Der GitLab-Registrierungsdienst exportiert jetzt Prometheus-Metriken und wird automatisch überwacht durch .
- Unterstützung für Google Cloud Memorystore hinzugefügt, die erfordert .
opensslaktualisiert auf Version 1.0.2r,nginx— auf Version 1.14.2,python— auf Version 3.4.9,jemalloc— auf Version 5.1.0,docutils— auf Version 0.13.1,gitlab-monitor— auf Version 3.2.0.
Veraltete Funktionen
GitLab Geo ermöglicht die verschlüsselte Speicherung in GitLab 12.0
GitLab Geo ist erforderlich um Wettrennen (Race Conditions) auf sekundären Knoten abzuschwächen. Dies wurde in .
In GitLab haben wir diese Anforderung in die Geo-Dokumentation aufgenommen: .
In GitLab sudo gitlab-rake gitlab:geo:check überprüft, ob die verschlüsselte Speicherung aktiviert ist und ob alle Projekte migriert werden. Siehe. . Wenn Sie Geo verwenden, führen Sie bitte diese Überprüfung durch und migrieren Sie so schnell wie möglich.
In GitLab stellbares Warnsignal wird auf der Seite angezeigt Admin-Bereich › Geo › Knoten, wenn die oben genannten Überprüfungen nicht aktiviert sind.
In GitLab Geo wird Anforderungen an die verschlüsselte Speicherung verwenden. Siehe. .
Löschdatum: 22. Juni 2019.
Hipchat-Integration
Hipchat . Darüber hinaus haben wir in Version 11.9 die bestehende Hipchat-Integrationsfunktion in GitLab entfernt. .
Löschdatum: Unterstützung für CentOS 6 für GitLab Runner mit Docker-Executor
GitLab Runner unterstützt CentOS 6 nicht, wenn Docker in GitLab 11.9 verwendet wird. Dies ist das Ergebnis einer Aktualisierung der zugrunde liegenden Docker-Bibliothek, die CentOS 6 nicht mehr unterstützt. Weitere Informationen finden Sie in
diesem Ticket. .
Löschdatum: Unterstützung für CentOS 6 für GitLab Runner mit Docker-Executor
Veraltete Pfade für den Legacy-Code von GitLab Runner
Ab GitLab 11.9 verwendet GitLab Runner . Und weitere Einzelheiten finden Sie in
In GitLab 11.0 haben wir das Konfigurationsschema für den Metrik-Server des GitLab Runners geändert. metrics_server wird zugunsten von listen_address in GitLab 12.0 entfernt. Weitere Informationen finden Sie in , was zu neuen Einstellungen für .
In Version 11.3 begann GitLab Runner, eine Übersicht über Änderungen und Anleitungen zur Migration auf die neue Konfiguration. Weitere Informationen finden Sie in . In Diese Pfade sind in GitLab 12.0 nicht mehr verfügbar. Als Benutzer müssen Sie nichts ändern, stellen Sie jedoch sicher, dass Ihre GitLab-Instanz bei einem Upgrade auf GitLab Runner 12.0 mit Version 11.9+ läuft. .
) für sein
Löschdatum: 22. Juni 2019.
Veralteter Parameter für die Einstiegspunktfunktion für GitLab Runner
In 11.4 wurde der Funktionsparameter für GitLab Runner eingeführt um Probleme wie die folgenden zu beheben und .
In GitLab 12.0 werden wir auf das richtige Verhalten umschalten, als ob der Funktionsparameter deaktiviert wäre. Weitere Informationen finden Sie in .
Löschdatum: 22. Juni 2019.
Veraltete Unterstützung für Linux-Distributionen, die das EOL erreicht haben, für GitLab Runner
Einige Linux-Distributionen, auf denen GitLab Runner installiert werden kann, haben das Supportende erreicht.
In GitLab 12.0 wird GitLab Runner keine Pakete mehr für solche Linux-Distributionen verteilen. Eine vollständige Liste der nicht mehr unterstützten Distributionen finden Sie in unserem . Danke an Javier Ardó (In GitLab 12.0 wird GitLab Runner mit neuen Befehlen ausgeführt. Dies betrifft nur Benutzer, die Überschreibungen vornehmen. !
Löschdatum: 22. Juni 2019.
Entfernung alter GitLab Runner Helper-Befehle
Im Rahmen der Bemühungen zur Unterstützung mussten einige alte Befehle, die für .
. . Weitere Informationen finden Sie in .
Löschdatum: 22. Juni 2019.
Entwickler können Git-Tags in GitLab 11.10 löschen
Das Löschen oder Bearbeiten von Versionshinweisen für Git-Tags in ungeschützten Zweigen war historisch gesehen nur auf .
Da Entwickler Tags hinzufügen sowie ungeschützte Zweige ändern und löschen können, sollten sie in der Lage sein, Git-Tags zu löschen. In GitLab 11.10 in unserem Berechtigungsmodell, um den Workflow zu verbessern und Entwicklern zu helfen, Tags besser und effektiver zu nutzen.
Wenn Sie diese Einschränkung für Betreuer und Eigentümer beibehalten möchten, verwenden Sie .
Löschdatum: 22. April 2019
Unterstützung von Prometheus 1.x in Omnibus GitLab
Ab GitLab , ist die integrierte Version von Prometheus 1.0 aus Omnibus GitLab ausgeschlossen. . Das Format der Metriken ist jedoch mit Version 1.0 nicht kompatibel. Bestehende Versionen können auf 2.0 aktualisiert werden und bei Bedarf Daten .
In GitLab-Version wird Prometheus 2.0 automatisch installiert, wenn noch kein Update erfolgt ist. Daten aus Prometheus 1.0 gehen verloren, da sie nicht übertragen werden.
Löschdatum: 22. Juni 2019.
TLS v1.1
Ab GitLab um die Sicherheit zu erhöhen. Dies beseitigt zahlreiche Probleme, einschließlich Heartbleed, und macht GitLab „out of the box“ kompatibel mit dem PCI DSS 3.1 Standard.
Um TLS v1.1 sofort zu deaktivieren, setzen Sie nginx['ssl_protocols'] = "TLSv1.2" in gitlab.rband und führen Sie aus gitlab-ctl reconfigure.
Löschdatum: 22. Juni 2019.
OpenShift-Vorlage zur Installation von GitLab
Offiziell — die empfohlene Methode für den Betrieb von GitLab auf Kubernetes, einschließlich .
zur Installation von GitLab ist veraltet und wird nicht mehr unterstützt in .
Löschdatum: 22. Juni 2019.
Frühere Definitionen von Sicherheitsjobs
Mit der Einführung von veralten alle früheren Jobdefinitionen und werden in GitLab 12.0 oder später entfernt.
Aktualisieren Sie die Jobdefinitionen, um die neue Syntax zu verwenden und von allen neuen Sicherheitsfunktionen, die GitLab bietet, zu profitieren.
Abmeldedatum: 22. Juni 2019.
Bereich Systeminformationen im Administrationsbereich
GitLab stellt Informationen über Ihre GitLab-Instanz in admin/system_info, zur Verfügung, aber diese Informationen können ungenau sein.
Wir aus dem Administrationsbereich in GitLab 12.0 entfernen und empfehlen die Verwendung von .
Löschdatum: 22. Juni 2019.
Quelle: habr.com
