Schnelle Erkennung von Geheimnislecks
Es scheint ein kleiner Fehler zu sein – Anmeldedaten versehentlich in ein öffentliches Repository zu übertragen. Doch die Konsequenzen können schwerwiegend sein. Sobald ein Angreifer Ihr Passwort oder Ihren API-Schlüssel erhält, kann er Ihr Konto übernehmen, Sie ausschließen und Ihr Geld missbrauchen. Zudem kann der Dominoeffekt eintreten: Der Zugriff auf ein Konto öffnet den Weg zu anderen. Die Einsätze sind hoch, weshalb es äußerst wichtig ist, so schnell wie möglich von einer Geheimnisleckage zu erfahren.
In diesem Release präsentieren wir die Option im Rahmen unserer SAST-Funktionalität. Jeder Commit wird in einem CI/CD-Job auf Geheimnisse gescannt. Gibt es ein Geheimnis, erhält der Entwickler eine Warnung im Merge-Request. Er widerruft sofort die kompromittierten Anmeldedaten und erstellt neue.
Sicherstellung eines korrekten Änderungsmanagements
Mit dem Wachstum und der Komplexität wird es zunehmend schwieriger, die Konsistenz zwischen den verschiedenen Teilen einer Organisation aufrechtzuerhalten. Je mehr Benutzer die Anwendung hat und je höher der Umsatz ist, desto gravierender sind die Folgen eines Merge mit fehlerhaftem oder unsicherem Code. Für viele Organisationen ist die Sicherstellung eines ordnungsgemäßen Überprüfungsprozesses vor dem Code-Merge ein entscheidendes Anliegen, da die Risiken sehr hoch sind.
GitLab 11.9 bietet mehr Kontrolle und eine effektivere Struktur — dank . Früher war es ausreichend, eine bestimmte Person oder Gruppe anzugeben (deren Mitglieder Genehmigungen erteilen konnten). Jetzt können mehrere Regeln hinzugefügt werden, damit ein Merge-Request die Genehmigung von spezifischen Personen oder sogar von mehreren Mitgliedern einer bestimmten Gruppe erfordert. Darüber hinaus ist die Funktion der Genehmiger in die Regeln integriert, die es erleichtert, den genehmigenden Verantwortlichen zu identifizieren.
Dies ermöglicht es Organisationen, komplexe Entscheidungsprozesse umzusetzen, während die Einfachheit der einzigen GitLab-Anwendung gewahrt bleibt, in der Aufgaben, Code, Pipelines und Überwachungsdaten sichtbar und verfügbar sind, um Entscheidungen zu treffen und den Entscheidungsprozess zu beschleunigen.
ChatOps ist jetzt Open Source.
GitLab ChatOps ist ein effektives Automatisierungstool, mit dem Sie jeden CI/CD-Job ausführen und seinen Status direkt in Chat-Anwendungen wie Slack und Mattermost abfragen können. war ChatOps Teil des GitLab Ultimate-Abonnements. Ausgehend von и , verlagern wir manchmal Funktionen nach unten, jedoch niemals nach oben.
Im Fall von ChatOps haben wir erkannt, dass diese Funktion für alle nützlich sein kann, und dass die Beteiligung der Community dem Feature zugutekommen könnte.
In GitLab 11.9 haben wir , und damit ist es jetzt kostenlos für die Nutzung in selbstverwalteten GitLab Core und auf GitLab.com verfügbar und für die Community offen.
Und vieles mehr!
In diesem Release gibt es so viele großartige Funktionen: zum Beispiel, , и , — worüber wir Ihnen unbedingt berichten möchten!
Mitarbeiter des Monats () ist Marcel Amirault ()
Marcel hat uns ständig dabei geholfen, die Dokumentation von GitLab zu verbessern. Er um die Qualität und Benutzerfreundlichkeit unserer Dokumente zu erhöhen. Domo arigato [vielen Dank (jap.) — Anm. d. Übers.], Marcel, wir schätzen das sehr!
Hauptfunktionen des GitLab 11.9 Releases
Erkennung von Geheimnissen und Anmeldedaten im Repository
(ULTIMATE, GOLD)
Entwickler geben manchmal unbeabsichtigt Geheimnisse und Anmeldedaten in entfernte Repositories weiter. Wenn andere Personen Zugriff auf diese Quelle haben oder wenn das Projekt öffentlich ist, wird vertrauliche Information offengelegt und kann von Angreifern genutzt werden, um auf Ressourcen wie Bereitstellungsumgebungen zuzugreifen.
GitLab 11.9 bietet einen neuen Test — „Secret Detection“. Er scannt den Inhalt des Repositories auf der Suche nach API-Schlüsseln und anderen Informationen, die dort nicht sein sollten. GitLab zeigt die Ergebnisse in einem SAST-Bericht im Merge-Request-Widget, in Pipeline-Berichten und auf Sicherheitsdashboards an.
Wenn Sie SAST bereits für Ihre Anwendung aktiviert haben, müssen Sie nichts weiter tun, sondern können einfach die Vorteile dieser neuen Funktion nutzen. Sie ist auch in der Konfiguration enthalten. als Standard.
Regeln zur Genehmigung von Merge-Requests
(PREMIUM, ULTIMATE, SILVER, GOLD)
Code-Reviews sind ein wesentlicher Bestandteil jedes erfolgreichen Projekts, aber es ist nicht immer klar, wer für die Überprüfung der Änderungen zuständig sein sollte. Oftmals ist es wünschenswert, dass Reviewer aus verschiedenen Teams teilnehmen: dem Entwicklerteam, dem Benutzerinteraktionsteam und dem Produktionsteam.
Die Genehmigungsregeln verbessern den Interaktionsprozess zwischen den Personen, die an der Code-Überprüfung beteiligt sind: Sie legen den Kreis der autorisierten Genehmigenden und die Mindestanzahl an Genehmigungen fest. Die Genehmigungsregeln werden im Widget des Merge-Requests angezeigt, sodass der nächste Reviewer schnell zugeordnet werden kann.
In GitLab 11.8 waren die Genehmigungsregeln standardmäßig deaktiviert. Ab der Version GitLab 11.9 sind sie standardmäßig verfügbar. In GitLab 11.3 haben wir die Option eingeführt zum Kennzeichnen der Teammitglieder, die für bestimmte Codes innerhalb des Projekts verantwortlich sind. Die Funktion der Code-Eigentümer ist in die Genehmigungsregeln integriert, sodass man immer schnell die richtigen Personen finden kann, um Änderungen zu überprüfen.
ChatOps in den Core verschieben
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ursprünglich in GitLab Ultimate 10.6 eingeführt, ist ChatOps in den GitLab Core übergegangen. GitLab ChatOps ermöglicht das Ausführen von GitLab CI-Jobs über Slack mit der Funktion .
Wir öffnen den Quellcode dieser Funktion gemäß unserem . Durch häufigere Nutzung wird die Community stärkeren Einfluss nehmen.
Audit von Funktionseinstellungen.
(PREMIUM, ULTIMATE, SILVER, GOLD)
Operationen wie das Hinzufügen, Entfernen oder Ändern von Funktionseinstellungen werden jetzt im Audit-Protokoll von GitLab aufgezeichnet, sodass Sie sehen können, was und wann geändert wurde. Hatten Sie einen Vorfall und möchten wissen, was sich kürzlich geändert hat? Oder müssen Sie einfach im Rahmen eines Audits überprüfen, wie die Funktionseinstellungen geändert wurden? Das ist jetzt ganz einfach.
Behebung von Schwachstellen in Merge-Requests
(ULTIMATE, GOLD)
Um Schwachstellen im Code schnell zu beheben, muss der Prozess einfach sein. Es ist wichtig, die Sicherheitskorrekturen zu vereinfachen, damit sich die Entwickler auf ihre Kernaufgaben konzentrieren können. In GitLab 11.7 haben wir , die heruntergeladen, lokal angewendet und dann die Änderungen in das entfernte Repository verschoben werden musste.
In GitLab 11.9 ist dieser Prozess automatisiert. Beheben Sie Schwachstellen, ohne die GitLab-Weboberfläche zu verlassen. Ein Merge-Request wird direkt aus dem Informationsfenster über die Schwachstellen erstellt, und dieser neue Branch enthält bereits die Korrektur. Überprüfen Sie, ob das Problem behoben ist, und fügen Sie die Korrektur in den Hauptbranch ein, wenn der Pipeline-Status in Ordnung ist.
Anzeige der Ergebnisse von Container-Scans im Sicherheits-Dashboard der Gruppe
(ULTIMATE, GOLD)
Die Sicherheitsübersicht der Gruppe ermöglicht es Fachleuten, sich auf die wichtigsten Aspekte ihrer Arbeit zu konzentrieren, indem sie einen klaren und detaillierten Überblick über alle potenziellen Schwachstellen bietet, die die Anwendungen beeinträchtigen könnten. Daher ist es wichtig, dass die Übersicht alle notwendigen Informationen an einem Ort bereitstellt und den Nutzern erlaubt, die Daten gründlich zu überprüfen, bevor sie Schwachstellen beheben.
In GitLab 11.9 wurden die Ergebnisse der Container-Scans in das Dashboard integriert, zusätzlich zu den bereits vorhandenen SAST- und Abhängigkeitsscans. 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ändige Aktualisierungen, um die Effektivität und den Schutz des Codes aufrechtzuerhalten. Die Definition von Jobs zu ändern, ist schwierig, wenn man mehrere Projekte verwaltet. Und wir verstehen auch: Keiner möchte das Risiko eingehen, die neueste Version von GitLab zu verwenden, ohne sicherzustellen, dass sie vollständig mit der aktuellen GitLab-Instanz kompatibel ist.
Genau aus diesem Grund haben wir in GitLab 11.7 einen neuen Mechanismus zur Definition von Jobs eingeführt, mit dem .
Ab GitLab 11.9 bieten wir integrierte Vorlagen für alle Sicherheitsjobs an: beispielsweise sast и dependency_scanning, die mit der entsprechenden Version von GitLab kompatibel sind.
Fügen Sie sie direkt in Ihre Konfiguration ein, und sie werden bei jedem Update auf eine neue GitLab-Version 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 früheren Definitionen von Jobs oder Codefragmenten. Aktualisieren Sie so schnell wie möglich die Definition, um das neue Schlüsselwort zu verwenden.
templateDie Unterstützung eines anderen Syntax kann in GitLab 12.0 oder zukünftigen Versionen entfernt werden.
Weitere Verbesserungen in GitLab 11.9
Antwort auf einen 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 hat, von Anfang an entscheiden, ob er eine Diskussion möchte.
Wir haben diese Einschränkung gelockert. Nehmen Sie einen Kommentar in GitLab (zu Aufgaben, Merge-Anfragen und Epics) und antworten Sie darauf, um damit eine Diskussion zu beginnen. So arbeiten die Teams organisierter zusammen.
Projektvorlagen für .NET, Go, iOS und Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Um unseren Nutzern die Erstellung neuer Projekte zu erleichtern, bieten wir mehrere neue Projektvorlagen an:
- Einsteiger , die eine grundlegende Anwendung mit CI enthält.
- Eine einsatzbereite Vorlage, die kombiniert und GitLab CI/CD.
- , bereit für erste Anpassungen in GitLab. Bitte beachten Sie, dass für den Aufbau von iOS ein dedizierter MacOS-Runner erforderlich ist, und Sie müssen Ihren eigenen Build-Server bereitstellen, wenn Sie ihn mit GitLab CI/CD verwenden möchten.
- sind für die Verwendung mit Netlify konfiguriert.
Fordern Sie die Genehmigung von Merge-Requests von den Code-Eigentümern an
(PREMIUM, ULTIMATE, SILVER, GOLD)
Es ist nicht immer offensichtlich, wer einen Merge-Request genehmigt.
Jetzt unterstützt GitLab die Anforderung, einen Merge-Request basierend auf den geänderten Dateien genehmigen zu müssen, mit Hilfe von . Code-Eigentümer werden über eine Datei namens CODEOWNERSzugewiesen, das Format ähnelt gitattributes..
Die Unterstützung für die automatische Zuordnung von Code-Eigentümern als Verantwortliche für die Genehmigung von Merge-Requests wurde bereits in .
Verschieben von Dateien im Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nachdem Sie die Datei oder das Verzeichnis umbenannt haben, können Sie es mit dem Web IDE an den neuen Speicherort 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 Anwendungsfälle dafür. Daher fügen Benutzer oft viele Labels zu einem Issue, Merge-Request oder Epic hinzu.
In GitLab 11.9 haben wir die Verwendung von Labels etwas vereinfacht. In Issues, Merge-Requests und Epics werden die Labels in der Seitenleiste alphabetisch angeordnet. Das gilt auch für die Ansicht der Liste dieser Objekte.
Schnelle Kommentare beim Filtern von Aktivitäten zu einem Issue
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kürzlich haben wir eine Funktion eingeführt, mit der Benutzer den Aktivitätsfeed nach Issues, Merge-Requests oder Epics filtern können, um sich nur auf Kommentare oder Systemhinweise zu konzentrieren. Diese Einstellung wird für jeden Benutzer im System gespeichert, und es kann passieren, dass ein Benutzer nicht versteht, dass er beim Durchsehen eines Issues mehrere Tage später einen gefilterten Feed sieht. Er hat das Gefühl, dass er keinen Kommentar hinterlassen kann.
Wir haben dieses Interaktionsformat verbessert. Nun können Benutzer schnell in den Modus wechseln, der das Hinterlassen von Kommentaren ermöglicht, ohne den Feed bis ganz nach oben scrollen zu müssen. Dies gilt für Aufgaben, Merge-Requests und Epics.
Ändern der Reihenfolge von untergeordneten Epics
(ULTIMATE, GOLD)
Kürzlich haben wir veröffentlicht , die es ermöglichen, Epics von Epics (neben untergeordneten Aufgaben der Epics) zu verwenden.
Jetzt können die Reihenfolgen der untergeordneten Epics einfach per Drag & Drop wie bei untergeordneten Aufgaben geändert werden. Teams können die Reihenfolge nutzen, um Prioritäten zu reflektieren oder den Ablauf der Arbeiten festzulegen.
Benutzerdefinierte systemweite Kopf- und Fußzeilenmeldungen im Internet und in E-Mails
Verbindung des Atlassian-Kontos
Zuvor haben wir eine Funktion hinzugefügt, die es ermöglicht, dass benutzerdefinierte Kopf- und Fußzeilenmeldungen auf jeder Seite in GitLab sichtbar sind. Sie wurde herzlich aufgenommen, und Teams verwenden sie, um wichtige Informationen auszutauschen, wie zum Beispiel systembezogene Nachrichten, die sich auf ihre GitLab-Instanz beziehen.
Wir freuen uns, dieses Feature in Core einzuführen, sodass nun noch mehr Menschen davon profitieren können. Außerdem erlauben wir Nutzern, auf Wunsch dieselben Nachrichten in allen über GitLab gesendeten E-Mails anzuzeigen, um die Konsistenz mit anderen Kontaktpunkten des Nutzers zu gewährleisten.
Filter für vertrauliche Aufgaben
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vertrauliche Aufgaben sind ein nützliches Werkzeug für Teams, das es ermöglicht, in einem offenen Projekt geschlossene Diskussionen über sensible Themen zu führen. Insbesondere eignen sie sich hervorragend für die Arbeit an Sicherheitsanfälligkeiten. Bislang war das Management vertraulicher Aufgaben nicht besonders einfach.
In GitLab 11.9 wird die Liste der Aufgaben nun nach vertraulichen oder nicht vertraulichen Aufgaben gefiltert. Dies gilt auch für die API-Suche nach Aufgaben.
Wir danken Robert Schilling für seinen Beitrag ()!
Bearbeitung der Knative-Domain nach der Bereitstellung
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bei der Angabe einer benutzerdefinierten Domain bei der Installation von Knative können verschiedene serverless Anwendungen/Funktionen mit einem einzigartigen Endpunkt bereitgestellt werden.
Jetzt ermöglicht die Integration von Kubernetes in GitLab, die benutzerdefinierte Domain nach dem Deployment von Knative im Kubernetes-Cluster zu ändern oder zu aktualisieren.
Überprüfung des Zertifikatsformat des Kubernetes-CA
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beim Hinzufügen eines bestehenden Kubernetes-Clusters überprüft GitLab jetzt, ob das eingegebene CA-Zertifikat im gültigen PEM-Format vorliegt. Dadurch werden mögliche Integrationsfehler mit Kubernetes vermieden.
Erweiterung des Vergleichstools für Merge-Requests auf die gesamte Datei
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beim Durchsehen der Änderungen in einem Merge-Request kann das Vergleichstool 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 bestimmter Jobs für Merge-Requests nur bei Änderungen an bestimmten 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 bestimmte Aufgaben nur bei Erstellung eines Merge-Requests ausführen können.
Jetzt erweitern wir diese Funktionalität: Es wurde eine Verknüpfungslogik hinzugefügt , sodass Benutzer bestimmte Jobs nur für Merge-Requests und nur bei Änderungen an bestimmten Dateien ausführen können.
Danke für den Beitrag von Hiroyuki Sato ()!
Automatische Überwachung von GitLab mit Grafana
Verbindung des Atlassian-Kontos
Grafana ist jetzt in unser Omnibus-Paket integriert, was das Verständnis der Funktionsweise Ihrer Instanz erleichtert.
Konfigurieren Sie grafana['enable'] = true in gitlab.rb, und Grafana wird unter folgender Adresse verfügbar sein: https://your.gitlab.instance/-/grafana. In naher Zukunft werden wir auch „out of the box“ einführen.
Anzeigen der Haupt-Epics in der Seitenleiste der Epics
(ULTIMATE, GOLD)
Kürzlich haben wir , die es ermöglichen, Epics von Epics zu verwenden.
In GitLab 11.9 haben wir den Mechanismus zur Anzeige dieser Beziehung vereinfacht. Nun wird nicht nur das übergeordnete Epic des angegebenen Epics angezeigt, sondern auch der gesamte Baum der Epics in der rechten Seitenleiste. Man sieht, ob diese Epics geschlossen sind oder nicht, und man kann sogar direkt zu ihnen wechseln.
Link zu einer neuen Aufgabe aus einer verschobenen und geschlossenen Aufgabe
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In GitLab können Sie eine Aufgabe einfach in ein anderes Projekt verschieben, indem Sie die Seitenleiste oder eine Schnellaktion verwenden. Im Hintergrund wird die bestehende Aufgabe geschlossen, und in dem Zielprojekt wird eine neue Aufgabe mit allen kopierten Daten erstellt, einschließlich systemeigener Notizen und Anmerkungen in der Seitenleiste. Das ist eine großartige Funktion.
Da es eine systematische Anmerkung zur Verschiebung gibt, sind Benutzer während der Ansicht einer geschlossenen Aufgabe verwirrt: sie können nicht verstehen, dass die Aufgabe wegen der Verschiebung geschlossen wurde.
In dieser Version zeigen wir nun direkt auf dem Symbol oben auf der Seite der geschlossenen Aufgabe an, dass sie verschoben wurde, und beinhalten einen integrierten Link zur neuen Aufgabe, damit jeder, der die alte gesehen hat, schnell zur neuen wechseln kann.
YouTrack-Integration
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab integriert sich mit vielen externen Aufgabenverfolgungssystemen, was es den Teams erleichtert, GitLab für andere Funktionen zu nutzen, während sie ihr gewähltes Aufgabenmanagement-Tool beibehalten.
In dieser Version haben wir die Möglichkeit zur Integration von YouTrack von JetBrains hinzugefügt.
Wir danken Kotau Yauhen für seinen Beitrag ()!
Ändern der Dateibäume im Merge-Request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beim Anzeigen der Änderungen eines Merge-Requests kann der Dateibaum jetzt angepasst werden, um lange Dateinamen anzuzeigen oder Platz auf kleinen Bildschirmen zu sparen.
Wechsel zu den letzten Aufgabenpanels
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Task-Boards sind äußerst praktisch, und Teams erstellen mehrere Boards für jedes Projekt und jede Gruppe. Kürzlich haben wir ein Suchfeld hinzugefügt, um alle für Sie interessanten Boards schnell zu filtern.
In GitLab 11.9 haben wir auch den Abschnitt Neueste im Dropdown-Menü eingeführt. So können Sie schnell zu den Boards wechseln, mit denen Sie zuletzt interagiert haben.
Die Möglichkeit für Entwickler, geschützte Branches zu erstellen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Geschützte Branches erlauben es nicht, nicht überprüften Code zu verschieben oder zu mergen. Wenn niemand das Verschieben geschützter Branches erlaubt ist, kann auch niemand einen neuen geschützten Branch erstellen: zum Beispiel, 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 Nutzung von Git zum Verschieben eines neuen geschützten Branchs bleibt eingeschränkt, um versehentliches Erstellen neuer geschützter Branches zu vermeiden.
Deduplication von Git-Objekten für offene Branches (Beta)
Verbindung des Atlassian-Kontos
Branches ermöglichen es jedem, an Open-Source-Projekten teilzunehmen: ohne Schreibrechte, einfach indem das Repository in ein neues Projekt kopiert wird. Das Speichern vollständiger Kopien häufig verzweigter Git-Repositories ist ineffizient. Jetzt mit Git. Alternativen Branches teilen sich gemeinsame Objekte aus dem übergeordneten Projekt im Objektpool, um den Speicherbedarf zu reduzieren.
Objektpools für Branches werden nur für öffentliche Projekte erstellt, wenn ein hashiertes Speicher-Backend angeschlossen ist. Objektpools werden durch Aktivieren der Funktionseinstellung aktiviert. object_pools.
Filtern der Merge-Requests nach zugewiesenen Genehmigenden
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Code-Review ist eine gängige Praxis in jedem erfolgreichen Projekt, aber es kann für den Reviewer schwierig sein, Merge-Requests nachzuvollziehen.
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.
Danke 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 ]или j um zur nächsten Datei zu gelangen und [ или k um zur vorherigen Datei zu gelangen.
Vereinfachung .gitlab-ci.yml für serverlose Projekte
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Basierend auf der Funktionalität von GitLab CI, serverloses Template gitlab-ci.yml wurde erheblich vereinfacht. Um in zukünftigen Releases neue Funktionen einzuführen, müssen keine Änderungen an dieser Datei vorgenommen werden.
Unterstützung für Hostnamen-Ingress
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beim Deployen des Kubernetes Ingress-Controllers verwenden einige Plattformen die IP-Adresse (z. B. GKE von Google), während andere den DNS-Namen verwenden (z. B. EKS von AWS).
Unsere Kubernetes-Integration unterstützt jetzt beide Typen von Endpunkten zur Anzeige im Abschnitt Cluster des Projekts bekanntgaben.
Wir danken Aaron Walker für seinen Beitrag ()!
Zugangsbegrenzung für den Einstieg in JupyterHub nur für Gruppen-/Projektmitglieder
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Das Deployen von JupyterHub mit der GitLab-Integration für Kubernetes ist eine hervorragende Möglichkeit, Jupyter Notebooks in großen Gruppen zu verwalten und zu nutzen. Es ist auch nützlich, den Zugang zu kontrollieren, wenn vertrauliche oder personenbezogene Daten übertragen werden.
In GitLab 11.9 ist der Zugriff auf JupyterHub-Instanzen, die über Kubernetes bereitgestellt werden, auf Projektmitglieder mit Zugriffsrecht „Entwickler“ (über Gruppe oder Projekt) beschränkt.
Anpassbare Zeiträume für die Sicherheitsdashboard-Schemata
(ULTIMATE, GOLD)
Das Sicherheitsdashboard der Gruppe beinhaltet ein Schwachstellenschema zur Übersicht über den aktuellen Sicherheitsstatus der Projekte der Gruppe. Dies ist für Sicherheitsverantwortliche sehr hilfreich, um Prozesse anzupassen und zu verstehen, wie das Team arbeitet.
In GitLab 11.9 können Sie nun den Zeitrahmen dieses Schwachstellenschemas auswählen. Standardmäßig sind dies die letzten 90 Tage, aber Sie können auch einen Zeitraum von 60 oder 30 Tagen festlegen, je nach gewünschtem Detaillierungsgrad.
Dies hat keinen Einfluss auf die Daten in den Zählern oder der Liste, nur auf die Datenpunkte, die im Schema angezeigt werden.
Hinzufügen eines Auto DevOps-Build-Jobs für Tags
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Die automatische Build-Stufe von Auto DevOps erstellt einen Build Ihrer Anwendung unter Verwendung der Dockerfile des Projekts oder des Heroku-Build-Pakets.
In GitLab 11.9 erhält das im Tag-Pipeline eingebettete Docker-Image einen Namen, der den traditionellen Namenskonventionen entspricht, indem der Tag-Commit anstelle des SHA-Commits verwendet wird.
Vielen Dank für den Beitrag von Aaron Walker!
Update von Code Climate auf Version 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab nutzt um zu überprüfen, wie Änderungen den Zustand Ihres Codes und Projekts beeinflussen.
In GitLab 11.9 haben wir die Engine auf die neueste Version aktualisiert (), um die Vorteile zusätzlicher Sprache und der Unterstützung statischer Analysen für die GitLab Code-Qualität zu bieten.
Vielen Dank für den Beitrag von GitLab Core-Teammitglied Takuya Noguti ()!
Skalierung und Scrollen des Metrik-Dashboards
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Bei der Untersuchung von Leistungsanomalien ist es oft hilfreich, einen genaueren Blick auf bestimmte Teile einer bestimmten Metrik zu werfen.
Mit GitLab 11.9 können Benutzer bestimmte Zeitperioden im Metrik-Dashboard skalieren, den gesamten Zeitraum scrollen und leicht zur Ansicht des ursprünglichen Zeitintervalls zurückkehren. Dies ermöglicht ein einfaches und schnelles Erkunden der relevanten Ereignisse.
SAST für TypeScript
(ULTIMATE, GOLD)
ist eine relativ neue Programmiersprache auf Basis von .
In GitLab 11.9 analysiert die Funktion zur statischen Anwendungssicherheit (SAST) und erkennt Schwachstellen im TypeScript-Code, indem sie diese im Merge-Request-Widget, im Pipeline-Level und im Sicherheitsdashboard anzeigt. Die aktuelle Jobdefinition sast muss nicht geändert werden und ist ebenfalls automatisch aktiviert in .
SAST für mehrmodulare Maven-Projekte.
(ULTIMATE, GOLD)
Maven-Projekte sind häufig so organisiert, dass sie in einem Repository zusammenfassen. Zuvor konnte GitLab solche Projekte nicht korrekt scannen, was bedeutete, dass Entwickler und Sicherheitsspezialisten keine Berichte über Schwachstellen erhielten.
GitLab 11.9 bietet eine erweiterte Unterstützung für die SAST-Funktion in dieser speziellen Projektkonfiguration und ermöglicht es, sie auf Schwachstellen im Ausgangszustand zu testen. Dank der Flexibilität der Scanner wird die Konfiguration automatisch bestimmt, sodass Sie nichts ändern müssen, um Ergebnisse für mehrmodulare Maven-Anwendungen anzuzeigen. Wie gewohnt sind ähnliche Verbesserungen auch im Rahmen von .
GitLab Runner 11.9 verfügbar.
(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, das verwendet wird, um CI/CD-Jobs auszuführen und die Ergebnisse zurück an GitLab zu senden.
Hier sind einige Änderungen in GitLab Runner 11.9:
- .
- и .
- . Dies schließt auch .
- zur Unterstützung von , die in GitLab 11.10 erscheinen werden.
- .
- .
- Verschieben mehrerer Skripte – einschließlich и – nach Go.
- .
- .
- .
Die vollständige Liste der Änderungen finden Sie im Änderungsprotokoll von GitLab Runner: .
Verbesserungen des GitLab-Schemas
Verbindung des Atlassian-Kontos
Die folgenden Verbesserungen wurden im GitLab-Diagramm vorgenommen:
- Unterstützung für Google Cloud Memorystore hinzugefügt.
- Cron-Job-Einstellungen , da sie von mehreren Diensten verwendet werden.
- Das Registry wurde auf Version 2.7.1 aktualisiert.
- Ein neuer Parameter wurde hinzugefügt, um die GitLab-Registry mit Docker-Versionen bis 1.10 kompatibel zu machen. Aktivieren Sie dazu
registry.compatibility.schema1.enabled: true.
Leistungsverbesserung
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wir arbeiten weiterhin an der Verbesserung der Leistung von GitLab mit jeder Version für Instanzen jeder Größe. Hier sind einige Verbesserungen in GitLab 11.9:
- .
- .
- .
- .
Verbesserungen für Omnibus
Verbindung des Atlassian-Kontos
In GitLab 11.9 wurden folgende Verbesserungen für Omnibus vorgenommen:
- GitLab 11.9 umfasst , , dessen neueste Version MFA für die Team Edition, verbesserte Bildleistung und vieles mehr bietet. Dieses Update beinhaltet außerdem ; ein Upgrade wird empfohlen.
- Ein neuer Parameter wurde hinzugefügt, um die GitLab-Registry mit Docker-Versionen bis 1.10 kompatibel zu machen. Aktivieren Sie dazu
registry['compatibility_schema1_enabled'] = true in gitlab.rb. - Die GitLab-Registry exportiert jetzt Prometheus-Metriken und wird automatisch durch das .
- Die Unterstützung von Google Cloud Memorystore wurde 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 wird ab Version 12.0 eine hashierte Speicherung bieten
GitLab Geo benötigt zur Minderung von Wettbewerbsbedingungen (Race Condition) auf sekundären Knoten. 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 hashierte 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 ständig deaktivierte Warnmeldung wird auf der Seite Admin-Bereich › Geo › Knoten, angezeigt, wenn die oben genannten Überprüfungen nicht erfolgreich sind.
In GitLab Geo verwendet die Anforderungen an die hashierte Speicherung. Siehe .
Enddatum: 22. Juni 2019.
Integration von Hipchat
Hipchat . Darüber hinaus haben wir in Version 11.9 .
Enddatum: 22. März 2019.
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 .
Enddatum: 22. März 2019.
Veraltete Legacy-Pfade des GitLab Runners
Ab GitLab 11.9 verwendet der GitLab Runner Klonen/Aufrufen des Repositories. Derzeit verwendet GitLab Runner die alte Methode, wenn die neue nicht unterstützt wird.
In GitLab 11.0 haben wir die Art der Konfiguration des Metrikservers für den GitLab Runner geändert. metrics_server wird zugunsten von listen_address in GitLab 12.0 entfernt. Weitere Informationen finden Sie in . Und weitere Details in .
In Version 11.3 begann der GitLab Runner, , die zu neuen Einstellungen führten für In eine Tabelle der Änderungen und Anweisungen zum Wechsel zur neuen Konfiguration. Weitere Informationen finden Sie in .
Diese Pfade sind in GitLab 12.0 nicht mehr verfügbar. Als Benutzer müssen Sie nichts ändern, sondern lediglich sicherstellen, dass Ihre GitLab-Instanz bei der Aktualisierung auf GitLab Runner 12.0 mit Version 11.9+ läuft.
Enddatum: 22. Juni 2019.
Veralteter Parameter für das Feature des Einstiegspunkts für GitLab Runner
In 11.4 wurde der Parameter für das Feature GitLab Runner vorgestellt um Probleme wie и .
In GitLab 12.0 wechseln wir zu einem korrekten Verhalten, als ob der Feature-Parameter deaktiviert wäre. Weitere Details finden Sie in .
Enddatum: 22. Juni 2019.
Veraltete Unterstützung für Linux-Distributionen, die EOL erreicht haben, für GitLab Runner
Einige Linux-Distributionen, auf denen GitLab Runner installiert werden kann, haben ihr Ende erreicht.
In GitLab 12.0 wird GitLab Runner keine Pakete mehr für diese Linux-Distributionen bereitstellen. Eine vollständige Liste der nicht mehr unterstützten Distributionen finden Sie in unserer . Vielen Dank an Javier Jardón für) für ihn !
Enddatum: 22. Juni 2019.
Im Rahmen der Bemühungen zur Unterstützung
Windows Docker Executor Helper-Image .
In GitLab 12.0 wird der GitLab Runner mit neuen Befehlen gestartet. Dies betrifft nur Benutzer, die überschreiben. Weitere Details finden Sie in .
Enddatum: 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 nicht geschützten Branches war historisch gesehen nur auf .
Da Entwickler Tags hinzufügen sowie nicht geschützte Branches ändern und löschen können, sollten Entwickler in der Lage sein, Git-Tags zu löschen. In GitLab 11.10 in unser Berechtigungsmodell auf, um den Workflow zu verbessern und Entwicklern zu helfen, Tags besser und effizienter zu nutzen.
Wenn Sie diese Einschränkung für Betreuer und Eigentümer beibehalten möchten, verwenden Sie .
Enddatum: 22. April 2019.
Unterstützung für Prometheus 1.x in Omnibus GitLab
Ab GitLab , wird die integrierte Version von Prometheus 1.0 aus Omnibus GitLab ausgeschlossen. . Das Format der Metriken ist jedoch nicht mit Version 1.0 kompatibel. Bestehende Versionen können auf 2.0 aktualisiert werden, und wenn erforderlich, können Daten übertragen werden. .
In GitLab Version wird Prometheus 2.0 automatisch installiert, falls es noch kein Update gegeben hat. Daten aus Prometheus 1.0 gehen verloren, da sie nicht übertragen werden.
Enddatum: 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 gitlab-ctl reconfigure.
Enddatum: 22. Juni 2019.
OpenShift-Template zur Installation von GitLab
Offiziell — die empfohlene Methode zur Ausführung von GitLab auf Kubernetes, einschließlich .
zur Installation von GitLab ist veraltet und wird in .
Enddatum: 22. Juni 2019.
Frühere Definitionen von Sicherheitsjobs
Mit der Einführung von werden alle vorherigen Jobdefinitionen obsolet und in GitLab 12.0 oder später entfernt.
Aktualisieren Sie Ihre Jobdefinitionen, um die neue Syntax zu verwenden und von den neuen Sicherheitsfunktionen zu profitieren, die GitLab bietet.
Stichtag für die Entfernung: 22. Juni 2019.
dem Abschnitt Systeminformationen im Administrationsbereich
GitLab stellt Informationen über Ihre GitLab-Instanz bereit unter admin/system_info, aber diese Informationen können ungenau sein.
Wir des Administrationsbereichs in GitLab 12.0 entfernen und empfehlen die Nutzung von .
Enddatum: 22. Juni 2019.
Quelle: habr.com
