GitLab 11.10 z pipeline'ami w panelu sterowania, pipeline'ami dla zintegrowanych wyników i propozycjami kilku wierszy w merge requestach.
Przydatne informacje o wydajności pipeline'ów w różnych projektach
GitLab nadal zwiększa przejrzystość cyklu życia DevOps. W tej wersji dodano przegląd statusu pipeline'ów.
Jest to wygodne, nawet jeśli badacie pipeline jednego projektu, ale szczególnie przydatne, jeśli — co zazwyczaj ma miejsce, gdy używasz mikroserwisów i chcesz uruchomić pipeline do testowania i wdrażania kodu z różnych repozytoriów projektów. Teraz od razu widzisz wydajność , gdziekolwiek są uruchamiane.
Uruchamianie pipeline'ów dla zintegrowanych wyników
Z biegiem czasu źródłowe i docelowe gałęzie się rozdzielają, co może prowadzić do sytuacji, w której osobno działają, a razem już nie. Teraz można Dzięki temu szybko zauważysz błędy, które ujawniłyby się tylko przy częstym przenoszeniu zmian między gałęziami, co pozwoli Ci szybciej poprawić błędy pipeline'a i efektywniej wykorzystać .
Dalsza optymalizacja współpracy
W GitLab 11.10 pojawiło się jeszcze więcej możliwości dla wygodnej współpracy i uproszczonych procesów roboczych. W wprowadziliśmy propozycje do merge requestów, kiedy recenzent mógł zaproponować zmianę jednej linii w komentarzu do merge requesta, która mogła być od razu skomitowana bezpośrednio z wątku komentarzy. Naszym użytkownikom się to spodobało, więc poprosili o rozszerzenie tej funkcji. Teraz możesz proponować określając, które linie usunąć, a które dodać.
Dziękujemy za Wasze opinie i propozycje!
I to jeszcze nie wszystko...
W tej wersji jest tak wiele niesamowitych funkcji, na przykład, dokładniejsze , i możliwość Poniżej szczegóły na temat każdej z nich.
Pracownik miesiąca () — Takuya Noguti
W tym miesiącu pracownikiem miesiąca został Takuya Noguti (). Takuya : naprawiałem błędy, kończyłem niedoróbki w backendzie i frontendzie oraz ulepszałem interfejs użytkownika. Dziękuję!
Główne funkcje GitLab 11.10
Pipeline'y na panelu sterowania
PREMIUM, ULTIMATE, SILVER, GOLD
Na panelu sterowania w GitLab wyświetlane są informacje o projektach w całej instancji GitLab. Możesz dodawać pojedyncze projekty jeden po drugim i wybierać, który projekt Cię interesuje.
W tej wersji dodaliśmy na panel sterowania informacje o statusach pipeline'ów. Teraz deweloperzy mogą zobaczyć funkcjonalność pipeline'ów we wszystkich potrzebnych projektach — w jednym interfejsie.
Pipeline'y dla połączonych wyników
PREMIUM, ULTIMATE, SILVER, GOLD
Zwykle z biegiem czasu gałąź źródłowa odchodzi od docelowej, jeśli nie przenosisz między nimi zmian. W rezultacie pipeline'y zarówno gałęzi źródłowej, jak i docelowej są "zielone" i nie ma konfliktów merge, ale przy scalaniu występuje błąd z powodu niekompatybilności zmian.
Kiedy pipeline merge requestów automatycznie tworzy nowy link, który zawiera połączony wynik scalania gałęzi źródłowej i docelowej, możemy uruchomić pipeline'a za pomocą tego linku i zapewnić, że finalny wynik będzie działał.
Jeśli używasz pipeline'ów merge requestów (w dowolnej formie) i korzystasz z prywatnych runnerów GitLab w wersji 11.8 lub starszych, musisz je zaktualizować, aby uniknąć problemów. . To nie wpływa na użytkowników publicznych runnerów GitLab.
Propozycja zmian w kilku linijkach
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Podczas współpracy nad merge requestami często zauważasz problemy i proponujesz rozwiązania. Od wersji GitLab 11.6 wspieramy dla jednej linijki.
W wersji 11.10 w komentarzach do diffu merge requesta można proponować zmiany w kilku linijkach, a następnie każdy użytkownik z uprawnieniami do zapisu w gałęzi źródłowej może je zaakceptować jednym kliknięciem. Dzięki tej nowej funkcji można uniknąć kopiowania i wklejania, jak w poprzednich wersjach.
Etykiety w jednym obszarze
PREMIUM, ULTIMATE, SILVER, GOLD
Dzięki etykietom w jednym obszarze zespoły mogą stosować wzajemnie wykluczające się etykiety (w tym samym obszarze) dla zadania, merge requesta lub epika w scenariuszach z niestandardowymi polami lub niestandardowymi stanami workflow. Są one konfigurowane za pomocą specjalnej składni z dwukropkiem w tytule etykiety.
Załóżmy, że potrzebujesz pola niestandardowego w zadaniach, aby śledzić system operacyjny platformy, na którą kierujesz swoje funkcje. Każde zadanie powinno odnosić się tylko do jednej platformy. Można tworzyć etykiety platform::iOS, platform::Android, platform::Linux i inne w razie potrzeby. Jeśli zastosujesz jedną z takich etykiet do zadania, automatycznie usunięta zostanie inna istniejąca etykieta, która zaczyna się od platform::.
Zakładając, że masz etykiety workflow::development, workflow::review i workflow::deployed, wskazujące na stan przepływu pracy w twoim zespole. Jeśli zadanie już ma etykietę workflow::development, a programista chce przenieść zadanie do etapu workflow::review, wystarczy, że zastosuje nową etykietę, a stara (workflow::development) automatycznie zostanie usunięta. To zachowanie istnieje już, gdy przenosisz zadania między listami etykiet na tablicy zadań, która reprezentuje przepływ pracy twojego zespołu. Teraz członkowie zespołu, którzy nie pracują bezpośrednio z tablicą zadań, mogą zmieniać stan przepływu pracy w samych zadaniach.
Dokładniejsze czyszczenie rejestru kontenerów
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Podczas normalnego użycia rejestru kontenerów z pipeline'ami CI wysyłasz kilka oddzielnych zmian do jednego tagu. Z powodu realizacji rozproszenia Docker domyślne zachowanie polega na zachowywaniu wszystkich zmian w systemie, ale w końcu zajmują one dużo pamięci. Używając opcji -m z registry-garbage-collect, można szybko usunąć wszystkie wcześniejsze zmiany i zwolnić cenne miejsce.
Zakup dodatkowych minut CI Runner
BRĄZOWY, SREBRNY, ZŁOTY
Użytkownicy z płatnymi planami GitLab.com (Złoty, Srebrny, Brązowy) mogą teraz kupować dodatkowe minuty CI Runner. Wcześniej trzeba było zmieścić się w kwocie przewidzianej przez plan. Dzięki tej poprawie można wcześniej zakupić minuty ponad kwotę, aby uniknąć przerwy w pracy z powodu zatrzymania pipeline'ów.
Aktualnie 1000 minut kosztuje 8 dolarów, a ich zakup jest nieograniczony. Dodatkowe minuty zaczną się używać, gdy wykorzystasz całą miesięczną kwotę, a pozostałe dodatkowe minuty przenoszone są na następny miesiąc. W chcemy dodać tę funkcję także do darmowych planów.
Modułowy Auto DevOps
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Dzięki Auto DevOps zespoły przechodzą na nowoczesne praktyki DevOps niemal bez wysiłku. Zaczynając od GitLab 11.10, każde zadanie w Auto DevOps jest udostępniane jako . Użytkownicy mogą korzystać z w GitLab CI, aby włączać poszczególne etapy Auto DevOps, jednocześnie używając własnego pliku konfiguracyjnego gitlab-ci.yml. W ten sposób można uruchomić tylko potrzebne zadania i korzystać z korzyści płynących z aktualizacji w upstream.
Automatyczne zarządzanie członkami grupy na GitLab.com za pomocą SCIM
SILVER, GOLD
Wcześniej zarządzanie członkostwem w grupach na GitLab.com musiało odbywać się ręcznie. Teraz można używać SAML SSO i zarządzać członkostwem za pomocą SCIM, aby tworzyć, usuwać i aktualizować użytkowników na GitLab.com.
Jest to szczególnie przydatne dla firm z dużą liczbą użytkowników i scentralizowanymi dostawcami tożsamości. Teraz możecie mieć jedno źródło prawdy, na przykład Azure Active Directory, a użytkownicy będą tworzeni i usuwani automatycznie przez dostawcę tożsamości, a nie ręcznie.
Logowanie do GitLab.com przez dostawcę SAML
SILVER, GOLD
Wcześniej przy korzystaniu z SAML SSO dla grupy użytkownik musiał logować się za pomocą danych logowania do GitLab oraz dostawcy tożsamości. Teraz można logować się bezpośrednio przez SSO jako użytkownik GitLab powiązany z skonfigurowaną grupą.
Użytkownicy nie będą musieli logować się dwukrotnie, dlatego firmom łatwiej jest korzystać z SAML SSO dla GitLab.com.
Inne ulepszenia w GitLab 11.10
Schemat epików podrzędnych
ULTIMATE, GOLD
W poprzednim wydaniu dodaliśmy epiki podrzędne (epiki epików), aby ułatwić zarządzanie strukturą rozdzielania zadań. Epiki podrzędne są wyświetlane na stronie epika głównego.
W tym wydaniu na stronie epika głównego wyświetlany jest schemat epików podrzędnych, dlatego zespoły mogą widzieć chronologię epików podrzędnych i zarządzać zależnościami czasowymi.
Ekrany rozwijane żądań scalania
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
W tym wydaniu wprowadzamy informacyjne ekrany, które pojawiają się po najechaniu kursorem na link żądania scalania. Wcześniej pokazywaliśmy tylko tytuł żądania scalania, a teraz także status żądania scalania, status pipeline'u CI oraz krótki URL.
W przyszłych wydaniach planujemy dodać więcej ważnych informacji, na przykład , a także wprowadzimy ekrany rozwijane dla .
Filtracja żądań scalania według gałęzi docelowych
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Procesy Git dotyczące wydania lub dostarczania oprogramowania często wiążą się z wieloma długoterminowymi gałęziami — do wprowadzania poprawek w poprzednich wersjach (na przykład, stable-11-9) lub przejścia od testów jakości do produkcji (na przykład, integration), ale nie jest łatwo znaleźć prośby o merge dla tych gałęzi wśród wielu otwartych prośb o merge.
Listę próśb o merge dla projektów i grup można teraz filtrować według docelowej gałęzi prośby o merge, co ułatwia znalezienie potrzebnych.
Dziękujemy, Hiroyuki Sato ()!
Wysyłanie i merge przy pomyślnym pipeline
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Jeśli korzystamy z metody Trunk-based development, powinniśmy unikać długoterminowych gałęzi na rzecz małych, tymczasowych gałęzi z jednym właścicielem. Małe zmiany są często wysyłane bezpośrednio do docelowej gałęzi, jednak ryzykujemy naruszenie kompilacji.
W tej wersji GitLab obsługuje nowe opcje wysyłania do Git, aby automatycznie otwierać prośby o merge, ustalać docelową gałąź i zapewniać merge przy pomyślnym pipeline z wiersza poleceń podczas wysyłania w gałąź.
Ulepszona integracja z zewnętrznymi panelami monitoringu
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab może łączyć się z wieloma serwerami Prometheus (na poziomie środowiska, projektu i ), ale posiadanie wielu punktów końcowych może komplikuje system lub być nieobsługiwane przez standardowe panele monitorowania. W tej wersji zespoły mogą korzystać z jednego API Prometheus, co znacznie upraszcza integrację z takimi serwisami, jak Grafana.
Sortowanie stron Wiki według daty utworzenia
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
W Wiki projektu zespoły mogą dzielić się dokumentacją i innymi ważnymi informacjami obok kodu źródłowego i zadań. W tej wersji lista stron w Wiki może być sortowana według daty utworzenia i tytułu, aby szybko znaleźć niedawno utworzone treści.
Monitorowanie zasobów żądanych przez klaster
ULTIMATE, GOLD
GitLab pomaga monitorować klaster Kubernetes dla rozwijanych i działających aplikacji. Od tej wersji śledź żądane przez klaster zasoby procesora i pamięć, aby dostrzec potencjalne trudności, zanim staną się problemami.
Wyświetlanie metryk load balancera na panelu monitorowania Grafana
CORE, STARTER, PREMIUM, ULTIMATE
Konieczne jest monitorowanie działania instancji GitLab. Wcześniej udostępnialiśmy domyślne pulpity monitorujące poprzez wbudowaną instancję Grafana. Począwszy od tej wersji, dodaliśmy dodatkowe panele do monitorowania load balancerów NGINX.
SAST dla Elixir
ULTIMATE, GOLD
Kontynuujemy rozszerzanie wsparcia dla języków i pogłębianie kontroli bezpieczeństwa. W tej wersji dodaliśmy kontrole bezpieczeństwa dla projektów opartych na i projektów stworzonych na .
Kilka zapytań na jednym wykresie
PREMIUM, ULTIMATE, SILVER, GOLD
W GitLab można tworzyć wykresy w celu wizualizacji zbieranych metryk. Często — na przykład, gdy trzeba sprawdzić maksymalną lub średnią wartość metryki — warto umieścić kilka wartości na jednym wykresie. Począwszy od tej wersji, masz taką możliwość.
Wyniki DAST na panelu bezpieczeństwa grupy
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Dodaliśmy wyniki dynamicznego testowania bezpieczeństwa aplikacji (Dynamic Application Security Testing, DAST) na panelu bezpieczeństwa grupy w dodatku do SAST, skanowania kontenerów i skanowania zależności.
Dodanie metadanych do raportu o skanowaniu kontenerów
ULTIMATE, GOLD
W tej wersji raport o skanowaniu kontenerów zawiera więcej metadanych — dodaliśmy dotknięty komponent (funkcja Clair) do istniejących metadanych: priorytet, identyfikator (z odniesieniem do mitre.org) i dotknięty poziom (np. debian:8).
Dodanie typu raportu o metrykach do merge requestów
PREMIUM, ULTIMATE, SILVER, GOLD
GitLab już zapewnia kilka typów raportów, które można umieszczać bezpośrednio w merge requestach: od raportów o i na etapie przeglądu do i na etapie zabezpieczeń.
I chociaż to ważne raporty, potrzebne są również podstawowe informacje, które pasują do różnych scenariuszy. W GitLab 11.10 dostarczamy raporty metryk bezpośrednio w merge request, który oczekuje prostą parę klucz-wartość. Dzięki temu użytkownicy śledzą zmiany w czasie, w tym metryki użytkownika oraz zmiany metryk dla danego merge requestu. Użycie pamięci, testowanie specjalistycznych obciążeń i statusy działania można przekształcić w proste metryki, które można przeglądać bezpośrednio w merge requestach obok innych wbudowanych raportów.
Wsparcie dla projektów wielomodułowych Maven w skanowaniu zależności
ULTIMATE, GOLD
W tej wersji projekty wielomodułowe Maven obsługują skanowanie zależności GitLab. Wcześniej, jeśli podmoduł miał zależność od innego podmodułu na tym samym poziomie, nie mógł załadować z centralnego repozytorium Maven. Teraz projekt wielomodułowy Maven tworzony jest z dwoma modułami i zależnością między nimi. Zależność między modułami na tym samym poziomie jest teraz dostępna w lokalnym repozytorium Maven, co pozwala kontynuować budowę.
Użytkownicy mogą zmieniać ścieżkę do klonowania w CI
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Domyślnie GitLab Runner klonuje projekt do unikalnej zagnieżdżonej ścieżki w $CI_BUILDS_DIR. Jednak w niektórych projektach, na przykład Golang, kod musi być klonowany w określonym katalogu, aby mógł zostać zbudowany.
W GitLab 11.10 wprowadziliśmy zmienną GIT_CLONE_PATH, która pozwala wskazać konkretną ścieżkę, do której GitLab Runner klonuje projekt przed wykonaniem zadania.
Proste maskowanie chronionych zmiennych w logach
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
GitLab oferuje kilka sposobów i zmiennych w GitLab CI/CD. Jednak zmienne mogą przypadkowo lub celowo trafić do logów kompilacji.
GitLab traktuje poważnie zarządzanie ryzykiem i audyt oraz nieustannie dodaje funkcje, aby spełniać wymagania. W GitLab 11.10 wprowadziliśmy możliwość maskowania niektórych typów zmiennych w logach śladów zadań, dodając poziom ochrony przed przypadkowym ujawnieniem zawartości tych zmiennych w logach. Ponadto GitLab teraz wiele wbudowanych zmiennych tokenów.
Włączanie i wyłączanie Auto DevOps na poziomie grupy
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Dzięki Auto DevOps w projekcie GitLab.com możesz łatwo zająć się nowoczesnymi procesami DevOps — od budowy po dostawę.
Począwszy od GitLab 11.10 możesz włączać i wyłączać Auto DevOps dla wszystkich projektów w jednej grupie.
Uproszczona i ulepszona strona licencji
STARTER, PREMIUM, ULTIMATE
Aby zarządzanie kluczami licencyjnymi było wygodniejsze, zmieniliśmy projekt strony licencji w panelu administratora i wyróżniliśmy najważniejsze elementy.
Aktualizacja selektora etykiet dla wdrożeń Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Na panelach wdrożeń wyświetlane są informacje o wszystkich wdrożeniach Kubernetes.
W tej wersji zmieniliśmy sposób przypisywania etykiet do wdrożeń. Teraz dostępne są dopasowania dla app.example.com/app i app.example.com/env lub app. To avoid filtering conflicts and the risk of incorrect deployments related to the project.
Moreover, in GitLab version 12.0 we , and matching will be possible only by app.example.com/app i app.example.com/env.
Dynamic resource creation in Kubernetes
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
The integration of Kubernetes in GitLab allows the use of the RBAC feature through a service account and a dedicated namespace for each GitLab project. Starting with this release, these resources will be created only when needed for deployment for maximum efficiency.
During the Kubernetes deployment, GitLab CI will create these resources before the deployment.
Group runners for clustered groups
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Group-level clusters now support the installation of GitLab Runner. Kubernetes group runners are displayed for child projects as group runners tagged with labels cluster i kubernetes.
Call counter for Knative functions
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Functions deployed with , now show the number of received calls for the individual function. To do this, Prometheus needs to be installed on the cluster where Knative is installed.
Parameters control git clean for GitLab CI/CD jobs
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
By default, GitLab Runner executes git clean during code unloading when a job runs in GitLab CI/CD. Starting with GitLab 11.10, users can control the parameters passed to the command git clean. This is convenient for teams with dedicated runners, as well as for teams that build projects from large monorepositories. Now they can manage the unloading process before script execution. The new variable GIT_CLEAN_FLAGS defaults to -ffdx and accepts all possible parameters of the command [git clean](https://git-scm.com/docs/git-clean).
External authorization in Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Protected environments may require an additional external resource authorization for access to the project. We have added support for an additional layer of access control in and have received many requests to open this functionality in Core. We are pleased to present external authorization and an additional level of security for Core instances, as this feature is needed by individual participants.
The ability to create projects in groups in Core
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Developer role can create projects in groups , a teraz to możliwe także w Core. Tworzenie projektów to kluczowa funkcjonalność dla efektywnej pracy w GitLab, a dzięki wdrożeniu tej funkcji w Core uczestnicy instancji mogą teraz łatwiej zająć się nowymi zadaniami.
GitLab Runner 11.10
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Dziś wydaliśmy GitLab Runner 11.10! GitLab Runner to projekt z otwartym kodem źródłowym, który służy do uruchamiania zadań CI/CD i przesyłania wyników z powrotem do GitLab.
Najciekawsze zmiany:
- .
- .
- .
- .
- .
Pełną listę zmian można znaleźć w dzienniku zmian GitLab Runner: .
Poprawa zwracanych project_id w API wyszukiwania blob w Elasticsearch
STARTER, PREMIUM, ULTIMATE
Naprawiliśmy błąd w API wyszukiwania blob w Elasticsearch, który błędnie zwracał 0 dla project_id. Będzie trzeba , aby uzyskać poprawne wartości project_id po zainstalowaniu tej wersji GitLab.
Ulepszenia Omnibus
CORE, STARTER, PREMIUM, ULTIMATE
Wprowadziliśmy następujące ulepszenia w Omnibus w GitLab 11.10:
- GitLab 11.10 zawiera , , w ostatnim wydaniu, które zawiera nowy katalog integracji dla łatwego przenoszenia danych z Hipchat oraz wiele innych nowości. Ta wersja zawiera , i zalecamy aktualizację.
- My , dzięki czemu rozpoczęcie monitorowania instancji GitLab stało się naprawdę proste.
- Dodaliśmy wsparcie dla usuwania starych obrazów kontenerów z rejestru Docker.
- Zaktualizowaliśmy certyfikaty ca do 2019-01-23.
Poprawa wydajności
CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Nadal poprawiamy wydajność GitLab z każdą wersją, aby dostosować się do instancji GitLab dowolnej wielkości. Niektóre usprawnienia w GitLab 11.10:
- .
- .
- .
- .
- .
- .
- .
- .
Ulepszenie diagramów GitLab
CORE, STARTER, PREMIUM, ULTIMATE
Wprowadziliśmy następujące usprawnienia w diagramach GitLab:
- .
Przestarzałe funkcje
GitLab Geo zapewni haszowane przechowywanie w GitLab 12.0
GitLab Geo wymaga w celu złagodzenia konkurencji na węzłach wtórnych. Zostało to zauważone w .
W GitLab dodaliśmy ten wymóg do dokumentacji Geo: .
W GitLab sudo gitlab-rake gitlab:geo:check sprawdza, czy haszowane przechowywanie jest włączone i czy wszystkie projekty są przenoszone. Zob. . Jeśli używasz Geo, uruchom tę kontrolę i migrację jak najszybciej.
W GitLab ciągłe ostrzeżenie o wyłączeniu będzie widoczne na stronie Obszar administracyjny › Geo › Węzły, jeśli wspomniane powyżej kontrole nie są dozwolone.
W GitLab Geo będzie korzystać z wymagań dotyczących haszowanego magazynu. Zob. .
Data usunięcia: 22 czerwca 2019 r.
Wsparcie dla Ubuntu 14.04
GitLab 11.10 będzie ostatnią wersją z .
Canonical ogłosił zakończenie standardowego wsparcia dla Ubuntu 14.04 od . Zalecamy użytkownikom przejście na wspieraną wersję LTS: Ubuntu 16.04 lub Ubuntu 18.04.
Data usunięcia: 22 maja 2019 r.
Ograniczenie maksymalnej liczby potoków tworzonych w trakcie jednego zgłoszenia
Wcześniej GitLab tworzył potoki dla HEAD każdej gałęzi w zgłoszeniu. To jest wygodne dla deweloperów, którzy przesyłają kilka zmian jednocześnie (na przykład w gałęzi funkcjonalnej i gałęzi develop).
Lecz przy przesyłaniu dużego repozytorium, gdzie jest wiele aktywnych gałęzi (na przykład do przenoszenia, odbicia lustrzanego lub rozgałęziania), nie ma potrzeby tworzenia potoku dla każdej gałęzi. Począwszy od GitLab 11.10 tworzymy przy przesyłaniu.
Data usunięcia: 22 maja 2019 r.
Przestarzałe ścieżki kodu legacy w GitLab Runner
Od Gitlab 11.9 GitLab Runner używa klonowania/wywoływania repozytorium. Obecnie GitLab Runner użyje starej metody, jeśli nowa nie jest wspierana. Szczegóły znajdziesz w .
W GitLab 11.0 zmieniliśmy sposób konfiguracji serwera metryk dla GitLab Runner. metrics_server zostanie usunięty na rzecz listen_address w GitLab 12.0. Więcej szczegółów znajdziesz w .
W wersji 11.3 GitLab Runner zaczął wspierać ; co doprowadziło do nowych ustawień dla . W , przedstawiona jest tabela zmian i instrukcje dotyczące przejścia na nową konfigurację. Szczegóły znajdziesz w .
Te ścieżki będą niedostępne w GitLab 12.0. Jako użytkownik, nie musisz nic zmieniać, tylko upewnić się, że instancja GitLab działa w wersji 11.9+ przy aktualizacji do GitLab Runner 12.0.
Data usunięcia: 22 czerwca 2019 r.
Przestarzały parametr dla cechy punktu wejścia dla GitLab Runner
W wersji 11.4 GitLab Runner wprowadzono parametr cechy w celu naprawy problemów takich jak i .
W GitLab 12.0 przełączymy się na właściwe zachowanie, tak jakby parametr cechy był wyłączony. Więcej informacji można znaleźć w .
Data usunięcia: 22 czerwca 2019 r.
Przestarzałe wsparcie dla dystrybucji Linux, które osiągnęły EOL, dla GitLab Runner
Niektóre dystrybucje Linux, na które można zainstalować GitLab Runner, zakończyły swoją żywotność.
W GitLab 12.0 GitLab Runner nie będzie już dystrybuował pakietów do tych dystrybucji Linux. Pełna lista dystrybucji, które nie są już wspierane, znajduje się w naszej . Dziękujemy Javierowi Jardónowi () za !
Data usunięcia: 22 czerwca 2019 r.
Usunięcie starych komend GitLab Runner Helper
W ramach wsparcia dla było konieczne porzucenie niektórych starych komend używanych do .
W GitLab 12.0 GitLab Runner uruchamiany jest za pomocą nowych poleceń. Dotyczy to tylko użytkowników, którzy . Więcej informacji można znaleźć w .
Data usunięcia: 22 czerwca 2019 r.
Usunięcie mechanizmu git clean z GitLab Runner
W GitLab Runner 11.10 skonfigurowania, jak Runner wykonuje polecenie git clean. Ponadto nowa strategia czyszczenia usuwa użycie pozwala na cofanie zmian w deploymentach; zawsze dostępne są poprzednie stany. i umieszcza polecenie git clean po kroku zrzutu.
Ponieważ ta zmiana zachowania może wpłynąć na niektórych użytkowników, przygotowaliśmy parametr FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Ustawienie wartości true, przywróci legacy-strategię czyszczenia. Więcej o używaniu parametrów funkcji w GitLab Runner można znaleźć .
W GitLab Runner 12.0 usuniemy wsparcie dla legacy-strategii czyszczenia oraz możliwość przywracania jej za pomocą parametru funkcji. Szczegóły znajdziesz w .
Data usunięcia: 22 czerwca 2019 r.
Sekcja Informacje systemowe w panelu administratora
GitLab przedstawia informacje o Twoim widoku GitLab w admin/system_info, ale te informacje mogą być nieprecyzyjne.
My panelu administratora w GitLab 12.0 i zalecamy korzystanie z .
Data usunięcia: 22 czerwca 2019 r.
Dziennik zmian
Szukaj wszystkich tych zmian w dzienniku zmian:
Instalacja
Jeśli konfigurowasz nową instalację GitLab, odwiedź .
Aktualizacja
Zajrzyj na .
Plany subskrypcyjne GitLab
GitLab dostępny jest w dwóch wariantach: i .
: lokalnie lub na preferowanej platformie chmurowej.
- Rdzeń: dla małych zespołów, projektów osobistych lub nieograniczonej wersji próbnej GitLab.
- Starter: dla zespołów pracujących w jednym biurze nad wieloma projektami, które potrzebują profesjonalnego wsparcia.
- Premium: dla rozproszonych zespołów, które potrzebują zaawansowanych funkcji, wysokiej dostępności i wsparcia 24/7.
- Ultimate: dla przedsiębiorstw, które wymagają solidnej strategii i realizacji z poprawionym bezpieczeństwem i zgodnością.
— GitLab.com: hostowany, zarządzany i administrowany przez GitLab na dla indywidualnych developerów i zespołów.
- Darmowe: nieograniczone prywatne repozytoria i nieograniczona liczba uczestników projektu. Projekty zamknięte mają dostęp do funkcji poziomu Darmowe, a mają dostęp do funkcji poziomu Gold.
- Bronze: dla zespołów, które potrzebują dostępu do zaawansowanych funkcji roboczego procesu.
- Silver: dla zespołów, które potrzebują bardziej niezawodnych możliwości DevOps, zgodności i szybkiego wsparcia.
- Gold: odpowiednie do wielu zadań CI/CD. Wszystkie projekty otwarte mogą korzystać z funkcji Gold za darmo, niezależnie od planu.
Źródło: habr.com
