GitLab 11.10 z potokami pulpitu nawigacyjnego, potokami scalonych wyników i sugestiami wielowierszowymi w żądaniach łączenia.
Wygodne informacje na temat wydajności rurociągów w różnych projektach
GitLab stale zwiększa wgląd w cykl życia DevOps. W tym numerze na панель управления dodano przegląd stanu rurociągu.
Jest to wygodne, nawet jeśli studiujesz przebieg pojedynczego projektu, ale jest szczególnie przydatne, jeśli kilka projektów, - i zwykle dzieje się tak, jeśli korzystasz z mikrousług i chcesz uruchomić potok do testowania i dostarczania kodu z różnych repozytoriów projektów. Teraz możesz natychmiast zobaczyć wydajność rurociągi na panelu sterowania, gdziekolwiek są wykonywane.
Uruchamianie potoków dla scalonych wyników
Z biegiem czasu gałęzie źródłowa i docelowa rozchodzą się i może powstać sytuacja, w której radzą sobie osobno, ale razem nie działają. Teraz możesz uruchamiaj potoki dla połączonych wyników przed połączeniem. W ten sposób szybko zauważysz błędy, które pojawiałyby się tylko wtedy, gdyby zmiany były często przenoszone pomiędzy gałęziami, co oznacza, że znacznie szybciej poprawisz błędy potoku i skorzystasz z opcji Biegacz GitLab.
Dalsza optymalizacja współpracy
GitLab 11.10 dodaje jeszcze więcej funkcji zapewniających płynną współpracę i uproszczony przepływ pracy. W poprzedni numer wprowadziliśmy sugestie dotyczące próśb o połączenie, w przypadku których recenzent może zasugerować zmianę jednej linii w komentarzu do prośby o połączenie i można ją natychmiast zatwierdzić bezpośrednio z wątku komentarzy. Naszym użytkownikom się to spodobało i poprosili o rozszerzenie tej funkcji. Teraz możesz zaoferować zmiany dla wielu linii, wskazując, które linie usunąć, a które dodać.
Najcenniejszy pracownik tego miesiąca (MVP) — Takuya Noguchi
Najcenniejszym pracownikiem tego miesiąca jest Takuya Noguchi (Takuya Noguchi). Takuya wykonał dobrą robotę na chwałę GitLaba: naprawiono błędy, uzupełniono braki w backendzie i frontendzie oraz udoskonalono interfejs użytkownika. Dziękuję!
Główne cechy GitLaba 11.10
Rurociągi na panelu sterowania
PREMIUM, NAJLEPSZY, SREBRNY, ZŁOTY
Panel w GitLab wyświetla informacje o projektach w całej instancji GitLab. Dodajesz pojedyncze projekty pojedynczo i możesz wybrać, który projekt Cię interesuje.
W tej wersji dodaliśmy do pulpitu nawigacyjnego informacje o stanach potoków. Teraz programiści widzą funkcjonalność potoków we wszystkich niezbędnych projektach - w jednym interfejsie.
Potoki dla scalonych wyników
PREMIUM, NAJLEPSZY, SREBRNY, ZŁOTY
Często zdarza się, że gałąź źródłowa z czasem odbiega od gałęzi docelowej, chyba że stale wprowadzasz zmiany między nimi. W rezultacie potoki gałęzi źródłowej i docelowej są „ekologiczne” i nie ma konfliktów scalania, ale scalanie kończy się niepowodzeniem z powodu niezgodnych zmian.
Kiedy potok żądania scalania automatycznie tworzy nowe łącze zawierające łączny wynik scalania gałęzi źródłowej i docelowej, możemy uruchomić potok na tym łączu i upewnić się, że ogólny wynik działa.
Jeśli używasz potoków żądań scalania (w dowolnej pojemności) i używasz prywatnych programów uruchamiających GitLab w wersji 11.8 lub starszej, będziesz musiał je zaktualizować, aby uniknąć tego problemu gitlab-ee#11122. Nie ma to wpływu na użytkowników publicznych programów uruchamiających GitLab.
Pracując wspólnie nad prośbami o połączenie, często dostrzegasz problemy i proponujesz rozwiązania. Od wersji GitLab 11.6 wspieramy propozycja zmian dla jednej linii.
W wersji 11.10 komentarze różnicowe dotyczące żądania scalania mogą proponować zmiany w wielu wierszach, a następnie każdy, kto ma uprawnienia do zapisu w oryginalnej gałęzi, może je zaakceptować jednym kliknięciem. Dzięki nowej funkcji można uniknąć kopiowania i wklejania, tak jak w poprzednich wersjach.
Skróty w jednym obszarze
PREMIUM, NAJLEPSZY, SREBRNY, ZŁOTY
Dzięki etykietom w tym samym zakresie zespoły mogą stosować wzajemnie wykluczające się etykiety (w tym samym zakresie) do problemu, żądania scalania lub epickiego w scenariuszach z niestandardowymi polami lub niestandardowymi stanami przepływu pracy. Są one konfigurowane przy użyciu specjalnej składni dwukropka w tytule etykiety.
Załóżmy, że potrzebujesz niestandardowego pola w zadaniach, aby śledzić system operacyjny platformy, na którą skierowane są Twoje funkcje. Każde zadanie musi dotyczyć tylko jednej platformy. Możesz tworzyć skróty platform::iOS, platform::Android, platform::Linux i inne w miarę potrzeb. Jeśli zastosujesz jeden taki skrót do zadania, automatycznie usunie on inny istniejący skrót zaczynający się od platform::.
Powiedzmy, że masz skróty workflow::development, workflow::review и workflow::deployed, wskazując stan przepływu pracy Twojego zespołu. Jeśli zadanie ma już skrót workflow::development, a programista chce przenieść zadanie na scenę workflow::review, po prostu stosuje nowy skrót i stary (workflow::development) jest automatycznie usuwany. To zachowanie już istnieje, gdy przenosisz zadania pomiędzy listami skrótów 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ą sami zmieniać stan przepływu pracy w zadaniach.
Jeśli zazwyczaj używasz rejestru kontenerów z potokami CI, wypychasz wiele oddzielnych zmian do jednego tagu. Ze względu na implementację dystrybucji Dockera domyślnym zachowaniem jest zapisywanie wszystkich zmian w systemie, ale ostatecznie zajmują one dużo pamięci. Jeśli używasz parametru -m с registry-garbage-collectmożesz szybko usunąć wszystkie poprzednie zmiany i zwolnić cenne miejsce.
Zakup dodatkowych minut CI Runner
BRĄZ, SREBRO, ZŁOTO
Użytkownicy posiadający płatne plany GitLab.com (Gold, Silver, Bronze) mogą teraz kupić dodatkowe minuty CI Runner. Wcześniej konieczne było dotrzymanie kwoty przewidzianej w planie. Dzięki temu udoskonaleniu możesz wykupić z wyprzedzeniem minuty przekraczające limit, aby uniknąć przerw spowodowanych przestojami rurociągów.
Teraz 1000 minut kosztuje 8 dolarów i możesz kupić ich dowolną liczbę. Dodatkowe minuty zaczną być wykorzystywane po wykorzystaniu całego miesięcznego limitu, a pozostała część dodatkowych minut przejdzie na następny miesiąc. W przyszłe wydanie chcemy dodać tę funkcję również do bezpłatnych planów.
Dzięki Auto DevOps zespoły przechodzą na nowoczesne praktyki DevOps niemal bez wysiłku. Począwszy od GitLab 11.10, każde zadanie w Auto DevOps jest dostarczane jako niezależny szablon. Użytkownicy mogą korzystać функцию includes w GitLab CI, aby umożliwić poszczególne etapy Auto DevOps i jednocześnie korzystać z własnego pliku gitlab-ci.yml. W ten sposób możesz włączyć tylko te zadania, których potrzebujesz i skorzystać z wcześniejszych aktualizacji.
Automatycznie zarządzaj członkami grupy na GitLab.com przy użyciu SCIM
SREBRNE ZŁOTO
Wcześniej trzeba było ręcznie zarządzać członkostwem w grupach na GitLab.com. Możesz teraz używać SAML SSO i zarządzać członkostwem przy użyciu standardu SCIM, aby tworzyć, usuwać i aktualizować użytkowników w witrynie GitLab.com.
Jest to szczególnie przydatne dla firm z dużą liczbą użytkowników i scentralizowanych dostawców tożsamości. Teraz możesz mieć jedno źródło prawdy, takie jak Azure Active Directory, a użytkownicy będą tworzeni i usuwani automatycznie za pośrednictwem dostawcy tożsamości, a nie ręcznie.
Zaloguj się do GitLab.com poprzez dostawcę SAML
SREBRNE ZŁOTO
Wcześniej w przypadku korzystania z logowania jednokrotnego SAML dla grup użytkownik musiał zalogować się przy użyciu poświadczeń GitLab i dostawcy tożsamości. Możesz teraz bezpośrednio zalogować się poprzez SSO jako użytkownik GitLab powiązany ze skonfigurowaną grupą.
Użytkownicy nie będą musieli logować się dwukrotnie, co ułatwi firmom korzystanie z logowania jednokrotnego SAML w witrynie GitLab.com.
Inne ulepszenia w GitLab 11.10
Dziecięcy schemat epicki
NAJLEPSZY, ZŁOTY
W poprzedniej wersji dodaliśmy epopeje podrzędne (eposy epopei), aby pomóc Ci zarządzać strukturą dystrybucji stanowisk. Eposy podrzędne pojawiają się na stronie epopei nadrzędnej.
W tej wersji strona eposów nadrzędnych wyświetla zarys eposów podrzędnych, dzięki czemu zespoły mogą zobaczyć oś czasu eposów podrzędnych i zarządzać zależnościami czasowymi.
W tej wersji wprowadzamy ekrany informacyjne, które pojawiają się po najechaniu kursorem na link żądania połączenia. Poprzednio pokazywaliśmy tylko tytuł żądania scalania, ale teraz pokazujemy także status żądania scalania, status potoku CI i krótki adres URL.
Przepływy pracy Git związane z wydawaniem lub dostarczaniem oprogramowania często obejmują wiele długoterminowych gałęzi — w celu wprowadzenia poprawek do poprzednich wersji (np. stable-11-9) lub przejście od testów jakościowych do produkcji (np. integration), ale nie jest łatwo znaleźć prośby o połączenie dla tych gałęzi wśród wielu otwartych próśb o połączenie.
Listę żądań połączenia dla projektów i grup można teraz filtrować według docelowej gałęzi żądania połączenia, aby ułatwić znalezienie tej, której potrzebujesz.
Jeśli zastosujemy metodę rozwoju w oparciu o trunking, powinniśmy unikać oddziałów długowiecznych na rzecz małych, tymczasowych oddziałów z jednym właścicielem. Małe zmiany są często wypychane bezpośrednio do gałęzi docelowej, ale może to spowodować uszkodzenie kompilacji.
W tej wersji GitLab obsługuje nowe opcje wypychania Git, które umożliwiają automatyczne otwieranie żądań scalania, ustawianie gałęzi docelowej i wymuszanie scalania w pomyślnym potoku z wiersza poleceń w momencie wypychania do gałęzi.
GitLab może uzyskać dostęp do wielu serwerów Prometheus (środowisko, projekt i grupy (oczekiwane)), ale posiadanie wielu punktów końcowych może zwiększyć złożoność lub może nie być obsługiwane przez standardowe pulpity nawigacyjne. W tej wersji zespoły mogą korzystać z jednego interfejsu API Prometheus, co znacznie ułatwia integrację z usługami takimi jak Grafana.
Na Wiki projektu zespoły mogą udostępniać dokumentację i inne ważne informacje wraz z kodem źródłowym i zadaniami. W tej wersji możesz sortować listę stron Wiki według daty utworzenia i tytułu, aby szybko znaleźć ostatnio utworzoną zawartość.
Monitorowanie zasobów żądanych przez klaster
NAJLEPSZY, ZŁOTY
GitLab pomaga monitorować klaster Kubernetes pod kątem aplikacji programistycznych i produkcyjnych. Począwszy od tej wersji, monitoruj żądania procesora i pamięci z klastra, aby wykryć potencjalne problemy, zanim staną się problemami.
Wyświetl wskaźniki modułu równoważenia obciążenia w panelu kontrolnym Grafana
PODSTAWOWE, STARTOWE, PREMIUM, ULTIMATE
Bardzo ważne jest monitorowanie stanu instancji GitLab. Wcześniej udostępnialiśmy domyślne pulpity nawigacyjne poprzez osadzoną instancję Grafana. Począwszy od tej wersji, dodaliśmy dodatkowe pulpity nawigacyjne do monitorowania modułów równoważenia obciążenia NGINX.
SAST dla Eliksiru
NAJLEPSZY, ZŁOTY
Stale rozwijamy obsługę języków i pogłębiamy kontrole bezpieczeństwa. W tej wersji włączyliśmy kontrolę bezpieczeństwa projektów w witrynie Eliksir i projekty stworzone na Platforma Feniks.
Wiele zapytań na jednym diagramie
PREMIUM, NAJLEPSZY, SREBRNY, ZŁOTY
W GitLab możesz tworzyć wykresy w celu wizualizacji zbieranych metryk. Często, jeśli na przykład chcesz sprawdzić maksymalną lub średnią wartość metryki, chcesz wyświetlić kilka wartości na jednym wykresie. Począwszy od tej wersji, masz taką możliwość.
Wyniki DAST na pulpicie nawigacyjnym bezpieczeństwa grupy
Oprócz SAST, skanowania kontenerów i skanowania zależności dodaliśmy wyniki dynamicznego testowania bezpieczeństwa aplikacji (DAST) do panelu bezpieczeństwa zespołu.
Dodawanie metadanych do raportu skanowania kontenera
NAJLEPSZY, ZŁOTY
W tej wersji raport skanowania kontenera zawiera więcej metadanych – dodaliśmy dotknięty komponent (funkcja Clair) do istniejących metadanych: priorytet, identyfikator (w odniesieniu do mitre.org) i poziom, którego dotyczy problem (np. debian:8).
Dodanie typu raportu metryk do żądań scalania
PREMIUM, NAJLEPSZY, SREBRNY, ZŁOTY
GitLab udostępnia już kilka typów raportów, które można uwzględnić bezpośrednio w żądaniach scalania: od raportów do jakość kodu и testów jednostkowych na etapie weryfikacji do SAST и DZIEŃ na etapie ochrony.
Chociaż są to ważne raporty, potrzebne są również podstawowe informacje pasujące do różnych scenariuszy. W GitLab 11.10 zapewniamy raportowanie metryk bezpośrednio w żądaniu scalania, które oczekuje prostej pary klucz-wartość. W ten sposób użytkownicy śledzą zmiany w czasie, w tym niestandardowe metryki i zmiany metryk dla konkretnego żądania połączenia. Użycie pamięci, specjalistyczne testowanie obciążenia i stany kondycji można przekształcić w proste metryki, które można przeglądać bezpośrednio w żądaniach scalania wraz z innymi wbudowanymi raportami.
Obsługa wielomodułowych projektów Maven do skanowania zależności
NAJLEPSZY, ZŁOTY
W tej wersji wielomodułowe projekty Maven obsługują skanowanie zależności GitLab. Poprzednio, jeśli podmoduł był zależny od innego podmodułu tego samego poziomu, nie mógł pozwolić na załadowanie z centralnego repozytorium Mavena. Teraz tworzony jest wielomodułowy projekt Maven z dwoma modułami i zależnością między nimi. Zależności między modułami rodzeństwa są teraz dostępne w lokalnym repozytorium Maven, dzięki czemu kompilacja może być kontynuowana.
Domyślnie GitLab Runner klonuje projekt do unikalnej ścieżki podrzędnej w $CI_BUILDS_DIR. Ale w przypadku niektórych projektów, takich jak Golang, kod musi zostać sklonowany do określonego katalogu, aby można go było zbudować.
W GitLab 11.10 wprowadziliśmy zmienną GIT_CLONE_PATH, co pozwala określić konkretną ścieżkę, w której GitLab Runner klonuje projekt przed wykonaniem zadania.
GitLab udostępnia kilka sposobów chronić и ograniczyć obszar zmienne w GitLab CI/CD. Jednak zmienne mogą nadal znajdować się w dziennikach kompilacji, celowo lub przypadkowo.
GitLab poważnie podchodzi do zarządzania ryzykiem i audytu i nadal dodaje funkcje zgodności. W GitLab 11.10 wprowadziliśmy możliwość maskowania niektórych typów zmiennych w logach śledzenia zadań, dodając poziom ochrony przed przypadkowym umieszczeniem zawartości tych zmiennych w logach. A teraz GitLab automatycznie maskuje wiele wbudowanych zmiennych tokenów.
Dzięki Auto DevOps w projekcie GitLab.com możesz bez problemu realizować nowoczesne przepływy pracy DevOps od kompilacji po dostawę.
Począwszy od GitLab 11.10, możesz włączyć lub wyłączyć Auto DevOps dla wszystkich projektów w tej samej grupie.
Uproszczona i ulepszona strona licencji
STARTER, PREMIUM, ULTIMATE
Aby zarządzanie kluczami licencyjnymi było wygodniejsze i prostsze, przeprojektowaliśmy stronę licencji w panelu administracyjnym i wyróżniliśmy najważniejsze elementy.
Zaktualizuj selektor skrótów dla wdrożeń Kubernetes
Panele wdrożeniowe wyświetlają informacje o wszystkich wdrożeniach Kubernetes.
W tej wersji zmieniliśmy sposób mapowania skrótów do wdrożeń. Mecze są teraz dostępne przez app.example.com/app и app.example.com/env lub app. Pozwoli to uniknąć konfliktów filtrowania i ryzyka nieprawidłowych wdrożeń związanych z projektem.
Integracja Kubernetes z GitLab pozwala na korzystanie z funkcji RBAC przy użyciu konta usługi i dedykowanej przestrzeni nazw dla każdego projektu GitLab. Począwszy od tej wersji, aby zapewnić maksymalną wydajność, zasoby te będą tworzone tylko wtedy, gdy będą potrzebne do wdrożenia.
Podczas wdrażania Kubernetes GitLab CI utworzy te zasoby przed wdrożeniem.
Klastry na poziomie grupy obsługują teraz instalację GitLab Runner. Moduły uruchamiające Kubernetes na poziomie grupy pojawiają się w projektach podrzędnych jako elementy uruchamiające grupę oznaczone cluster и kubernetes.
Funkcje wdrożone za pomocą GitLab bezserwerowy, pokaż teraz liczbę wywołań odebranych dla określonej funkcji. Aby to zrobić, musisz zainstalować Prometheus na klastrze, na którym zainstalowany jest Knative.
Kontrola parametrów git clean dla zadań GitLab CI/CD
Domyślnie działa GitLab Runner git clean podczas procesu przesyłania kodu podczas wykonywania zadania w GitLab CI/CD. Od wersji GitLab 11.10 użytkownicy mogą kontrolować parametry przekazywane zespołowi git clean. Jest to przydatne dla zespołów z dedykowanymi biegaczami, a także dla zespołów, które zbierają projekty z dużych monorepozytoriów. Teraz mogą kontrolować proces rozładunku przed wykonaniem skryptów. Nowa zmienna GIT_CLEAN_FLAGS wartość domyślna to -ffdx i akceptuje wszystkie możliwe parametry poleceń [git clean](https://git-scm.com/docs/git-clean).
Bezpieczne środowiska mogą wymagać dodatkowego zewnętrznego zasobu autoryzacyjnego, aby uzyskać dostęp do projektu. Dodaliśmy obsługę dodatkowego poziomu kontroli dostępu w 10.6 i otrzymałem wiele próśb o otwarcie tej funkcjonalności w Core. Z przyjemnością wprowadzamy zewnętrzną autoryzację i dodatkową warstwę zabezpieczeń dla instancji Core, gdyż taka funkcja jest potrzebna indywidualnym uczestnikom.
Rola Deweloper może tworzyć projekty w grupach od wersji 10.5, a teraz jest to możliwe w Core. Tworzenie projektów jest kluczową funkcją wpływającą na produktywność w GitLab, a dzięki włączeniu tej funkcji do Core, teraz członkowie mogą łatwiej zrobić coś nowego.
Dzisiaj wydaliśmy GitLab Runner 11.10! GitLab Runner to projekt typu open source, który służy do uruchamiania zadań CI/CD i wysyłania wyników z powrotem do GitLab.
Pełną listę zmian można znaleźć w dzienniku zmian GitLab Runner: CHANGELOG.
Korekta zwróconego project_id w interfejsie API wyszukiwania obiektów blob w Elasticsearch
STARTER, PREMIUM, ULTIMATE
Naprawiliśmy błąd w interfejsie API wyszukiwania obiektów blob Elasticsearch, który błędnie zwracał 0 dla project_id. To będzie konieczne ponownie zindeksuj Elasticsearchaby uzyskać prawidłowe wartości project_id po zainstalowaniu tej wersji GitLaba.
Ulepszenia omnibusa
PODSTAWOWE, STARTOWE, PREMIUM, ULTIMATE
W GitLab 11.10 wprowadziliśmy następujące ulepszenia Omnibusa:
W GitLabie 11.5 dodaliśmy ten wymóg do dokumentacji Geo: gitlab-ee#8053.
W GitLabie 11.6sudo gitlab-rake gitlab:geo:check sprawdza, czy włączona jest funkcja mieszania magazynu i czy wszystkie projekty zostały przeniesione. Cm. gitlab-ee#8289. Jeśli używasz Geo, przeprowadź tę kontrolę i przeprowadź migrację tak szybko, jak to możliwe.
W GitLabie 11.8 trwale wyłączone ostrzeżenie gitlab-ee!8433 zostaną wyświetlone na stronie Strefa administracyjna > Geo > Węzły, jeżeli powyższe kontrole nie są dozwolone.
W GitLabie 12.0 Geo będzie używać zaszyfrowanych wymagań dotyczących przechowywania. Cm. gitlab-ee#8690.
Canonical ogłosił koniec standardowego wsparcia dla Ubuntu 14.04 Kwiecień 2019. Zalecamy użytkownikom aktualizację do obsługiwanej wersji LTS: Ubuntu 16.04 lub Ubuntu 18.04.
Data usunięcia: 22 maja 2019 miasto
Ograniczenie maksymalnej liczby potoków utworzonych na jedno zgłoszenie
Wcześniej GitLab tworzył potoki dla HEAD każdego oddziału w zgłoszeniu. Jest to wygodne dla programistów, którzy wypychają kilka zmian jednocześnie (na przykład do gałęzi funkcji i do gałęzi develop).
Jednak w przypadku wypychania dużego repozytorium z wieloma aktywnymi gałęziami (na przykład przenoszeniem, tworzeniem kopii lustrzanych lub rozgałęzianiem) nie trzeba tworzyć potoku dla każdej gałęzi. Zaczynając od GitLab 11.10 tworzymy maksymalnie 4 rurociągi podczas wysyłania.
Data usunięcia: 22 maja 2019 miasto
Nieaktualne ścieżki kodu starszego narzędzia GitLab Runner
Począwszy od Gitlab 11.9, GitLab Runner używa nowa metoda klonowanie/wywoływanie repozytorium. Obecnie GitLab Runner będzie używał starej metody, jeśli nowa nie jest obsługiwana. Więcej szczegółów znajdziesz w to zadanie.
W GitLab 11.0 zmieniliśmy wygląd konfiguracji serwera metryk dla GitLab Runner. metrics_server zostaną usunięte na korzyść listen_address w GitLabie 12.0. Więcej szczegółów znajdziesz w to zadanie.
Te ścieżki nie będą dostępne w GitLab 12.0. Jako użytkownik nie musisz nic zmieniać poza upewnieniem się, że Twoja instancja GitLab działa w wersji 11.9 lub nowszej podczas aktualizacji do GitLab Runner 12.0.
Data usunięcia: 22 2019 czerwca
Przestarzały parametr funkcji punktu wejścia dla GitLab Runner
W GitLab 12.0 przełączymy się na prawidłowe zachowanie, tak jakby ustawienie funkcji było wyłączone. Więcej szczegółów znajdziesz w to zadanie.
Data usunięcia: 22 2019 czerwca
Przestarzała obsługa dystrybucji Linuksa osiągająca EOL dla GitLab Runner
Niektóre dystrybucje Linuksa, na których można zainstalować GitLab Runner, spełniły swoje zadanie.
W GitLab 12.0 GitLab Runner nie będzie już dystrybuował pakietów do takich dystrybucji Linuksa. Pełną listę dystrybucji, które nie są już obsługiwane, można znaleźć w naszym dokumentacja. Dzięki Javierowi Ardo (Javiera Jardona) za jego wkład!
W GitLab 12.0 GitLab Runner jest uruchamiany przy użyciu nowych poleceń. Dotyczy to tylko użytkowników, którzy zastąpić obraz pomocniczy. Więcej szczegółów znajdziesz w to zadanie.
Data usunięcia: 22 2019 czerwca
Usuwanie starszego mechanizmu git clean z GitLab Runner
W GitLab Runner 11.10 zapewniamy możliwość skonfiguruj sposób, w jaki Runner wykonuje polecenie git clean. Ponadto nowa strategia czyszczenia eliminuje użycie git reset i wydaje polecenie git clean po etapie rozładunku.
Ponieważ ta zmiana zachowania może dotyczyć niektórych użytkowników, przygotowaliśmy parametr FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Jeśli ustawisz wartość true, przywróci starszą strategię czyszczenia. Więcej na temat wykorzystania parametrów funkcji w GitLab Runnerze znajdziesz w dokumentacji.
W GitLab Runner 12.0 usuniemy obsługę starszej strategii czyszczenia i możliwość jej przywrócenia za pomocą parametru funkcji. Więcej szczegółów znajdziesz w to zadanie.
Data usunięcia: 22 2019 czerwca
Sekcja Informacje o systemie w panelu administracyjnym
GitLab prezentuje informacje o Twojej instancji GitLab w admin/system_info, ale te informacje mogą nie być dokładne.
Darmowy: Nieograniczone prywatne repozytoria i nieograniczona liczba współautorów projektu. Zamknięte projekty mają dostęp do funkcji poziomu DarmowyMieć otwarte projekty mieć dostęp do funkcji poziomu Złoto.
Brąz: Dla zespołów, które potrzebują dostępu do zaawansowanych funkcji przepływu pracy.
Srebro: Dla zespołów, które potrzebują bardziej niezawodnych możliwości DevOps, zgodności i szybszego wsparcia.
Złoto: Nadaje się do wielu zadań CI/CD. Wszystkie otwarte projekty mogą bezpłatnie korzystać z funkcji Gold, niezależnie od planu.