• typy biegaczy
  • Współdzieleni biegacze
    • Jak współdzieleni biegacze wybierają zadania
    • Włącz współdzielonych biegaczy
    • Wyłącz współdzielonych biegaczy
  • Utwórz biegacza grupowego
  • Wyświetlanie i zarządzanie biegaczami grupowymi
  • pauza lub Usuń grupę biegaczy
• określonych biegaczy
  • Utwórz określonego biegacza
  • włącz określonego biegacza dla określonego projektu
  • Zapobiegaj włączaniu określonego biegacza dla innych projektów

w GitLab CI/CD biegacze uruchamiają kod zdefiniowany w.gitlab-ci.yml.Runner jest lekkim, wysoce skalowalnym agentem, który odbiera zadanie CI za pośrednictwem API koordynatora GitLab Ci / CD, uruchamia zadanie i wysyła wynik z powrotem do instancji GitLab.

biegacze są tworzone przez administratora i są widoczne w interfejsie GitLab.Biegacze mogą być specyficzne dla niektórych projektów lub dostępne dla wszystkich projektów.

ta dokumentacja skupia się na używaniu runnerów w GitLab.Jeśli chcesz zainstalować i skonfigurować GitLab Runner, zapoznaj się z dokumentacją GitLab Runner.

typy biegaczy

w interfejsie GitLab istnieją trzy typy biegaczy, w zależności od tego, do kogo chcesz mieć dostęp:

• współdzielone biegacze są dostępne dla wszystkich grup i projektów w instancji GitLab.
• biegacze grupowi są dostępni dla wszystkich projektów i podgrup w grupie.
• konkretni biegacze są powiązani z konkretnymi projektami.Zazwyczaj konkretne biegacze są używane do jednego projektu na raz.

współdzielone biegacze

współdzielone biegacze są dostępne dla każdego projektu w instancji GitLab.

użyj współdzielonych biegaczy, gdy masz wiele zadań o podobnych wymaganiach. Zamiast mieć wielu biegaczy na biegu jałowym dla wielu projektów, możesz mieć kilku biegaczy, którzy obsługują wiele projektów.

Jeśli używasz samodzielnie zarządzanej instancji GitLab:

• Twój administrator może zainstalować i zarejestrować udostępnione biegacze, przechodząc do ustawień Twojego projektu> CI / CD,rozwijając sekcję biegacze i klikając Pokaż instrukcje instalacji biegacza.Instrukcje te są również dostępne w dokumentacji.
• administrator może również skonfigurować maksymalną liczbę współdzielonych minut rurociągu dla każdej grupy.

Jeśli używasz GitLab.com:

• możesz wybrać z listy współdzielonych biegaczy, które utrzymuje GitLab.
• współdzieleni biegacze zużywają minuty dołączone do Twojego konta.

jak współdzieleni biegacze wybierają zadania

Współdzieleni biegacze przetwarzają zadania przy użyciu kolejki fair usage. Ta Kolejka zapobiega tworzeniu setek zadań i wykorzystywaniu wszystkich dostępnych zasobów runnera.

algorytm kolejki fair usage przypisuje zadania na podstawie projektów, które mają największą liczbę zadań już uruchomionych na współdzielonych biegaczach.

przykład 1

Jeśli te zadania znajdują się w kolejce:

• Zadanie 1 dla projektu 1
• Zadanie 2 dla projektu 1
• Zadanie 3 dla projektu 1
• Zadanie 4 dla projektu 2
• zadanie 5 dla projektu 2
• Zadanie 6 dla projektu 3

algorytm sprawiedliwego użytkowania przypisuje zadania w tej kolejności:

1. Zadanie 1 jest wybierane jako pierwsze, ponieważ ma najniższy numer zadania z projektów bez uruchomionych zadań (czyli wszystkich projektów).
2. zadanie 4 jest następne, ponieważ 4 jest teraz najniższym numerem zadania z projektów bez uruchomionych zadań (Projekt 1 ma uruchomione zadanie).
3. Zadanie 6 jest następne, ponieważ 6 jest teraz najniższym numerem zadania z projektów bez uruchomionych zadań (projekty 1 i 2 mają uruchomione zadania).
4. Zadanie 2 jest następne, ponieważ z projektów o najniższej liczbie uruchomionych zadań (każdy ma 1), jest to najniższy numer zadania.
5. zadanie 5 jest następne, ponieważ projekt 1 ma teraz uruchomione 2 zadania, a zadanie 5 jest najniższym pozostałym numerem zadania między projektami 2 i 3.
6. wreszcie jest praca 3 … bo to jedyna praca jaka została.

przykład 2

Jeśli te zadania znajdują się w kolejce:

• Zadanie 1 dla projektu 1
• Zadanie 2 dla projektu 1
• Zadanie 3 dla projektu 1
• Zadanie 4 dla projektu 2
• zadanie 5 dla projektu 2
• Zadanie 6 dla projektu 3

algorytm fair usage przypisuje zadania w następującej kolejności:

1. Zadanie 1 jest wybierane jako pierwsze, ponieważ ma najniższy numer zadania z projektów bez uruchomionych zadań (czyli wszystkich projektów).
2. kończymy Zadanie 1.
3. Zadanie 2 jest następne, ponieważ po zakończeniu zadania 1 wszystkie projekty mają 0 zadań uruchomionych ponownie, a 2 jest najniższym dostępnym numerem zadania.
4. zadanie 4 jest następne, ponieważ przy uruchomieniu zadania w projekcie 1, 4 jest najniższą liczbą z projektów bez Zadań (projekty 2 i 3).
5. kończymy Zadanie 4.
6. zadanie 5 jest następne, ponieważ po zakończeniu zadania 4, Projekt 2 nie ma ponownie uruchomionych zadań.
7. Zadanie 6 jest następne, ponieważ projekt 3 jest jedynym projektem, który nie ma uruchomionych zadań.
8. na koniec wybieramy Zadanie 3 … bo znowu jest to jedyne zadanie jakie zostało.

Włącz współdzielonych biegaczy

On GitLab.com, współdzielone biegacze są włączone we wszystkich projektach przezefault.

w instancjach samodzielnie zarządzanych GitLab, administrator musi je zainstalować i zarejestrować.

Możesz również włączyć współdzielonych biegaczy dla poszczególnych projektów.

aby włączyć współdzielone biegacze:

1. przejdź do ustawień projektu> CI / CD i rozwiń sekcję biegacze.
2. wybierz Włącz współdzielone biegacze dla tego projektu.

Wyłącz współdzielone biegacze

możesz wyłączyć współdzielone biegacze dla poszczególnych projektów lub dla grup.Musisz mieć uprawnienia właściciela dla projektu lub grupy.

aby wyłączyć współdzielone biegacze dla projektu:

1. przejdź do ustawień projektu> CI / CD i rozwiń sekcję biegacze.
2. w obszarze współdzielone biegacze wybierz opcję Włącz współdzielone biegacze dla tego projektu, aby przełącznik był wyszarzony.

współdzielone biegacze są automatycznie wyłączone dla projektu:

• Jeśli ustawienie współdzielone biegacze dla grupy nadrzędnej jest wyłączone, oraz
• Jeśli nadpisanie tego ustawienia nie jest dozwolone na poziomie projektu.

aby wyłączyć współdzielone biegacze dla grupy:

1. przejdź do ustawień grupy> CI / CD i rozwiń sekcję biegacze.
2. w obszarze współdzielone biegacze wyłącz przełącznik Włącz współdzielone biegacze dla tej grupy.
3. Opcjonalnie,aby umożliwić współdzielenie biegaczy dla poszczególnych projektów lub podgrup, kliknij Zezwól na projekty i podgrupy, aby zastąpić ustawienie grupy.

biegacze grupowi

użyj biegaczy grupowych, gdy chcesz, aby wszystkie projekty w grupie miały dostęp do zestawu biegaczy.

biegacze grupowi przetwarzają zadania za pomocą kolejki first in, first out (FIFO).

Utwórz grupę runner

możesz utworzyć grupę runner Dla samodzielnie zarządzanej instancji GitLab lub dla GitLab. com. musisz mieć uprawnienia właściciela dla grupy.

aby utworzyć grupę runner:

1. zainstaluj GitLab Runner.
2. przejdź do grupy, dla której chcesz sprawić, by biegacz pracował.
3. przejdź do ustawień > CI / CD i rozwiń sekcję Runners.
4. zwróć uwagę na URL i token.
5. Zarejestruj biegacza.

Wyświetlanie i zarządzanie biegaczami grup

Możesz przeglądać i zarządzać wszystkimi biegaczami dla grupy, jej podgrup i projektów.Możesz to zrobić dla własnej instancji GitLab lub dla GitLab. com. musisz mieć uprawnienia właściciela dla grupy.

1. przejdź do grupy, w której chcesz zobaczyć biegaczy.
2. przejdź do ustawień > CI / CD i rozwiń sekcję Runners.

3. wyświetlane są następujące pola.

   atrybut	opis
   Typ	jeden lub więcej z następujących stanów:
   Token biegacza	Token używany do identyfikacji biegacza i używany do komunikacji z instancją GitLab
   opis	opis podany biegaczowi podczas jego tworzenia
   Wersja	GitLab Runner wersja
   adres IP	adres IP hosta, na którym zarejestrowany jest biegacz
   projekty	liczba projektów, do których biegacz jest przypisany
   zadania	suma zadań prowadzonych przez biegacza
   Tagi	Tagi powiązane z runnerem
   ostatni kontakt	znacznik czasu wskazujący, kiedy instancja GitLab ostatni kontaktowała się z runnerem

na tej stronie możesz edytować, wstrzymywać i usuwać biegaczy z grupy, jej podgrup i projektów.

Wstrzymaj lub Usuń grupę runner

możesz wstrzymać lub usunąć grupę runner Dla samodzielnie zarządzanej instancji GitLab lub dla GitLab. com. musisz mieć uprawnienia właściciela dla grupy.

1. przejdź do grupy, dla której chcesz usunąć lub wstrzymać biegacza.
2. przejdź do ustawień > CI / CD i rozwiń sekcję Runners.
3. kliknij Wstrzymaj lub Usuń biegacza.
   • Jeśli zatrzymasz biegacza grupowego używanego przez wiele projektów, biegacz zatrzyma się dla wszystkich projektów.
   • z widoku grupy nie można usunąć biegacza przypisanego do więcej niż jednego projektu.Musisz najpierw usunąć go z każdego projektu.
4. w oknie potwierdzenia kliknij OK.

konkretni biegacze

używaj konkretnych biegaczy, gdy chcesz używać biegaczy do konkretnych projektów. Na przykład, gdy masz:

• zadania o określonych wymaganiach, takie jak zadanie wdrażania wymagające poświadczeń.
• projekty z dużą aktywnością CI, które mogą korzystać z bycia oddzielonym od innych biegaczy.

możesz ustawić konkretny biegacz, który będzie używany w wielu projektach. Konkretne uruchamianie musi być jawnie włączone dla każdego projektu.

konkretni biegacze przetwarzają zadania za pomocą kolejki first in, first out (FIFO).

Utwórz konkretny biegacz

możesz utworzyć konkretny biegacz dla samodzielnie zarządzanej instancji GitLab lub dla GitLab. com. musisz mieć uprawnienia właściciela dla projektu.

aby utworzyć konkretny biegacz:

1. zainstaluj biegacza.
2. przejdź do ustawień projektu> CI / CD i rozwiń sekcję Runners.
3. zwróć uwagę na URL i token.
4. Zarejestruj biegacza.

Włącz konkretny biegacz dla konkretnego projektu

konkretny biegacz jest dostępny w projekcie, dla którego został stworzony. Administrator może zastosować konkretny biegacz do dodatkowych projektów.

• musisz mieć uprawnienia właściciela projektu.
• konkretny biegacz nie może być zablokowany.

aby włączyć lub wyłączyć konkretny biegacz dla projektu:

1. przejdź do ustawień projektu> CI / CD i rozwiń sekcję biegacze.
2. Kliknij Włącz dla tego projektu lub wyłącz dla tego projektu.

zapobieganie włączaniu określonego biegacza dla innych projektów

możesz skonfigurować określony biegacz tak, aby był „zablokowany” i nie mógł być włączony dla innych projektów.To ustawienie można włączyć podczas pierwszej rejestracji biegacza,ale można je również zmienić później.

aby zablokować lub odblokować biegacza:

1. przejdź do ustawień projektu> CI / CD i rozwiń sekcję biegaczy.
2. Znajdź biegacza, którego chcesz zablokować lub odblokować. Upewnij się, że jest włączona.
3. kliknij przycisk ołówek.
4. zaznacz opcję Zablokuj bieżące projekty.
5. kliknij Zapisz zmiany.

ręcznie Wyczyść pamięć podręczną runnera

przeczytaj czyszczenie pamięci podręcznej.

ustaw maksymalny Limit czasu pracy dla biegacza

dla każdego biegacza możesz określić maksymalny Limit czasu pracy. Ten limit czasu, jeśli jest mniejszy niż limit czasu zdefiniowany przez projekt, ma pierwszeństwo.

Ta funkcja może być użyta, aby zapobiec przytłaczaniu współdzielonego programu przez projekt, który ma zadania z długim czasem oczekiwania (na przykład jeden tydzień).

gdy nie jest skonfigurowany, biegacze nie nadpisują limitu czasu projektu.

na GitLab.com, nie możesz nadpisać limitu czasu zadania dla współdzielonych biegaczy i musisz użyć limitu czasu zdefiniowanego przez projekt.

aby ustawić maksymalny Limit Czasu Pracy:

1. w projekcie przejdź do ustawień> CI/CD>.
2. Wybierz swojego biegacza, aby edytować ustawienia.
3. Wprowadź wartość pod Maximum job timeout.
4. Wybierz Zapisz zmiany.

jak działa ta funkcja:

przykład 1 – limit czasu dla biegacza większy niż limit czasu projektu

1. Ustawiasz maksymalny Limit czasu dla biegacza na 24 godziny
2. Ustawiasz limit czasu CI/CD dla projektu na 2 godziny
3. uruchamiasz zadanie
4. zadanie, jeśli działa dłużej, wygasa po 2 godzinach

przykład 2 – limit czasu dla biegacza nie jest skonfigurowany

1. usuwasz maksimum konfiguracja limitu czasu pracy z runnera
2. ustawiasz limit czasu CI/CD dla projektu na 2 godziny
3. uruchamiasz zadanie
4. zadanie, jeśli działa dłużej, wygasa po 2 godzinach

przykład 3 – Runner

1. ustawiasz maksymalny Limit czasu zadania dla biegacza na 30 minut
2. Ustawiasz limit czasu CI/CD dla projektu na 2 godziny
3. rozpoczynasz zadanie
4. zadanie, jeśli działa dłużej, wygasa po 30 minutach

uważaj na poufne informacje

z niektórymi wykonawcami biegacza,jeśli możesz uruchomić zadanie na biegaczu, możesz uzyskaj pełny dostęp do systemu plików,a tym samym dowolnego kodu, który uruchamia, a także tokena biegacza. W przypadku współdzielonych biegaczy oznacza to, że każdy, kto wykonuje zadania na biegaczu, może uzyskać dostęp do kodu każdego innego, który działa na biegaczu.

Ponadto, ponieważ możesz uzyskać dostęp do tokena biegacza, możliwe jest na przykład utworzenie klonu biegacza i przesłanie fałszywych zadań.

powyższego można łatwo uniknąć, ograniczając użycie współdzielonych uruchomień w dużych publicznych instancjach GitLab,kontrolując dostęp do instancji GitLab i używając bardziej bezpiecznych wykonawców runnera.

Zapobiegaj ujawnianiu poufnych informacji

możesz chronić biegaczy, aby nie ujawniali poufnych informacji.Gdy biegacz jest chroniony, wybiera zadania utworzone tylko w zabezpieczonych gałęziach lub chronionych tagach i ignoruje inne zadania.

aby chronić lub odblokować biegacza:

1. przejdź do ustawień projektu> CI / CD i rozwiń sekcję biegaczy.
2. Znajdź biegacza, którego chcesz chronić lub usunąć. Upewnij się, że jest włączona.
3. kliknij przycisk ołówek.
4. zaznacz opcję chronioną.
5. kliknij Zapisz zmiany.

widełki

za każdym razem, gdy projekt jest rozwidlony, kopiuje ustawienia zadań, które go dotyczą. Oznacza to, że jeśli masz współdzielonych biegaczy skonfigurowanych do projektu i kilka widelców tego projektu, współdzieleni biegacze służą zadaniom tego projektu.

wektory ataku u biegaczy

wspomniano krótko wcześniej, ale można wykorzystać następujące rzeczy biegaczy.Zawsze szukamy wkładu, który może złagodzić te względy bezpieczeństwa.

Zresetuj token rejestracyjny dla projektu

Jeśli uważasz, że token rejestracyjny dla projektu został ujawniony, powinieneś go ustawić. Token może być użyty do zarejestrowania innego uczestnika projektu. Ten nowy runnermay może być użyty do uzyskania wartości zmiennych tajnych lub do klonowania kodu projektu.

aby zresetować token:

1. przejdź do ustawień projektu > CI / CD.
2. rozwiń sekcję Ogólne ustawienia potoków.
3. znajdź pole formularza Tokena biegacza i kliknij przycisk Pokaż wartość.
4. Usuń wartość i zapisz formularz.
5. po odświeżeniu strony rozwiń sekcję Ustawienia biegaczy i sprawdź token rejestracji-powinien zostać zmieniony.

od teraz stary token nie jest już ważny i nie rejestruje nowych uczestników projektu. Jeśli używasz narzędzi do dostarczania i rejestrowania nowych biegaczy, tokeny używane w tych narzędziach powinny zostać zaktualizowane, aby odzwierciedlić wartość nowego tokena.

Określ adres IP biegacza

przydatne może być poznanie adresu IP biegacza, aby móc rozwiązywać problemy z tym biegaczem. GitLab przechowuje i wyświetla adres IP, przeglądając źródło żądań HTTP, które wysyła do GitLab podczas wyszukiwania zadań. Adres IP jest zawsze aktualizowany, więc jeśli IP runnera zmieni się automatycznie aktualizuje się w GitLab.

adres IP współdzielonych biegaczy i konkretnych biegaczy można znaleźć w innych miejscach.

Określ adres IP współdzielonego biegacza

aby wyświetlić adres IP współdzielonego biegacza, musisz mieć dostęp administratora do instancji GitLab. Aby to ustalić:

1. odwiedź Stronę administratora> przegląd>
2. poszukaj biegacza w tabeli i powinieneś zobaczyć kolumnę adresu IP.

Określ adres IP konkretnego biegacza

aby znaleźć adres IP biegacza dla określonego projektu,musisz mieć uprawnienia właściciela dla projektu.

1. przejdź do ustawień projektu > CI / CD i rozwiń sekcję Runners.
2. na stronie szczegółów powinieneś zobaczyć wiersz adresu IP.

użyj tagów, aby ograniczyć liczbę zadań używając biegacza

musisz skonfigurować biegacza, aby mógł uruchamiać wszystkie rodzaje zadań, które może napotkać w projektach, nad którymi jest współdzielony. Byłoby to problematyczne dla dużych ilości projektów, gdyby nie znaczniki.

Tagi Ci GitLab to nie to samo co tagi Git. Tagi ci GitLab są powiązane z runners.Tagi Git są powiązane z commitami.

oznaczając biegacza dla rodzajów zadań, które może obsłużyć, możesz sprawić, że biegacze będą wykonywać tylko te zadania, do których są przygotowani.

na przykład na GitLab mamy biegaczy oznaczonych tagami rails, jeśli zawierają odpowiednie zależności do uruchamiania pakietów testowych Rails.

Kiedy rejestrujesz biegacza, jego domyślnym zachowaniem jest tylko wybieranie jobs.To zmień to, musisz mieć uprawnienia właściciela dla projektu.

aby biegacz wybierał nieoznakowane zadania:

1. przejdź do ustawień projektu > CI / CD i rozwiń sekcję Runners.
2. Znajdź biegacza, którego chcesz wybrać i upewnij się, że jest włączony.
3. kliknij przycisk ołówek.
4. zaznacz opcję Uruchom nieoznakowane zadania.
5. kliknij przycisk Zapisz zmiany, aby zmiany odniosły skutek.

poniżej kilka przykładowych scenariuszy różnych odmian.

biegacz uruchamia tylko oznaczone zadania

poniższe przykłady ilustrują potencjalny wpływ biegacza na uruchamianie tylko oznakowanych zadań.

przykład 1:

1. biegacz jest skonfigurowany do uruchamiania tylko oznaczonych zadań i ma znacznik docker.
2. zadanie, które mahello jest wykonywane i blokowane.

przykład 2:

1. biegacz jest skonfigurowany do uruchamiania tylko oznaczonych zadań i ma znacznikdocker.
2. zadanie, które madocker jest wykonywane i uruchamiane.

przykład 3:

1. biegacz jest skonfigurowany do uruchamiania tylko oznaczonych zadań i madocker tag.
2. zadanie, które nie ma zdefiniowanych tagów jest wykonywane i blokowane.

biegacz może uruchamiać zadania nieoznakowane

poniższe przykłady ilustrują potencjalny wpływ biegacza na uruchamianie zadań oznaczonych i nieoznakowanych.

przykład 1:

1. biegacz jest skonfigurowany do uruchamiania zadań nieoznaczonych i posiada znacznik docker.
2. zadanie, które nie ma zdefiniowanych tagów jest wykonywane i uruchamiane.
3. wykonuje się i uruchamia drugie zadanie, które ma zdefiniowany znacznikdocker.

przykład 2:

1. biegacz jest skonfigurowany do uruchamiania zadań nieoznaczonych i nie ma zdefiniowanych tagów.
2. zadanie, które nie ma zdefiniowanych tagów jest wykonywane i uruchamiane.
3. drugie zadanie, które ma zdefiniowany znacznikdocker jest zablokowane.

Konfiguracja zachowania runnera za pomocą zmiennych

możesz użyć zmiennych CI/CD do skonfigurowania behawiorglobalnie runnera Git lub dla poszczególnych zadań:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (płytkie klonowanie)
• GIT_CLONE_PATH (niestandardowe katalogi kompilacji)

Możesz również użyć zmiennych, aby skonfigurować, ile razy runnerat usuwa niektóre etapy zadania egzekucja.

strategia Gita

Możesz ustawićGIT_STRATEGY używany do pobierania zawartości repozytorium, eitherglobally lub per-job w sekcjivariables:

variables: GIT_STRATEGY: clone

git submodule sync --recursivegit submodule update --init --recursive

aby ta funkcja działała poprawnie, podmoduły muszą być skonfigurowane(w.gitmodules) za pomocą:

• adres URL http publicznie dostępnego repozytorium lub
• ścieżka względna do innego repozytorium na tym samym serwerze GitLab. Zobacz dokumentację podmodułów git.

Git checkout

zmiennaGIT_CHECKOUT może być używana, gdyGIT_STRATEGY jest ustawiona naclone lubfetch, aby określić, czygit checkout należy uruchomić. Jeśli nie jest określony, domyślnie ma wartość true. Możesz ustawić je globalnie lub dla każdego zadania w sekcjivariables.

jeśli jest ustawione na false, runner:

• podczas robieniafetch – aktualizuje repozytorium i pozostawia kopię roboczą aktualnej wersji,
• podczas robienia clone – klonuje repozytorium i pozostawia kopię roboczą w gałęzi default.

JeśliGIT_CHECKOUT jest ustawione natrue, obaclone Ifetch działają w ten sam sposób.Runner sprawdza kopię roboczą rewizji związanej z rurociągiem CI:

variables: GIT_STRATEGY: clone GIT_CHECKOUT: "false"script: - git checkout -B master origin/master - git merge $CI_COMMIT_SHA

Git clean flags

zmienna GIT_CLEAN_FLAGS służy do kontrolowania domyślnego zachowaniagit clean po sprawdzeniu źródeł. Możesz ustawić go globalnie lub dla każdego zadania w sekcjivariables.

GIT_CLEAN_FLAGS akceptuje wszystkie możliwe opcje poleceniagit clean.

git clean jest wyłączony, jeśli podanoGIT_CHECKOUT: "false".

Jeśli GIT_CLEAN_FLAGS jest:

• nie określono, git cleanflagi domyślnie -ffdx.
• podana wartośćnonegit clean nie jest wykonywana.

na przykład:

variables: GIT_CLEAN_FLAGS: -ffdx -e cache/script: - ls -al cache/

Git pobiera dodatkowe flagi

zmiennaGIT_FETCH_EXTRA_FLAGS służy do kontrolowania zachowaniagit fetch. Możesz ustawić go globalnie lub dla każdego zadania w sekcjivariables.

GIT_FETCH_EXTRA_FLAGS akceptuje wszystkie opcje poleceniagit fetch. Jednak flagiGIT_FETCH_EXTRA_FLAGS są dodawane po domyślnych flagach, których nie można modyfikować.

domyślnymi flagami są:

• GIT_DEPTH.
• lista referencji.
• Pilot o nazwie origin.

JeśliGIT_FETCH_EXTRA_FLAGS jest:

• nie podano,git fetch flagi domyślne do--prune --quiet wraz z domyślnymi flagami.
• Po podaniu wartościnonegit fetch jest wykonywane tylko z domyślnymi flagami.

na przykład domyślne flagi to --prune --quiet, więc możesz sprawić, że git fetch będzie bardziej gadatliwy, nadpisując to po prostu --prune:

variables: GIT_FETCH_EXTRA_FLAGS: --prunescript: - ls -al cache/

git fetch origin $REFSPECS --depth 50 --prune

variables: GIT_DEPTH: "3"

variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/project-nametest: script: - pwd

variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-nametest: script: - pwd

variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATHtest: script: - pwd

ścieżki zagnieżdżone

wartość GIT_CLONE_PATH zostanie rozwinięta raz i zagnieżdżanie variableswithin nie jest obsługiwane.

na przykład zdefiniujesz obie zmienne poniżej w pliku.gitlab-ci.yml :

variables: GOPATH: $CI_BUILDS_DIR/go GIT_CLONE_PATH: $GOPATH/src/namespace/project

wartośćGIT_CLONE_PATH zostanie rozwinięta raz do$CI_BUILDS_DIR/go/src/namespace/project I spowoduje błąd, ponieważ$CI_BUILDS_DIR nie jest rozwijany.

job stages próby

Możesz ustawić liczbę prób, które uruchomione zadanie próbuje wykonać następujące etapy:

domyślnie jest to jedna próba.

przykład:

variables: GET_SOURCES_ATTEMPTS: 3

możesz ustawić je globalnie lub dla zadania w sekcji variables.

wywołania systemowe niedostępne na GitLab.com wspólne bieganie

GitLab.com współdzieleni biegacze biegają na CoreOS. Oznacza to, że nie można używać niektórych wywołań systemowych, takich jak getlogin, z biblioteki standardowej C.

Ustawienia artefaktu i pamięci podręcznej

Ustawienia artefaktu i pamięci podręcznej kontrolują stopień kompresji artefaktów i pamięci podręcznej.Użyj tych ustawień, aby określić rozmiar archiwum tworzonego przez zadanie.

• w wolnej sieci ładowanie może być szybsze dla mniejszych archiwów.
• w szybkiej sieci, w której przepustowość i pamięć masowa nie są problemem, przesyłanie może być szybsze przy użyciu najszybszego współczynnika kompresji, mimo że produkowane archiwum jest większe.

aby strony GitLab obsługiwały żądania zakresu http, artefakty powinny używać ustawieniaARTIFACT_COMPRESSION_LEVEL: fastest, ponieważ tylko nieskompresowane archiwa zip wspierają tę funkcję.

miernik może być również włączony, aby zapewnić szybkość transferu dla wysyłania i pobierania.

variables: # output upload and download progress every 2 seconds TRANSFER_METER_FREQUENCY: "2s" # Use fast compression for artifacts, resulting in larger archives ARTIFACT_COMPRESSION_LEVEL: "fast" # Use no compression for caches CACHE_COMPRESSION_LEVEL: "fastest"