GitLab 11.10 mit Pipelines im Dashboard, Pipelines für Merge-Resultate und Vorschlägen für mehrere Zeilen in Merge-Anfragen.
Praktische Informationen über die Funktionalität von Pipelines in verschiedenen Projekten
GitLab erhöht weiterhin die Transparenz im Lebenszyklus von DevOps. In dieser Ausgabe wird eine Übersicht über den Status der Pipelines hinzugefügt.
Das ist praktisch, selbst wenn Sie nur die Pipeline eines Projekts ansehen, aber besonders nützlich, wenn , — was normalerweise der Fall ist, wenn Sie Mikrodienste verwenden und eine Pipeline zum Testen und Bereitstellen von Code aus verschiedenen Projekt-Repositories ausführen möchten. Jetzt sehen Sie sofort die Funktionalität , wo auch immer sie ausgeführt werden.
Ausführen von Pipelines für Merge-Resultate
Im Laufe der Zeit weichen der ursprüngliche und der Ziel-Branch voneinander ab, und es kann eine Situation entstehen, in der sie einzeln funktionieren, aber zusammen nicht. Jetzt können Sie So bemerken Sie schnell Fehler, die nur bei häufigen Änderungen zwischen den Branches aufgetreten wären, und können die Fehler in der Pipeline viel schneller beheben und effizienter nutzen. .
Weiter Optimierung der Zusammenarbeit
In GitLab 11.10 gibt es noch mehr Möglichkeiten für komfortable Zusammenarbeit und vereinfachte Arbeitsabläufe. In der führten wir Vorschläge für Merge-Anfragen ein, bei denen der Rezensent in einem Kommentar zur Merge-Anfrage eine Zeilenänderung vorschlagen konnte, die direkt aus dem Kommentarthread committed werden konnte. Unsere Benutzer fanden das großartig und haben um eine Erweiterung dieser Funktion gebeten. Jetzt können Sie , indem Sie angeben, welche Zeilen gelöscht und welche hinzugefügt werden sollen.
Vielen Dank für Ihr Feedback und Ihre Vorschläge!
Und das ist noch nicht alles...
In dieser Ausgabe gibt es so viele großartige Funktionen, zum Beispiel , eine gründlichere , und die Möglichkeit Unten finden Sie Einzelheiten zu jeder von ihnen.
Mitarbeiter des Monats () — Takuya Noguchi
In diesem Monat wurde Takuya Noguchi zum Mitarbeiter des Monats ernannt (). Takuya : Fehler behoben, Nachbesserungen im Backend und Frontend abgeschlossen und die Benutzeroberfläche verbessert. Danke!
Die wichtigsten Features von GitLab 11.10
Pipelines im Dashboard
PREMIUM, ULTIMATE, SILVER, GOLD
Im Dashboard von GitLab werden Informationen zu Projekten über die gesamte Instanz von GitLab angezeigt. Sie fügen einzelne Projekte nacheinander hinzu und können auswählen, welches Projekt für Sie von Interesse ist.
In dieser Ausgabe haben wir dem Dashboard Informationen über den Status der Pipelines hinzugefügt. Jetzt sehen Entwickler die Funktionsfähigkeit der Pipelines in all ihren benötigten Projekten – in einer einzigen Oberfläche.
Pipelines für kombinierte Ergebnisse
PREMIUM, ULTIMATE, SILVER, GOLD
Normalerweise weicht im Laufe der Zeit der ursprüngliche Branch vom Ziel-Branch ab, es sei denn, Sie übertragen ständig Änderungen zwischen ihnen. Das Ergebnis sind "grüne" Pipelines für die ursprünglichen und Ziel-Branches, und es entstehen keine Merge-Konflikte, aber beim Zusammenführen kommt es zu einem Fehler wegen inkompatibler Änderungen.
Wenn ein Merge-Request-Pipeline automatisch einen neuen Link erstellt, der das kombinierte Ergebnis des Mergers des ursprünglichen und des Ziel-Branches enthält, können wir die Pipeline über diesen Link starten und garantieren, dass das Gesamtergebnis funktionsfähig ist.
Wenn Sie Merge-Request-Pipelines (in irgendeiner Form) verwenden und private GitLab-Runner der Version 11.8 oder älter verwenden, müssen Sie diese aktualisieren, um Probleme zu vermeiden. . Dies hat keine Auswirkung auf Benutzer öffentlicher GitLab-Runner.
Änderungsvorschläge in mehreren Zeilen
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Bei der Zusammenarbeit an Merge-Requests stoßen Sie häufig auf Probleme und schlagen Lösungen vor. Seit der Version GitLab 11.6 unterstützen wir für eine Zeile.
In Version 11.10 können in den Kommentaren zu den Diff-Ansichten von Merge-Requests Änderungen für mehrere Zeilen vorgeschlagen werden, und dann kann jeder Benutzer mit Schreibberechtigung für den ursprünglichen Branch diese mit einem Klick annehmen. Dank dieser neuen Funktion kann das Kopieren und Einfügen, wie in früheren Versionen, vermieden werden.
Labels in einem Bereich
PREMIUM, ULTIMATE, SILVER, GOLD
Mit Labels in einem Bereich können Teams sich gegenseitig ausschließende Labels (im gleichen Bereich) für Aufgaben, Merge-Requests oder Epics in Szenarien mit benutzerdefinierten Feldern oder benutzerdefinierten Status für Workflows anwenden. Diese werden mit einer speziellen Syntax mit einem Doppelpunkt im Labelkopf konfiguriert.
Angenommen, Sie benötigen ein benutzerdefiniertes Feld in Aufgaben, um das Betriebssystem der Plattform zu verfolgen, auf die Ihre Funktionen abzielen. Jede Aufgabe sollte nur einer Plattform zugeordnet sein. Labels können erstellt werden platform::iOS, platform::Android, platform::Linux und weitere nach Bedarf. Wenn ein solches Label einer Aufgabe zugewiesen wird, wird automatisch ein anderes vorhandenes Label entfernt, das mit platform::.
Angenommen, Sie haben Labels workflow::development, workflow::review und workflow::deployed, die den Status des Arbeitsablaufs in Ihrem Team anzeigen. Wenn eine Aufgabe bereits ein Label hat, und der Entwickler die Aufgabe in den Status workflow::development, wechseln möchte, wendet er einfach ein neues Label an, und das alte ( workflow::review) wird automatisch entfernt. Dieses Verhalten existiert bereits, wenn Sie Aufgaben zwischen Labels auf dem Kanban-Board verschieben, das den Arbeitsablauf Ihres Teams darstellt. Jetzt können Teammitglieder, die nicht direkt mit dem Kanban-Board arbeiten, den Status des Arbeitsablaufs in den Aufgaben selbst ändern.workflow::developmentSorgfältigere Bereinigung des Container-Registries
Bei der üblichen Verwendung der Container-Registry mit CI-Pipelines senden Sie mehrere separate Änderungen zu einem Tag. Aufgrund der Implementierung der Verteilung in Docker ist das Standardverhalten, alle Änderungen im System zu speichern, was jedoch viel Speicherplatz beansprucht. Wenn Sie die Option
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
-m registry-garbage-collect c , verwenden, können alle vorherigen Änderungen schnell entfernt und wertvoller Speicherplatz freigegeben werden.Kauf zusätzlicher Minuten für den CI Runner
BRONZE, SILBER, GOLD
Benutzer mit kostenpflichtigen Plänen auf GitLab.com (Gold, Silber, Bronze) können jetzt zusätzliche Minuten für den CI Runner kaufen. Früher mussten sie mit dem im Plan vorgesehenen Kontingent auskommen. Mit dieser Verbesserung können Sie im Voraus Minuten über das Kontingent hinaus kaufen, um Unterbrechungen aufgrund eines Stopps der Pipelines zu vermeiden.
Derzeit kosten 1000 Minuten 8 Dollar und Sie können so viele kaufen, wie Sie möchten. Zusätzliche Minuten werden verwendet, wenn Sie Ihr monatliches Kontingent aufgebraucht haben, und der Rest der zusätzlichen Minuten wird in den nächsten Monat übertragen. In
einer zukünftigen Version Composable Auto DevOps
Mit Auto DevOps wechseln Teams nahezu mühelos zu modernen DevOps-Praktiken. Ab GitLab 11.10 wird jeder Job in Auto DevOps als
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
unabhängige Vorlage bereitgestellt . Benutzer können die in GitLab CI verwenden, um einzelne Auto DevOps-Stufen einzuschließen und dabei ihre benutzerdefinierte Datei gitlab-ci.yml. So können nur die benötigten Jobs aktiviert werden und die Vorteile von Updates im Upstream genutzt werden.
Automatische Verwaltung von Gruppenmitgliedern auf GitLab.com mithilfe von SCIM
SILBER, GOLD
Früher musste die Mitgliedschaft in Gruppen auf GitLab.com manuell verwaltet werden. Jetzt können SAML SSO verwendet werden, um die Mitgliedschaft über SCIM zu verwalten, um Benutzer auf GitLab.com zu erstellen, zu löschen und zu aktualisieren.
Das ist besonders nützlich für Unternehmen mit vielen Nutzern und zentralisierten Identitätsanbietern. Nun können Sie eine einzige Wahrheit haben, wie beispielsweise Azure Active Directory, und Benutzer werden automatisch über den Identitätsanbieter erstellt und gelöscht, statt manuell.
Anmeldung bei GitLab.com über SAML-Anbieter
SILBER, GOLD
Früher musste beim Einsatz von SAML SSO für Gruppen der Benutzer sich mit seinen GitLab-Anmeldeinformationen und dem Identitätsanbieter anmelden. Jetzt können Sie sich direkt über SSO als GitLab-Benutzer anmelden, der mit der konfigurierten Gruppe verknüpft ist.
Benutzer müssen sich nicht zweimal anmelden, was es für Unternehmen einfacher macht, SAML SSO für GitLab.com zu nutzen.
Weitere Verbesserungen in GitLab 11.10
Schema der Unterepics
ULTIMATIV, GOLD
In der vorherigen Version haben wir Unterepics (Epics von Epics) hinzugefügt, um Ihnen die Verwaltung der Struktur von Aufgabenverteilungen zu erleichtern. Unterepics werden auf der Seite des übergeordneten Epics angezeigt.
In dieser Version wird auf der Seite des übergeordneten Epics das Schema der Unterepics angezeigt, sodass die Teams die Chronologie der Unterepics sehen und zeitliche Abhängigkeiten verwalten können.
Popup-Bildschirme von Merge-Requests
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
In dieser Version führen wir informative Bildschirme ein, die beim Überfahren des Merge-Request-Links angezeigt werden. Früher wurde nur der Titel des Merge-Requests angezeigt, jetzt auch der Status des Merge-Requests, der CI-Pipeline-Status und ein kurzer URL.
In zukünftigen Versionen planen wir, weitere wichtige Informationen hinzuzufügen, wie , sowie Popup-Bildschirme für .
Filterung von Merge-Requests nach Ziel-Branches
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Die Arbeitsprozesse von Git für die Veröffentlichung oder Bereitstellung von Software sind häufig mit mehreren langfristigen Branches verbunden – zur Behebung von Fehlern in früheren Versionen (z. B. stable-11-9) oder um von der Qualitätsprüfung zur Produktion überzugehen (z. B. integration), aber es ist nicht so einfach, Merge-Requests für diese Branches unter den vielen offenen Merge-Requests zu finden.
Die Liste der Merge-Requests für Projekte und Gruppen kann jetzt nach dem Zielbranch des Merge-Requests gefiltert werden, um die Suche nach den gewünschten zu erleichtern.
Danke, Hiroyuki Sato ()!
Übermittlung und Merge bei erfolgreichem Pipeline
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Wenn wir die Methode der trunkbasierten Entwicklung verwenden, sollten wir langlebige Branches zugunsten von kurzen, temporären Branches mit einem Eigentümer vermeiden. Kleine Änderungen werden häufig direkt in den Zielbranch übertragen, was jedoch das Risiko birgt, den Build zu brechen.
In dieser Version unterstützt GitLab neue Übermittlungsparameter in Git, um automatisch Merge-Requests zu öffnen, den Zielbranch festzulegen und einen Merge bei erfolgreicher Pipeline über die Kommandozeile während der Übermittlung an einen Branch zu ermöglichen.
Verbesserte Integration mit externen Überwachungsdashboards
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab kann auf mehrere Prometheus-Server (auf Umgebungs-, Projekt- und ), aber mehrere Endpunkte können das System kompliziert machen oder nicht von Standardüberwachungsdashboards unterstützt werden. In dieser Version können Teams eine API von Prometheus verwenden, was die Integration mit Diensten wie Grafana erheblich vereinfacht.
Sortierung der Wiki-Seiten nach Erstellungsdatum
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Im Wiki eines Projekts können Teams Dokumentation und andere wichtige Informationen zusammen mit dem Quellcode und den Aufgaben teilen. In dieser Version kann die Liste der Seiten im Wiki nach Erstellungsdatum und Titel sortiert werden, um neu erstellte Inhalte schnell zu finden.
Überwachung der vom Cluster angeforderten Ressourcen
ULTIMATIV, GOLD
GitLab hilft, den Kubernetes-Cluster für entwickelte und produktive Anwendungen zu überwachen. Ab dieser Version verfolgen Sie die vom Cluster angeforderten CPU- und Speicherräume, um potenzielle Probleme zu erkennen, bevor sie zu einem Problem werden.
Ansicht der Metriken des Lastenausgleichs auf dem Grafana-Dashboard
CORE, STARTER, PREMIUM, ULTIMATE
Es ist sehr wichtig, die Betriebsbereitschaft der GitLab-Instanz zu überwachen. Früher haben wir standardmäßig Dashboards über die integrierte Instanz von Grafana bereitgestellt. Seit dieser Version haben wir zusätzliche Dashboards zur Überwachung von NGINX-Lastenausgleich hinzugefügt.
SAST für Elixir
ULTIMATIV, GOLD
Wir erweitern weiterhin die Unterstützung für Programmiersprachen und vertiefen die Sicherheitsprüfungen. In dieser Version haben wir Sicherheitsprüfungen für Projekte auf und Projekte, die auf .
Mehrere Anfragen in einem Diagramm
PREMIUM, ULTIMATE, SILVER, GOLD
In GitLab können Diagramme erstellt werden, um erfasste Metriken zu visualisieren. Oft möchte man mehrere Werte in einem Diagramm anzeigen, beispielsweise um den maximalen oder durchschnittlichen Wert einer Metrik zu sehen. Ab dieser Version haben Sie die Möglichkeit dazu.
DAST-Ergebnisse im Sicherheits-Dashboard der Gruppe
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Wir haben die Ergebnisse des Dynamic Application Security Testing (DAST) zum Sicherheits-Dashboard der Gruppe hinzugefügt, zusätzlich zu SAST, Container-Scans und Abhängigkeits-Scans.
Hinzufügen von Metadaten zum Container-Scan-Bericht
ULTIMATIV, GOLD
In dieser Version enthält der Bericht über das Container-Scanning mehr Metadaten - wir haben hinzugefügt betroffener Bestandteil (Clair-Funktion) zu den bestehenden Metadaten: Priorität, ID (mit Bezug auf mitre.org) und betroffenes Level (z.B. debian:8).
Hinzufügen eines Berichtstyps für Metriken in Merge-Requests
PREMIUM, ULTIMATE, SILVER, GOLD
GitLab bietet bereits mehrere Berichtstypen, die direkt in Merge-Requests eingebunden werden können: von Berichten über und in der Überprüfungsphase bis hin zu und in der Schutzphase.
Und obwohl dies wichtige Berichte sind, sind auch grundlegende Informationen, die für verschiedene Szenarien geeignet sind, erforderlich. In GitLab 11.10 bieten wir Metrikberichte direkt im Merge-Request an, der ein einfaches Schlüssel-Wert-Paar erwartet. So können die Benutzer zeitliche Änderungen verfolgen, einschließlich benutzerdefinierter Metriken und Metriken für einen bestimmten Merge-Request. Speicherauslastung, spezialisierte Lasttests und Betriebsbereitschaftsstatus können in einfache Metriken umgewandelt werden, die direkt in den Merge-Requests zusammen mit anderen integrierten Berichten angezeigt werden können.
Unterstützung für multimodulare Maven-Projekte zur Abhängigkeitsscan
ULTIMATIV, GOLD
In dieser Version unterstützen multimodulare Maven-Projekte das Abhängigkeitsscanning in GitLab. Früher konnte ein Submodul, das von einem anderen Submodul auf derselben Ebene abhing, die Abhängigkeit nicht aus dem zentralen Maven-Repository auflösen. Nun wird ein multimodulares Maven-Projekt mit zwei Modulen und einer Abhängigkeit zwischen diesen erstellt. Die Abhängigkeit zwischen Modulen auf derselben Ebene ist jetzt im lokalen Maven-Repository verfügbar, sodass der Build fortgesetzt werden kann.
Benutzer können den Klonpfad in CI ändern
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Standardmäßig klont der GitLab Runner das Projekt in einen einzigartigen verschachtelten Pfad in $CI_BUILDS_DIR. Für einige Projekte, wie Golang, muss der Code jedoch in ein bestimmtes Verzeichnis geklont werden, um ihn zu bauen.
In GitLab 11.10 hatten wir die Variable GIT_CLONE_PATH, eingeführt, mit der Sie einen bestimmten Pfad angeben können, in den der GitLab Runner das Projekt vor der Ausführung des Jobs klont.
Einfache Maskierung geschützter Variablen in Logs
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab bietet mehrere Möglichkeiten, um und von Variablen in GitLab CI/CD zu beschränken. Dennoch können Variablen absichtlich oder versehentlich in die Build-Logs gelangen.
GitLab nimmt Risikomanagement und Audits ernst und fügt ständig Funktionen hinzu, um den Anforderungen gerecht zu werden. In GitLab 11.10 haben wir die Möglichkeit eingeführt, bestimmte Typen von Variablen in den Job-Trace-Logs zu maskieren, indem ein Schutzlevel hinzugefügt wurde, um zu verhindern, dass der Inhalt dieser Variablen in die Logs gelangt. Darüber hinaus maskiert GitLab jetzt viele eingebaute Variablen-Token.
Aktivieren und Deaktivieren von Auto DevOps auf Gruppenniveau
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Mit Auto DevOps können Sie in einem GitLab.com-Projekt mühelos moderne DevOps-Workflows von Build bis Deployment übernehmen.
Ab GitLab 11.10 können Sie Auto DevOps für alle Projekte in einer Gruppe aktivieren oder deaktivieren.
Vereinfachte und verbesserte Lizenzseite
STARTER, PREMIUM, ULTIMATE
Um die Verwaltung von Lizenzschlüsseln einfacher und benutzerfreundlicher zu gestalten, haben wir das Design der Lizenzseite im Admin-Panel geändert und die wichtigsten Elemente hervorgehoben.
Aktualisierung des Label-Selectors für Kubernetes-Deployments
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Auf den Deployment-Panels werden Informationen zu allen Kubernetes-Deployments angezeigt.
In dieser Version haben wir die Art und Weise geändert, wie Labels mit Deployments abgeglichen werden. Jetzt sind Übereinstimmungen verfügbar durch app.example.com/app und app.example.com/env oder App. Dies wird Konflikte bei der Filterung und das Risiko fehlerhafter Deployments im Zusammenhang mit dem Projekt vermeiden.
Darüber hinaus werden wir in GitLab Version 12.0 , und die Übereinstimmung wird nur nach app.example.com/app und app.example.com/env.
Dynamisches Erstellen von Kubernetes-Ressourcen
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Die Integration von Kubernetes in GitLab ermöglicht die Verwendung der RBAC-Funktion über ein Servicekonto und einen dedizierten Namespace für jedes GitLab-Projekt. Ab dieser Version werden diese Ressourcen nur erstellt, wenn sie für Deployments benötigt werden.
Beim Kubernetes-Deployment wird GitLab CI diese Ressourcen vor dem Deployment erstellen.
Gruppen-Runner für Cluster auf Gruppenebene
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Cluster auf Gruppenebene unterstützen jetzt die Installation des GitLab Runner. Kubernetes-Runner auf Gruppenebene werden für untergeordnete Projekte als Gruppen-Runner angezeigt, die mit Labels gekennzeichnet sind: Cluster und Kubernetes.
Aufrufzähler für Knative-Funktionen
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Funktionen, die mit , zeigen jetzt die Anzahl der eingegangenen Aufrufe für die einzelnen Funktionen an. Dazu muss Prometheus im Cluster installiert sein, in dem Knative eingerichtet ist.
Kontrolle der Parameter git clean für Jobs in GitLab CI/CD
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Standardmäßig führt der GitLab Runner git clean den Code beim Ausführen eines Jobs in GitLab CI/CD aus. Ab GitLab 11.10 können Benutzer die an den Befehl übergebenen Parameter steuern, git clean. Dies ist praktisch für Teams mit dedizierten Runnern sowie für Teams, die Projekte aus großen Monorepositories bauen. Jetzt können sie den Ausladeprozess vor der Ausführung von Skripten steuern. Die neue Variable GIT_CLEAN_FLAGS hat standardmäßig den Wert -ffdx und akzeptiert alle möglichen Parameter des Befehls [git clean](https://git-scm.com/docs/git-clean).
Externe Autorisierung in Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Geschützte Umgebungen können zusätzliche externe Autorisierungsressourcen für den Zugriff auf das Projekt anfordern. Wir haben Unterstützung für eine zusätzliche Zugriffskontrollstufe in hinzugefügt und viele Anfragen erhalten, diese Funktionalität in Core zu öffnen. Wir freuen uns, externe Autorisierung und eine zusätzliche Sicherheitsebene für Core-Instanzen vorzustellen, da dieses Feature für einige Teilnehmer erforderlich ist.
Möglichkeit zur Erstellung von Projekten in Gruppen in Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Die Rolle Developer kann seit Version 10.5 Projekte in Gruppen erstellen , und jetzt ist es auch möglich in Core. Das Erstellen von Projekten ist eine Schlüsselressource für produktives Arbeiten in GitLab, und durch die Aktivierung dieser Funktion in Core ist es für die Teilnehmer des Instances einfacher geworden, sich mit Neuem zu beschäftigen.
GitLab Runner 11.10
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Heute haben wir GitLab Runner 11.10 veröffentlicht! GitLab Runner ist ein Open-Source-Projekt, das verwendet wird, um CI/CD-Aufgaben auszuführen und die Ergebnisse zurück an GitLab zu senden.
Die interessantesten Änderungen:
- .
- .
- .
- .
- .
Die vollständige Liste der Änderungen finden Sie im Änderungsprotokoll von GitLab Runner: .
Korrektur des zurückgegebenen project_id im Blob-Such-API in Elasticsearch
STARTER, PREMIUM, ULTIMATE
Wir haben einen Fehler in der Blob-Such-API in Elasticsearch behoben, der fälschlicherweise 0 für project_idzurückgab. Elasticsearch neu zu indizieren project_id , um korrekte Werte zu erhalten
Verbesserungen von Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Wir haben die folgenden Verbesserungen in Omnibus in GitLab 11.10 vorgenommen:
- GitLab 11.10 beinhaltet , , dessen letzte Version ein neues Integrationsverzeichnis für einfachen Datenimport aus Hipchat und vieles mehr enthält. Diese Version enthält , und wir empfehlen ein Upgrade.
- Wir , und jetzt ist es ganz einfach, die GitLab-Instanz zu überwachen.
- Wir haben die Unterstützung für das Entfernen alter Container-Images aus dem Docker-Registry hinzugefügt.
- Wir haben die ca-certs auf den Stand vom 23.01.2019 aktualisiert.
Leistungsverbesserungen
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Wir verbessern weiterhin die Leistung von GitLab mit jeder Veröffentlichung für GitLab-Instanzen jeder Größe. Einige Verbesserungen in GitLab 11.10:
- .
- .
- .
- .
- .
- .
- .
- .
Verbesserung der GitLab-Diagramme.
CORE, STARTER, PREMIUM, ULTIMATE
Wir haben die folgenden Verbesserungen an den GitLab-Diagrammen vorgenommen:
- .
Veraltete Funktionen
GitLab Geo ermöglicht die verschlüsselte Speicherung in GitLab 12.0
GitLab Geo ist erforderlich um die Konkurrenz auf sekundären Knoten zu verringern. Dies wurde vermerkt 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.
Unterstützung für Ubuntu 14.04
GitLab 11.10 wird die letzte Version mit .
Canonical hat angekündigt, die Standardunterstützung für Ubuntu 14.04 einzustellen ab Wir empfehlen den Benutzern, auf eine unterstützte LTS-Version zu wechseln: Ubuntu 16.04 oder Ubuntu 18.04.
Löschdatum: 22. Mai 2019.
Begrenzung der maximalen Anzahl von Pipelines, die mit einem Commit erstellt werden
Früher erstellte GitLab Pipelines für HEAD jeder Branch im Commit. Dies ist praktisch für Entwickler, die mehrere Änderungen auf einmal übermitteln (z. B. in einen Feature-Branch und in den Branch develop).
Aber beim Commit eines großen Repositories, in dem viele aktive Branches vorhanden sind (z. B. für Umzüge, Spiegelungen oder Abzweigungen), muss nicht für jeden Branch eine Pipeline erstellt werden. Ab GitLab 11.10 erstellen wir beim Commit.
Löschdatum: 22. Mai 2019.
Veraltete Pfade für den Legacy-Code von GitLab Runner
Ab GitLab 11.9 verwendet GitLab Runner zum Klonen/Aufrufen des Repositories. Momentan wird GitLab Runner die alte Methode verwenden, wenn die neue nicht unterstützt wird. Weitere Informationen 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 .
In Version 11.3 begann GitLab Runner, ; was zu neuen Einstellungen für . In , finden Sie eine Tabelle mit Änderungen und Anweisungen für den Übergang zu einer neuen Konfiguration. Weitere Informationen finden Sie in .
Diese Wege werden in GitLab 12.0 nicht mehr verfügbar sein. Als Benutzer müssen Sie nichts ändern, sondern nur sicherstellen, dass Ihre GitLab-Instanz auf Version 11.9+ aktualisiert wird, bevor Sie auf GitLab Runner 12.0 wechseln.
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ó () für !
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 .
verwendet werden, eingestellt werden. In GitLab 12.0 wird GitLab Runner mit neuen Befehlen gestartet. Dies betrifft nur Benutzer, die . Weitere Informationen finden Sie in .
Löschdatum: 22. Juni 2019.
Entfernung des Legacy-Mechanismus git clean aus GitLab Runner
In GitLab Runner 11.10 zu konfigurieren, wie der Runner den Befehl ausführt git clean. Darüber hinaus entfernt die neue Bereinigungsstrategie die Verwendung von git reset und fügt den Befehl git clean nach dem Upload-Schritt hinzu.
Da diese Verhaltensänderung einige Benutzer betreffen kann, haben wir den Parameter FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Wenn Sie diesen auf truesetzen, wird die Legacy-Bereinigungsstrategie wiederhergestellt. Weitere Informationen zu funktionalen Parametern in GitLab Runner finden Sie in der .
In GitLab Runner 12.0 werden wir die Unterstützung für die Legacy-Bereinigungsstrategie und die Möglichkeit, sie über einen Funktionsparameter wiederherzustellen, entfernen. Weitere Informationen finden Sie in .
Löschdatum: 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.
Änderungsprotokoll
Suchen Sie all diese Änderungen im Änderungsprotokoll:
Installation
Wenn Sie eine neue GitLab-Installation einrichten, besuchen Sie .
Aktualisierung
Besuchen Sie die .
GitLab Abonnementpläne
GitLab ist in zwei Varianten verfügbar: und .
: lokal oder auf der bevorzugten Cloud-Plattform.
- Kern: für kleine Teams, persönliche Projekte oder eine unlimitierte Testversion von GitLab.
- Starter: für Teams, die in einem Büro an mehreren Projekten arbeiten und professionelle Unterstützung benötigen.
- Premium: für verteilte Teams, die erweiterte Funktionen, hohe Verfügbarkeit und 24/7-Support benötigen.
- Ultimate: für Unternehmen, die eine zuverlässige Strategie und Umsetzung mit verbesserter Sicherheit und Compliance erfordern.
— GitLab.com: wird von GitLab gehostet, verwaltet und administriert. für Einzelentwickler und Teams.
- Kostenlos: unbegrenzte private Repositories und unbegrenzte Anzahl an Projektmitgliedern. Geschlossene Projekte haben Zugang zu Funktionen der Ebene Kostenlos, während Zugang zu Funktionen der Ebene Gold.
- Bronze: für Teams, die Zugang zu erweiterten Workflow-Funktionen benötigen.
- Silber: für Teams, die zuverlässigere DevOps-Möglichkeiten, Compliance und schnelle Unterstützung benötigen.
- Gold: eignet sich für viele CI/CD-Jobs. Alle offenen Projekte können die Gold-Funktionen unabhängig vom Plan kostenlos nutzen.
Quelle: habr.com
