Wydano wersję 13.4 z przechowalnią HashiCorp dla zmiennych CI, agentem Kubernetes i centrum bezpieczeństwa, a także przełączanymi funkcjami w Starter.
W GitLab zawsze myślimy o tym, jak pomóc użytkownikom zmniejszyć ryzyko, zwiększyć efektywność i przyspieszyć dostarczanie na Twojej ulubionej platformie. W tym miesiącu dodaliśmy wiele przydatnych nowości, które rozszerzają możliwości bezpieczeństwa, redukują liczbę podatności, zwiększają efektywność, upraszczają pracę z GitLab i pomagają Twojemu zespołowi dostarczać funkcje jeszcze szybciej. Mamy nadzieję, że podstawowe funkcje wydania oraz 53 inne nowe funkcje, dodane w tym wydaniu.
Rozszerzone możliwości bezpieczeństwa
Staramy się dodawać kilka nowych funkcji do GitLab DevSecOps każdego miesiąca, a to wydanie nie jest wyjątkiem. w ramach budowy i wdrażania. Ponadto organizacje, które chcą utrzymać podział obowiązków przy wdrażaniu kodu, mogą teraz . Ta rola odpowiada i umożliwi zatwierdzanie merge requestów (w polskiej lokalizacji GitLab 'prośby o scalenie') oraz wdrażanie kodu w zabezpieczonych środowiskach bez udzielania dostępu do samego kodu.
Kolejnym sposobem na zmniejszenie ryzyka jest wykorzystanie nowego Specjaliści z działu operacji mogą wdrażać klastry Kubernetes z GitLab bez konieczności otwierania dostępu do swojego klastra dla całego internetu. Wprowadzamy także automatyczne wsparcie kontroli wersji dla nowych plików stanu Terraform z w celu wsparcia zgodności z wymaganiami i ułatwienia debuggowania. I wreszcie, panel sterowania bezpieczeństwem w instancji stał się z raportami o podatnościach i ustawieniami bezpieczeństwa.
Bardziej wygodna i efektywna praca z GitLab
Udoskonaliliśmy nasze globalne wyszukiwanie, dodając do niego , umożliwiającą łatwe przechodzenie do ostatnich zgłoszeń, grup, projektów, ustawień i sekcji pomocy. Z radością ogłaszamy, że w GitLab Pages do przekierowywania poszczególnych stron i katalogów w ramach witryny, co pozwoli użytkownikom na efektywniejsze rozwijanie swoich witryn. Dla tych, którzy chcieliby uzyskać bardziej szczegółowe informacje na temat wdrażania, ta wersja umożliwia !
Wkłady z otwartym kodem źródłowym
Prezentujemy , które dodał . Adnotacje o pokryciu testami jednostkowymi zmienionego kodu dają deweloperom wizualne przedstawienie pokrycia kodu podczas przeglądów; ta informacja pomaga przyspieszyć przegląd i skraca czas scalania oraz wdrażania nowego kodu. A także i planujemy .
I to dopiero początek!
Jak zawsze, w ogólnym przeglądzie jest za mało miejsca, a w wersji 13.4 jest wiele wspaniałych funkcji. Oto kilka kolejnych:
- .
Jeśli chcesz wiedzieć, co czeka Cię w następnej wersji, sprawdź .
.
tego miesiąca —
Fabio wniósł znaczący do — funkcję, na którą społeczność GitLab czekała od dawna. To naprawdę ważny wkład z nieszablonowymi zmianami, które wymagały stałej współpracy z członkami zespołu GitLab i obejmowały wiele obszarów projektu, takich jak UX, frontend i backend.
Podstawowe funkcje wersji GitLab 13.4
Używaj kluczy HashiCorp Vault w zadaniach CI
(PREMIUM, ULTIMATE, SILVER, GOLD)
W wersji 12.10 GitLab wprowadził możliwość odbierania i przesyłania kluczy w zadaniach CI za pomocą agenta zadań GitLab (GitLab runner). Teraz rozszerzamy , dodając nową składnię secrets do pliku .gitlab-ci.yml. Ułatwi to konfigurację i użycie magazynu HashiCorp z GitLab.
i .
Prezentujemy GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
Integracja GitLab z Kubernetes umożliwia wdrażanie na klastrach Kubernetes bez konieczności ręcznej konfiguracji. Wiele osób doceniło prostotę użytkowania tego połączenia, ale inni napotkali pewne trudności. Aby zrealizować tę integrację, Twój klaster musi być dostępny z Internetu, aby GitLab mógł się do niego dostać. Dla wielu organizacji jest to niemożliwe, gdyż ograniczają dostęp do klastrów z powodów bezpieczeństwa, zgodności z przepisami lub regulacjami. Aby obejść te ograniczenia, użytkownicy musieli tworzyć własne narzędzia na bazie GitLab, inaczej nie mogliby skorzystać z tej funkcjonalności.
Dziś przedstawiamy GitLab Kubernetes Agent – nowy sposób wdrażania na klastrach Kubernetes. Agent działa wewnątrz Twojego klastra, więc nie musisz go otwierać dla całego internetu. Agent koordynuje wdrożenie, żądając nowych zmian z GitLab, zamiast aby GitLab wysyłał aktualizacje do klastra. Niezależnie od metody GitOps, którą używasz, GitLab będzie odpowiedni.
Zauważ, że to pierwsza wersja agenta. Obecnie skupiliśmy się na konfiguracji i zarządzaniu wdrożeniem poprzez kod. Niektóre istniejące funkcje integracji Kubernetes, takie jak tablice wdrożeń i aplikacje zarządzane przez GitLab, nie są jeszcze wspierane. , że te funkcjonalności zostaną dodane do agenta w przyszłych wydaniach, a także nowe integracje skoncentrowane na bezpieczeństwie i zgodności z przepisami.
i .
Dostarczaj użytkownikom uprawnienia do wdrożenia bez dostępu do kodu
(PREMIUM, ULTIMATE, SILVER, GOLD)
Wcześniej system uprawnień w GitLab nie umożliwiał właściwego podziału obowiązków w Twoim zespole między tymi, którzy są odpowiedzialni za rozwój, a tymi, którzy są odpowiedzialni za wdrożenie. Dzięki wydaniu GitLab 13.4 możesz przyznać pozwolenie na zatwierdzanie merge requestów do wdrożeń, a także na faktyczne wdrożenie kodu osobom, które nie programują, jednocześnie nie dając im praw dostępu maintenanta.
i .
Centrum bezpieczeństwa
(ULTIMATE, GOLD)
Wcześniejsze zarządzanie podatnościami na poziomie instancji było ograniczone zarówno pod względem funkcjonalności, jak i elastyczności. Interfejs stanowił jedną stronę, która łączyła szczegóły dotyczące podatności, wykresy metryk i ustawienia. Nie było zbyt wielu możliwości rozwoju tych funkcji ani wykorzystania innych narzędzi zabezpieczających.
Wprowadziliśmy fundamentalne zmiany w zarządzaniu bezpieczeństwem i jego przejrzystością w GitLab. Panel bezpieczeństwa instancji przekształcił się w cały centrum bezpieczeństwa. Największą zmianą jest wprowadzenie nowej struktury menu: zamiast jednej strony teraz osobno widzisz panel sterowania bezpieczeństwem, raport o podatnościach i sekcję ustawień. Choć funkcjonalność nie uległa zmianie, podział ten pozwoli na poprawę tej części, co w przeciwnym razie byłoby utrudnione. Tworzy to również fundament do dodawania w przyszłości innych funkcji związanych z bezpieczeństwem.
Specjalna sekcja dla raportu o podatnościach ma teraz więcej miejsca na wyświetlanie istotnych szczegółów. Zgromadzono tutaj podatności, które obecnie znajdują się na liście podatności projektu. Przeniesienie widgetów z metrykami podatności do osobnej sekcji tworzy wygodny panel sterowania bezpieczeństwem. Teraz jest to płótno dla przyszłych wizualizacji — nie tylko do zarządzania podatnościami, ale i do wszelkich metryk związanych z bezpieczeństwem. Wreszcie, osobny obszar ustawień tworzy wspólną przestrzeń dla wszystkich ustawień bezpieczeństwa na poziomie instancji, nie tylko dla zarządzania podatnościami.
i .
Funkcje przełączane dostępne teraz w GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
W wersji GitLab 11.4 wprowadzono . W wersji 12.2 wprowadziliśmy dla nich strategie i , a w wersji 13.1 dodaliśmy i dla różnych środowisk.
Na początku tego roku GitLab zobowiązał się do otwartego kodu. W tej wersji zakończyliśmy przenoszenie funkcji przełączanych do planu Starter i będziemy kontynuować ich przenoszenie do Core z . Cieszymy się, że możemy zaoferować tę możliwość większej liczbie użytkowników i chcemy wiedzieć, jak będziesz z nich korzystać.
i .
Szybka nawigacja z paska wyszukiwania
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Czasami podczas nawigacji po GitLabie chcesz bezpośrednio przejść do konkretnego projektu, a nie na stronę z wynikami wyszukiwania.
Dzięki panelowi globalnego wyszukiwania możesz szybko przejść do ostatnich zgłoszeń, grup, projektów, ustawień i sekcji pomocy. Możesz nawet użyć skrótu klawiszowego /, aby przenieść kursor na pasku wyszukiwania, co ułatwi poruszanie się po GitLabie!
i .
Wyświetlanie pokrycia kodu w różnicach między żądaniami scalania
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Podczas przeglądania żądania scalenia może być trudno określić, czy zmieniony kod jest pokryty testami jednostkowymi. Zamiast tego recenzenci mogą polegać na ogólnym pokryciu i wymaganiu jego zwiększenia, zanim zatwierdzą żądanie scalenia. Może to prowadzić do chaotycznego podejścia do pisania testów, co w rzeczywistości nie poprawi jakości kodu ani jego pokrycia testami.
Teraz przy przeglądaniu różnicy między żądaniem scalenia zobaczysz wizualne wyświetlenie pokrycia kodu. Nowe oznaczenia pozwolą szybko zrozumieć, czy zmieniony kod jest objęty testem jednostkowym, co pomoże przyspieszyć recenzję kodu oraz czas scalania i wdrażania nowego kodu.
Dziękuję i Siemens za tę funkcję!
i .
Więcej środowisk i projektów na panelu środowisk
(PREMIUM, ULTIMATE, SILVER, GOLD)
Od wersji GitLab 12.5 dzięki możesz śledzić stan środowisk, ale nie więcej niż siedem środowisk w trzech projektach. Poprawiliśmy ten panel w wersji 13.4, dzieląc go na strony, aby pomóc ci zarządzać swoimi środowiskami na większą skalę. Teraz możesz zobaczyć więcej środowisk w większej liczbie projektów.
i .
GitLab przejął zarządzanie dostawcą GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Niedawno i planujemy . W ciągu ostatniego miesiąca zaakceptowaliśmy 21 żądań scalania i zamknęliśmy 31 zgłoszeń, w tym niektóre długoterminowe błędy i brakujące funkcje, takie jak . Możesz w dokumentacji dotyczącej Terraform.
i .
Testowanie fuzzingowe API z specyfikacjami OpenAPI lub plikiem HAR
(ULTIMATE, GOLD)
Fuzzing testowanie API to doskonały sposób na wykrywanie błędów i luk w zabezpieczeniach twoich aplikacji internetowych i API, które mogą umknąć innym skanerom i metodom testowania.
Testowanie API fuzzingiem w GitLab umożliwia dostarczenie lub twojej aplikacji, a następnie automatycznie generuje losowe dane wejściowe, które mają na celu testowanie przypadków brzegowych i wykrywanie błędów. Wyniki są natychmiast wyświetlane w ramach twojego potoku.
To nasza pierwsza wersja testowania API fuzzingiem i chętnie poznamy twoje zdanie. Mamy jeszcze wiele , które będziemy rozwijać w oparciu o tę funkcjonalność.
i .
Podgląd nowych wykresów na pulpicie metrycznym
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wcześniej tworzenie wykresu na pulpicie metrycznym w GitLab było trudnym zadaniem. Po utworzeniu metryki w pliku YAML pulpitu, wprowadzałeś zmiany w master, nie mając możliwości sprawdzenia, czy właśnie stworzony wykres działa dokładnie tak, jak tego potrzebujesz. Począwszy od tej wersji możesz podglądać zmiany podczas tworzenia wykresu, uzyskując wgląd w wynik przed przesłaniem zmian do pliku YAML pulpitu.
i .
Dane o pokryciu kodu testami we wszystkich projektach grupy
(PREMIUM, ULTIMATE, SILVER, GOLD)
Gdy zarządzasz dużą ilością projektów w GitLab, potrzebujesz jednolitego źródła informacji o tym, jak w czasie zmienia się pokrycie kodu we wszystkich projektach. Wcześniej wyświetlanie tych informacji wymagało żmudnej i czasochłonnej pracy ręcznej: trzeba było pobrać dane o pokryciu kodu testami z każdego projektu i połączyć je w tabeli.
W wersji 13.4 dodano możliwość łatwego i szybkiego zebrania w .csv pliku wszystkich danych o pokryciu kodu we wszystkich projektach grupy lub w wybranej grupie projektów. Ta funkcjonalność to MVC, a wkrótce pojawi się możliwość .
i .
Wsparcie dla nowych języków do pełnego testowania fuzzingowego
(ULTIMATE, GOLD)
Ta wersja wprowadza wsparcie dla kilku nowych języków do testowania fuzzingowego, mającego na celu pełne pokrycie.
Teraz możesz ocenić wszystkie możliwości testowania fuzzing w swoich aplikacjach napisanych w Java, Rust i Swift oraz znaleźć błędy i luki, które mogą umknąć innym skanerom i metodom testowania.
i .
Powiadomienia na stronie głównej środowisk
(PREMIUM, ULTIMATE, SILVER, GOLD)
Strona środowisk pokazuje ogólny stan swoich środowisk. W tej wersji poprawiliśmy tę stronę, dodając wyświetlanie powiadomień. Uruchomione powiadomienia razem ze statusem twoich środowisk pomogą ci szybciej podjąć działania w celu rozwiązania powstałych problemów.
i .
Zagnieżdżone potoki mogą teraz uruchamiać swoje zagnieżdżone potoki
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Przy użyciu zagnieżdżonych potoków możliwe stało się uruchamianie nowych potoków wewnątrz potoków podrzędnych. Dodatkowy poziom głębokości może być przydatny, jeśli potrzebujesz elastyczności w generowaniu zmiennej liczby potoków.
Wcześniej przy użyciu zagnieżdżonych potoków każdy potok podrzędny wymagał przypisania wyzwalacza, ręcznie ustawionego w potoku nadrzędnym. Teraz możesz tworzyć zagnieżdżone potoki, które dynamicznie uruchomią dowolną liczbę nowych zagnieżdżonych potoków. Na przykład, jeśli masz monorepo, możesz dynamicznie generować pierwszy zagnieżdżony potok, który sam stworzy wymaganą liczbę nowych potoków, bazując na zmianach w gałęzi.
i .
Ulepszona nawigacja między potokami nadrzędnymi a zagnieżdżonymi
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Poruszanie się między potokami nadrzędnymi a zagnieżdżonymi wcześniej nie było zbyt wygodne — wymagało wielu kliknięć, aby dotrzeć do potrzebnego potoku. Ponadto trudno było zrozumieć, które zadanie uruchomiło dany potok. Teraz łatwiej będzie zobaczyć związki między potokami nadrzędnymi a zagnieżdżonymi.
i .
Równoległe zadania w macierzy wyświetlają odpowiednie zmienne w nazwie zadania
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Jeśli korzystałeś z , mogłeś zauważyć, że trudno było określić, która zmienna macierzy była używana dla danego zadania, ponieważ nazwy zadań wyglądały jak matrix 1/4. W wydaniu 13.4 będziesz widzieć odpowiednie wartości zmiennych użytych w tym zadaniu, zamiast ogólnej nazwy zadania. Na przykład, jeśli twoim celem jest debugowanie architektury x86, to zadanie będzie nosić nazwę matrix: debug x86.
i .
Inne ulepszenia w GitLab 13.4
Połączenie konta Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Użytkownicy GitLab teraz będą mogli łączyć swoje konta GitLab z kontem Atlassian Cloud. Umożliwi to logowanie się do GitLab za pomocą danych uwierzytelniających Atlassian oraz położy fundamenty pod przyszłe ulepszenia integracji i innymi produktami z rodziny Atlassian.
i .
Eksport listy wszystkich commitów merge
(ULTIMATE, GOLD)
Organizacje, które kładą nacisk na przestrzeganie wymagań, potrzebują sposobu, aby pokazać audytorom całościowy obraz komponentów związanych z jakąkolwiek konkretną zmianą w produkcji. W ramach GitLab oznacza to, że trzeba zebrać w jednym miejscu wszystko: merge requesty, tickety, pipeline'y, skanowanie bezpieczeństwa i inne dane o commitach. Do tej pory trzeba było albo ręcznie zbierać to w GitLab, albo konfigurować własne narzędzia do zbierania informacji, co nie było zbyt efektywne.
Teraz możesz programowo zbierać i eksportować te dane, aby spełnić wymagania audytu lub przeprowadzić inne analizy. Aby eksportować listę wszystkich commitów merge dla bieżącej grupy, musisz przejść do i kliknąć przycisk Lista wszystkich commitów merge. Plik uzyskany w wyniku tego będzie zawierał wszystkie commity merge requesta, ich autora, ID powiązanego merge requesta, grupę, projekt, zatwierdzających i inne informacje.
i .
Wyjście listy i zarządzanie osobistymi tokenami dostępu przez API
(ULTIMATE, GOLD)
Zarządzanie dostępem do przestrzeni nazw GitLab jest istotną częścią działalności związanej z przestrzeganiem wymogów. Od zasady minimalnych uprawnień po tymczasowe wyłączanie dostępu — mogą istnieć różne wymagania dotyczące osobistych tokenów dostępu w GitLab. Aby ułatwić utrzymanie i zarządzanie wszystkimi tymi danymi użytkowników w ramach Twojej przestrzeni nazw, umożliwiliśmy wygenerowanie listy wszystkich osobistych tokenów dostępu oraz opcjonalnie poprzez API.
Te usprawnienia w API GitLab pozwalają użytkownikom generować listę i unieważniać swoje osobiste tokeny dostępu, a administratorom — generować listę i unieważniać tokeny swoich użytkowników. Teraz administratorzy będą łatwiej widzieć, kto ma dostęp do ich przestrzeni nazw, podejmować decyzje o przyznawaniu dostępu na podstawie danych użytkowników oraz unieważniać osobiste tokeny dostępu, które mogły zostać skompromitowane lub które są niezgodne z zasadami firmy dotyczącymi zarządzania dostępem.
i .
Powiązane zgłoszenia i inne funkcje są teraz w GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Kilka miesięcy temu ogłosiliśmy plan . Pracując nad realizacją tej obietnicy, dokonaliśmy , i (w polskiej lokalizacji GitLab 'tablica dyskusyjna') dostępnymi w planie Core. Dotyczy to tylko relacji typu 'powiązane z', relacje typu 'blokuje' i 'jest blokowane' pozostają w płatnych planach.
i .
Wyświetlanie nazwy oryginalnej gałęzi w bocznym panelu prośby o scalanie
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Podczas przeglądania zmian kodu, dyskusji i commitów prośby o scalanie często warto wykonać lokalne checkout gałęzi, aby uzyskać dokładniejszy przegląd. Jednak znalezienie nazwy gałęzi staje się coraz trudniejsze w miarę dodawania większej liczby treści do opisu prośby o scalanie, co wymusza przewijanie strony.
Dodaliśmy nazwę gałęzi do bocznego panelu prośby o scalanie, co czyni ją dostępną w każdej chwili i eliminuje konieczność przewijania całej strony. Podobnie jak link do prośby o scalanie, sekcja z oryginalną gałęzią zawiera wygodny przycisk 'skopiuj'.
Dziękuję za ogromny wkład w rozwój tej funkcji!
i .
Wskazanie na obecność zwinętych plików w diffach merge requestu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Merge requesty, które wprowadzają zmiany do kilku plików, czasami zwijają długi diff dużych plików, aby poprawić wydajność wyświetlania. Kiedy to się dzieje, można przypadkowo przeoczyć plik podczas przeglądu, szczególnie w merge requestach z dużą liczbą plików. Od wersji 13.4 merge requesty będą oznaczać diffy zawierające zwinęte pliki, dzięki czemu nie przegapisz tych plików podczas przeglądu kodu. W celu jeszcze większej klarowności planujemy dodać podświetlenie tych plików w przyszłej wersji. Śledź aktualizacje w .
i .
Ostrzeżenie o obecności zwinętych plików w dymanie merge requestu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
W sekcji z dyfami merge requestów duże pliki są zwijane w celu zwiększenia wydajności. Jednak podczas przeglądania kodu niektóre pliki mogą być pominięte, gdy recenzent przewija listę plików, ponieważ wszystkie duże pliki są zwinęte.
Dodaliśmy widoczne ostrzeżenie u góry strony dyfu merge requestu, aby informować użytkowników, że w tej sekcji jest zwinęty plik. W ten sposób nie przegapisz żadnych zmian w merge requestcie podczas przeglądu.
i .
Automatyczne przywracanie repozytoriów klastra Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wcześniej, gdy węzeł główny klastra Gitaly był wyłączany, repozytoria na tym węźle były oznaczane jako dostępne tylko do odczytu. Zapobiegało to utracie danych w sytuacjach, gdy na węźle były zmiany, które jeszcze nie zostały replikowane. Gdy węzeł ponownie się łączył, GitLab nie był automatycznie przywracany, a administratorzy musieli ręcznie uruchamiać proces synchronizacji lub godzić się na utratę danych. Inne sytuacje, takie jak nieudane zakończenie zadania replikacji na węźle podrzędnym, również mogły prowadzić do powstawania przestarzałych lub dostępnych tylko do odczytu repozytoriów. W tym przypadku repozytorium pozostawało przestarzałe, aż do wykonania następnej operacji zapisu, która uruchomiłaby zadanie replikacji.
Aby rozwiązać ten problem Teraz planuje zadanie replikacji, gdy wykryje przestarzałe repozytorium na jednym węźle i najnowszą wersję repozytorium na innym. To zadanie replikacji automatycznie aktualizuje repozytorium, eliminując potrzebę ręcznego przywracania danych. Automatyczne przywracanie zapewnia również szybkie aktualizacje węzłów podrzędnych, jeśli zadanie replikacji zakończy się niepowodzeniem, zamiast czekać na następną operację zapisu. Ponieważ wiele klastrów Gitaly przechowuje dużą liczbę repozytoriów, znacznie skraca to czas, który administratorzy i inżynierowie ds. niezawodności poświęcają na przywracanie danych po awarii.
Ponadto automatyczna naprawa uruchamia replikację repozytoriów na każdym nowym węźle Gitaly dodanym do klastra, co eliminuje ręczną pracę przy dodawaniu nowych węzłów.
i .
Oznacz zadanie do zrobienia jako zakończone na stronie projektu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Skuteczna komunikacja w GitLab opiera się na listach zadań do zrobienia. Jeśli zostałeś wymieniony w komentarzu, krytycznie ważne jest, aby móc przejść do zadania i albo zacząć coś robić, albo oznaczyć je jako już zakończone. Ważne jest również, aby móc przypisać zadanie do siebie, gdy potrzebujesz popracować nad czymś lub wrócić do tego później.
Wcześniej nie mogłeś dodawać zadań ani oznaczać ich jako zakończone podczas pracy nad projektami. To poważnie naruszało efektywność komunikacji między zespołami produktowymi, ponieważ zadania do zrobienia są kluczowym elementem przepływu pracy w GitLab.
W wersji 13.4 projekty doganiają komentarze do zgłoszeń pod względem wykorzystania zadań, co sprawia, że praca nad nimi jest bardziej spójna i efektywna.
i .
Udoskonalone przewodnictwo w rozwiązywaniu problemów dla CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ulepszyliśmy przewodnik po rozwiązywaniu problemów dla GitLab CI/CD, dodając dodatkowe informacje na temat powszechnych problemów, z którymi możesz się spotkać. Mamy nadzieję, że ulepszona dokumentacja będzie cennym zasobem, który pomoże Ci szybko i łatwo konfigurować i uruchamiać GitLab CI/CD.
i .
Prośby o scalanie już nie wypadają z kolejki scalania
(PREMIUM, ULTIMATE, SILVER, GOLD)
Wcześniej prośby o scalanie mogły przypadkowo wypaść z kolejki scalania z powodu późnych komentarzy. Jeśli prośba o scalanie była już w kolejce, a ktoś dodał do niej komentarz, który tworzył nowe nierozwiązane dyskusje, prośba o scalanie była uznawana za nieodpowiednią do scalania i wypadała z kolejki. Teraz, po dodaniu prośby o scalanie do kolejki, można dodawać nowe komentarze, nie obawiając się zakłócenia procesu scalania.
i .
Wyświetlanie wartości pokrycia kodu w prośbie o scalanie dla zadania
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Programiści powinni mieć możliwość zobaczenia wartości pokrycia kodu po zakończeniu potoku — nawet w złożonych scenariuszach, takich jak praca potoku z wieloma zadaniami, które trzeba przeanalizować, aby obliczyć wartość pokrycia. Wcześniej widżet prośby o scalanie pokazywał tylko średnią z tych wartości, co oznaczało, że musieliście przechodzić na stronę zadania i z powrotem do prośby o scalanie, aby uzyskać pośrednie wartości pokrycia. Aby zaoszczędzić czas i uniknąć tych zbędnych kroków, w widżecie wprowadziliśmy wyświetlanie średniej wartości pokrycia, zmiany między gałęzią docelową a źródłową oraz podpowiedź, która pokazuje wartość pokrycia dla każdego zadania, na podstawie którego obliczono średnią wartość.
i .
Usuwanie pakietów z rejestru pakietów podczas przeglądania grupy
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Rejestr pakietów GitLab to miejsce przechowywania i dystrybucji pakietów w różnych formatach. Gdy w Twoim projekcie lub grupie znajduje się wiele pakietów, musisz szybko zidentyfikować nieużywane pakiety i je usunąć, aby ludzie ich nie pobierali. Możesz usuwać pakiety ze swojego rejestru poprzez lub poprzez interfejs użytkownika rejestru pakietów. Jednak do tej pory nie mogłeś usuwać pakietów podczas przeglądania grupy przez interfejs użytkownika. W rezultacie musiałeś usuwać zbędne pakiety osobno dla każdego projektu, co było nieefektywne.
Teraz możesz usuwać pakiety podczas przeglądania rejestru pakietów grupy. Po prostu przejdź do strony rejestru pakietów grupy, przefiltruj pakiety według nazwy i usuń wszystkie niepotrzebne.
i .
Skalowanie pakietów Conan do poziomu projektu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Możesz używać repozytorium Conan w GitLab do publikacji i dystrybucji zależności C/C++. Wcześniej pakiety można było skalować tylko do poziomu instancji, ponieważ nazwa pakietu Conan mogła mieć maksymalnie 51 znaków. Jeśli chciałeś opublikować pakiet z podgrupy, na przykład gitlab-org/ci-cd/package-stage/feature-testing/conan, to było prawie niemożliwe.
Teraz możesz skalować pakiety Conan do poziomu projektu, co ułatwia publikację i dystrybucję zależności twoich projektów.
i .
Wsparcie dla nowych menedżerów pakietów i języków w skanowaniu zależności
(ULTIMATE, GOLD)
Cieszymy się, że możemy dodać skanowanie zależności dla projektów z kodem w C, C++, C# i .Net, które używają NuGet 4.9+ lub menedżerów pakietów Conan, do naszej listy . Teraz możesz włączać skanowanie zależności jako część etapu Secure, aby sprawdzać znane podatności zależności dodanych przez menedżerów pakietów. Znalezione podatności będą wyświetlane w twoim prośbie o scalanie wraz z poziomem ich niebezpieczeństwa, abyś wiedział przed wykonaniem scalania, jakie ryzyko niesie nowa zależność. Możesz również skonfigurować swój projekt tak, aby wymagał dla zależności z podatnościami o krytycznym (Critical), wysokim (High) lub nieznanym (Unknown) poziomie niebezpieczeństwa.
i .
Powiadomienia przy zmianie ustawienia prośby o scalanie na 'Scalaj po pomyślnym zakończeniu potoku'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Wcześniej, przy ustawianiu konfiguracji prośby o scalanie Scal, gdy zakończy się potok (Merge When Pipeline Succeeds, MWPS), żadne powiadomienie e-mail nie było wysyłane. Musiałeś ręcznie sprawdzać status lub czekać na powiadomienie o zakończeniu scalania. W tej wersji cieszymy się, że możemy przedstawić wkład użytkownika , który rozwiązał ten problem, dodając automatyczne wysyłanie powiadomień do wszystkich, którzy są subskrybowani do prośby o scalanie, gdy recenzent zmienia ustawienie scalania na MWPS.
i .
Tworzenie klastrów EKS z wersją Kubernetes określoną przez użytkownika
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Użytkownicy GitLab mogą teraz samodzielnie wybierać wersję Kubernetes, która zostanie udostępniona w EKS; mogą wybierać między wersjami 1.14–1.17.
i .
Tworzenie incydentów jako typów zgłoszeń
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nie każda występująca problematyka od razu uruchamia wysyłanie powiadomień: użytkownicy zgłaszają awarie, podczas gdy członkowie zespołów analizują problemy z wydajnością. Teraz incydenty stały się rodzajem zgłoszenia, co pozwala twoim zespołom szybko je tworzyć w ramach znanego przepływu pracy. Kliknij Nowe zadanie z dowolnego miejsca w GitLab, a w polu Typ wybierz Incydent.
i .
Wzmianka o powiadomieniach GitLab w Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Udoskonaliliśmy powiadomienia GitLab, dodając nowy typ wzmianki specjalnie dla nich w wersji GitLab Markdown, co ułatwia dzielenie się powiadomieniami i wzmiankowanie o nich. Użyj ^alert#1234, aby wzmiankować o powiadomieniu w dowolnym polu z formatowaniem Markdown: w incydentach, zgłoszeniach lub wnioskach o scalanie. To również pomoże ci określić zadania, które są tworzone z powiadomień, a nie ze zgłoszeń lub wniosków o scalanie.
i .
Przegląd obciążenia powiadomień związanych z incydentami
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Opis powiadomienia zawiera informacje krytyczne dla diagnozowania awarii i ich przywracania, które muszą być łatwo dostępne, aby nie trzeba było przełączać narzędzi lub kart podczas pracy nad rozwiązaniem incydentu. Incydenty utworzone z powiadomień wyświetlają pełny opis powiadomienia na karcie Szczegóły powiadomienia.
O 75% szybsze rozszerzone wyszukiwanie
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab, jako jednolita aplikacja, ma wyjątkową możliwość przyspieszenia wyszukiwania treści w całym procesie DevOps. W GitLab 13.4 rozszerzone wyszukiwanie zwraca wyniki o 75% szybciej, gdy jest , jak na GitLab.com.
i .
Przegląd usuniętych projektów dla administratorów
(CORE, STARTER, PREMIUM, ULTIMATE)
Funkcja opóźnionego usunięcia projektu została . Jednak wcześniej nie było możliwości zobaczenia w jednym miejscu wszystkich projektów oczekujących na usunięcie. Teraz administratorzy użytkowników instancji GitLab mogą przeglądać wszystkie projekty czekające na usunięcie w jednym miejscu - wraz z przyciskami umożliwiającymi łatwe przywracanie tych projektów.
Ta funkcja umożliwia administratorom lepsze kontrolowanie usuwania projektów, zbierając wszystkie niezbędne informacje w jednym miejscu i oferując możliwość anulowania niepożądanych działań związanych z usuwaniem.
Dziękuję za tę funkcję!
i .
Wsparcie dla reguł push dla grup zostało dodane do API
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Wcześniej reguły push dla grup można było ustawiać tylko, odwiedzając każdą grupę indywidualnie za pośrednictwem interfejsu użytkownika GitLab i stosując te zasady. Teraz możesz zarządzać tymi regułami przez API, wspierając swoje własne narzędzia i automatyzację GitLab.
i .
Cofnięcie osobistych tokenów dostępu dla zarządzanego przez siebie repozytorium danych
(ULTIMATE)
daje administratorom informacje niezbędne do zarządzania poświadczeniami użytkowników ich instancji GitLab. Ponieważ organizacje dążące do zgodności różnią się pod względem rygoru swoich zasad zarządzania poświadczeniami, dodaliśmy przycisk umożliwiający administratorom, w razie potrzeby, cofnięcie tokenu osobistego dostępu użytkownika (PAT). Teraz administratorzy mogą łatwo cofnąć potencjalnie skompromitowane PAT. Ta funkcjonalność jest przydatna dla organizacji, które potrzebują elastyczniejszych opcji zapewnienia zgodności, aby zminimalizować zakłócenia dla swoich użytkowników.
i .
Plik konfiguracyjny dla edytora statycznych stron internetowych
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
W GitLab 13.4 wprowadzamy nowy sposób konfigurowania edytora statycznych stron internetowych. Chociaż plik konfiguracyjny nie zapisuje ani nie pobiera żadnych parametrów w tej wersji, kładziemy fundamenty dla przyszłej konfiguracji zachowania edytora. W kolejnych wersjach dodamy do pliku .gitlab/static-site-editor.yml parametry do ustawienia , na którym , nadpisanie ustawień składni Markdown oraz innych ustawień edytora.
i .
Edytowanie części wprowadzającej pliku za pomocą edytora statycznych stron.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Część wprowadzająca (front matter) to elastyczny i wygodny sposób definiowania zmiennych strony w plikach danych przeznaczonych do przetwarzania przez generator statycznych stron. Zazwyczaj jest używana do ustawienia tytułu strony, szablonu układu lub autora, ale może być używana do przekazywania dowolnego typu metadanych do generatora podczas renderowania strony w HTML. Umieszczana na samym początku każdego pliku danych, część wprowadzająca jest zazwyczaj formatowana jako YAML lub JSON i wymaga spójnej oraz precyzyjnej składni. Użytkownicy, którzy nie są zaznajomieni z określonymi zasadami składni, mogą niezamierzenie wprowadzić nieprawidłowy format, co z kolei może prowadzić do problemów z formatowaniem lub nawet z awarią budowy.
Tryb edycji WYSIWYG edytora statycznych stron już ukrywa część wprowadzającą z edytora, aby zapobiec tym błędom formatowania. Niemniej jednak, nie pozwala to na zmianę wartości przechowywanych w tej części bez powrotu do edytowania w trybie kodu źródłowego. W GitLab 13.4 możesz uzyskać dostęp do dowolnego pola i edytować jego wartość w znanym interfejsie opartym na formularzach. Po naciśnięciu przycisku Ustawienia (Ustawienia) otworzy się panel, w którym wyświetlane jest pole formularza dla każdego klucza zdefiniowanego na początku. Pola są wypełnione bieżącą wartością, a aby edytować którekolwiek z nich, wystarczy wpisać je w formularzu internetowym. Takie edytowanie części wprowadzającej pozwala uniknąć skomplikowanej składni i daje pełną kontrolę nad zawartością, zapewniając jednocześnie jednolite formatowanie ostatecznego rezultatu.
i .
GitLab dla Jira i DVCS Connector już w Core.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dla użytkowników Jira w GitLab: i pozwalają na wyświetlanie informacji o commitach i merge requestach GitLab bezpośrednio w Jira. W połączeniu z naszą wbudowaną integracją z Jira, możesz łatwo poruszać się między tymi dwoma aplikacjami podczas pracy.
Funkcje te wcześniej były dostępne tylko w naszym planie Premium, a teraz są dostępne dla wszystkich użytkowników!
i .
Głosowanie większościowe dla transakcji klastra Gitaly (beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Klastr Gitaly pozwala na replikację repozytoriów Git na wiele «gorących» węzłów Gitaly. Zwiększa to niezawodność dzięki eliminacji pojedynczych punktów awarii. , wprowadzone w GitLab 13.3, powodują szeroką transmisję zmian na wszystkie węzły Gitaly w klastrze, ale tylko węzły Gitaly, które głosują na zgodność z węzłem głównym, zapisują zmiany na dysku. Jeśli wszystkie węzły replikujące nie osiągną zgody, tylko jedna kopia zmiany zostanie zapisana na dysku, tworząc pojedynczy punkt awarii do zakończenia asynchronicznej replikacji.
Głosowanie większościowe zwiększa niezawodność, wymagając zgody większości węzłów (a nie wszystkich) przed zapisaniem zmian na dysku. Jeśli ta funkcjonalność jest włączona, zapis musi zostać pomyślnie wykonany na kilku węzłach. Niezgadzające się węzły automatycznie synchronizują się za pomocą asynchronicznej replikacji z węzłami, które utworzyły kworum.
i .
Wsparcie dla niestandardowego schematu walidacji JSON w Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Projekty, w których ludzie piszą konfiguracje w formacie JSON lub YAML, często borykają się z problemami, ponieważ łatwo jest popełnić literówkę i coś zepsuć. Można napisać narzędzia do weryfikacji, które wychwycą te problemy w procesie CI, ale korzystanie z pliku schematu JSON może być pomocne do udostępnienia dokumentacji i wskazówek.
Uczestnicy projektu mogą określić w ich repozytorium ścieżkę do niestandardowego schematu w pliku .gitlab/.gitlab-webide.yml, który wskazuje schemat i ścieżkę do plików do weryfikacji. Podczas ładowania określonego pliku w Web IDE będzie widoczna dodatkowa informacja zwrotna i weryfikacja, które pomogą w utworzeniu pliku.
i .
Limit branżowania skierowanego acyklicznego grafu (DAG) został zwiększony do 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Jeśli używasz potoków (Directed Acyclic Graph (DAG)), mogłeś zauważyć, że limit 10 zadań, które zadanie może określić w needs:, zbyt surowo. W wersji 13.4 domyślny limit został zwiększony z 10 do 50, aby umożliwić bardziej skomplikowane sieci zależności między zadaniami w Twoich potokach.
Jeśli jesteś administratorem instancji GitLab, możesz podnieść ten limit jeszcze wyżej, konfigurując przełączaną funkcję, chociaż nie oferujemy oficjalnego wsparcia dla tego.
i .
Poprawione zachowanie needs dla pominiętych zadań
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
W niektórych przypadkach pominięte zadanie w potoku mogło być błędnie oceniane jako udane w odniesieniu do zależności wskazanych w needs, co powodowało uruchamianie kolejnych zadań, co nie powinno się zdarzać. To zachowanie zostało naprawione w wersji 13.4, a needs teraz poprawnie obsługuje przypadki pominiętych zadań.
i .
Zablokuj ostatni artefakt zadania, aby zapobiec jego usunięciu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab teraz automatycznie blokuje ostatni artefakt udanego zadania i potoku na każdej aktywnej gałęzi, prośbie o scalenie lub tagu, aby zapobiec jego usunięciu po upływie terminu. Staje się łatwiejsze stosowanie bardziej agresywnych zasad dotyczących terminu ważności dla usuwania starych artefaktów. To pomaga zmniejszyć zużycie przestrzeni dyskowej i zapewnia, że zawsze będziesz mieć kopię ostatniego artefaktu z potoku.
i .
Przewodnik CI/CD dotyczący optymalizacji potoku
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Optymalizacja działania potoku CI/CD może zwiększyć prędkość dostarczania i zaoszczędzić pieniądze. Poprawiliśmy naszą dokumentację, dodając krótkie wytyczne dotyczące uzyskania maksymalnych korzyści z optymalizacji Twoich potoków.
i .
Raport z testów posortowany według statusu testu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— to prosty sposób, aby zobaczyć wyniki wszystkich testów w pipeline. Jednak przy dużej liczbie testów, zlokalizowanie nieudanych testów może zająć dużo czasu. Inne problemy, które mogą utrudniać korzystanie z raportu, to trudności z przewijaniem długiej wyjściowej zawartości śledzenia oraz zaokrąglanie czasu do zera dla testów trwających mniej niż 1 sekundę. Domyślnie raport z testowania teraz przy sortowaniu najpierw umieszcza nieudane testy na początku raportu, a następnie sortuje testy według czasu trwania. Ułatwia to znalezienie awarii oraz długotrwałych testów. Ponadto czas trwania testów jest teraz wyświetlany w milisekundach lub sekundach, co znacznie przyspiesza ich odczyt, a także rozwiązano wcześniejsze problemy z przewijaniem.
i .
Ograniczenia dotyczące rozmiaru plików przesyłanych do rejestru pakietów
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Teraz obowiązują ograniczenia dotyczące rozmiaru plików pakietów, które można przesyłać do rejestru pakietów GitLab. Ograniczenia te zostały wprowadzone w celu optymalizacji wydajności rejestru pakietów i zapobiegania nadużyciom. Ograniczenia zależą od formatu pakietu. Dla GitLab.com maksymalne rozmiary plików to:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Dla instancji GitLab użytkowników wartości domyślne są takie same. Administrator może jednak zaktualizować ograniczenia za pomocą .
i .
Użyj CI_JOB_TOKEN do publikowania pakietów PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Możesz użyć rejestru GitLab PyPI do stworzenia, publikacji i udostępnienia pakietów Pythona wraz z kodem źródłowym i pipeline'ami CI/CD. Jednak wcześniej nie mogłeś autoryzować się w rejestrze za pomocą wstępnie zdefiniowanej zmiennej środowiskowej CI_JOB_TOKEN. W wyniku tego musiałeś korzystać ze swoich osobistych danych uwierzytelniających do aktualizacji rejestru PyPI lub mogłeś zdecydować się w ogóle nie używać rejestru.
Teraz łatwiej jest korzystać z GitLab CI/CD do publikowania i instalowania pakietów PyPI za pomocą wstępnie zdefiniowanej zmiennej środowiskowej CI_JOB_TOKEN.
i .
Profile skanera DAST na żądanie
(ULTIMATE, GOLD)
Skanowanie DAST na żądanie, które zostało , dodano profile skanera DAST. Rozszerzają one możliwości konfiguracji skanowania, umożliwiając szybkie tworzenie wielu profili dla różnych typów skanowania. W wersji 13.4 profil skanera początkowo zawiera parametr limitu czasowego dla robota, który ustala, jak długo robot DAST powinien działać podczas próby wykrycia wszystkich stron skanowanego serwisu. Profil zawiera również parametr limitu czasowego dla docelowej witryny, który ustala, jak długo skaner powinien czekać na dostępność strony, zanim przerwie skanowanie, jeśli strona nie odpowiada kodem stanu 200 lub 300. W miarę jak w następnych wydaniach będziemy dalej ulepszać tę funkcję, profil skanera zostanie wzbogacony o dodatkowe opcje konfiguracji.
i .
Prosty plik konfiguracyjny przekierowań dla GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Jeśli korzystasz z GitLab Pages i chcesz lepiej zarządzać zmianami adresów URL, mogłeś zauważyć, że zarządzanie przekierowaniami na stronie GitLab Pages było niemożliwe. GitLab teraz umożliwia skonfigurowanie zasad przekierowywania jednego adresu URL na inny dla twojej strony Pages, dodając plik konfiguracyjny do repozytorium. Ta funkcja stała się możliwa dzięki wkładowi Kevina Barnetta (), naszego Erica Eastwooda () oraz zespołu GitLab. Dziękujemy wszystkim za wasz wkład.
i .
Stan Terraform zarządzany przez GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dostęp do wcześniejszych wersji stanu Terraform jest niezbędny zarówno w celach zgodności, jak i debuggowania w razie potrzeby. Obsługa zarządzania wersjami stanu Terraform zarządzanego przez GitLab jest dostępna od wersji GitLab 13.4. Zarządzanie wersjami jest automatycznie włączane dla nowych plików stanu Terraform. Istniejące pliki stanu Terraform będą w późniejszych wydaniach.
i .
Ważne szczegóły dotyczące powiadomień o incydentach
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Podczas przetwarzania incydentów musisz łatwo określić, jak długo ostrzeżenie było otwarte i ile razy wystąpiło zdarzenie. Te szczegóły często mają kluczowe znaczenie przy ocenie wpływu na klienta oraz tego, czym Twoja drużyna powinna zająć się w pierwszej kolejności. Na nowej panelu szczegółów incydentów wyświetlamy czas rozpoczęcia powiadomienia, liczbę zdarzeń oraz link do oryginalnego powiadomienia. Informacje te są dostępne w incydentach, które powstają na podstawie powiadomień.
i .
Ustawianie i edytowanie parametru powagi incydentu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Parametr 'powaga incydentu' pozwala specjalistom ds. reagowania i interesariuszom określać skutki przestojów oraz metody i pilność reakcji. W miarę jak Twoja drużyna dzieli się wynikami podczas usuwania incydentu i przywracania funkcjonalności, może zmieniać ten parametr. Teraz możesz edytować powagę incydentu w prawym panelu bocznym na stronie 'Szczegóły incydentu', a stopień powagi jest wyświetlany na liście incydentów.
i .
Tworzenie, edytowanie i usuwanie zasad bezpieczeństwa sieciowego kontenerów
(ULTIMATE, GOLD)
To ulepszenie edytora zasad bezpieczeństwa sieciowego kontenerów umożliwia użytkownikom łatwe tworzenie, edytowanie i usuwanie swoich zasad bezpośrednio z interfejsu użytkownika GitLab. Możliwości edytora obejmują tryb .yaml dla zaawansowanych użytkowników oraz edytor zasad z intuicyjnym interfejsem dla tych, którzy nie są zaznajomieni z zasadami sieciowymi. Nowe możliwości zarządzania zasadami możesz znaleźć w sekcji Bezpieczeństwo i zgodność > Zarządzanie zagrożeniami > Zasady (Bezpieczeństwo i zgodność > Zarządzanie zagrożeniami > Polityki).
i .
Wsparcie dla magazynu obiektów blob Azure
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Zarówno GitLab, jak i GitLab Runner teraz wspierają , co ułatwia uruchamianie usług GitLab w Azure.
Instancje GitLab wspierają Azure dla wszystkich typów magazynów obiektów, w tym pliki LFS, artefakty CI oraz . Aby skonfigurować magazyn obiektów blob Azure, postępuj zgodnie z instrukcjami instalacji lub .
Ob handlers GitLab również obsługują Azure dla przechowywania . Magazyn Azure można skonfigurować w sekcji .
i .
Pakiety Omnibus ARM64 dla Ubuntu i OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
W odpowiedzi na rosnące zapotrzebowanie na wsparcie uruchamiania GitLab dla 64-bitowej architektury ARM, z przyjemnością ogłaszamy dostępność oficjalnego pakietu ARM64 Ubuntu 20.04 Omnibus. Wielkie podziękowania dla Zitai Chen i Guillaume Gardet za ich ogromny wkład — ich prośby o scalanie odegrały kluczową rolę w tym projekcie!
Aby pobrać i zainstalować pakiet dla Ubuntu 20.04, przejdź do naszej i wybierz Ubuntu.
i .
Wsparcie dla uwierzytelniania za pomocą kart inteligentnych dla wykresu Helm GitLab
(PREMIUM, ULTIMATE)
Karty inteligentne, takie jak karty dostępu (CAC), mogą teraz być używane do uwierzytelniania w instancji GitLab wdrożonej za pomocą wykresu Helm. Karty inteligentne są uwierzytelniane w lokalnej bazie danych za pomocą certyfikatów X.509. Dzięki temu wsparcie dla kart inteligentnych w wykresie Helm jest teraz zgodne z wsparciem dla kart inteligentnych dostępnym w wdrożeniach Omnibus.
i .
Szczegółowe notatki wydania i instrukcje aktualizacji/pobierania można znaleźć w oryginalnym anglojęzycznym poście: .
W tłumaczeniu z angielskiego uczestniczyli , , i .
Źródło: habr.com
