• Typy běžců
  • Sdílené běžci
    • Jak sdílené běžci vybrat pracovních míst
    • Povolit sdílené běžci
    • Zakázat sdílené běžci
  • Skupina běžců
    • Vytvořit skupinu runner
    • Zobrazit a spravovat skupiny běžců
    • Pozastavit nebo odstranit skupinu runner
  • Specifické běžci
    • Vytvořit konkrétní runner
    • Povolit konkrétní runner pro konkrétní projekt
    • Zabránit konkrétní runner od být povoleno pro další projekty
• Ručně vymazat runner cache
• Nastavit maximální časový limit pro práci běžec
• Buďte opatrní s citlivými informacemi
  • Zabránit běžci z odhalení citlivých informací
  • Vidlice
  • vektorů Útoku v běžci
  • Obnovit runner registrační token pro projekt
• Zjistit IP adresu runner
  • Zjistit IP adresu sdíleného runner
  • Zjistit IP adresu konkrétního běžce
• Použít značky k omezení počtu pracovních míst pomocí runner
  • běžec běží pouze označených míst
  • runner je povoleno spuštění neoznačených míst
• Konfigurace runner chování s proměnnými
  • Git strategie
  • Git submodul strategie
  • Git checkout
  • Git čisté vlajky
  • Git fetch další vlajky
  • Mělké klonování
  • Vlastní sestavení adresáře
    • Zpracování souběžnost
    • Vnořené cesty
  • Práce fázích pokusů
• systémová volání nejsou k dispozici na GitLab.com sdílené běžci
• Artefakt a nastavení mezipaměti

V GitLab CI/CD, běžci spustit kód definovaný v .gitlab-ci.yml.Běžec je lehký, vysoce škálovatelné agent, který zvedne CI práci prostřednictvím koordinátora API GitLab CI/CD, běží do práce, a výsledek pošle zpět do GitLab stupně.

běžce jsou vytvořeny správcem a jsou viditelné v uživatelském rozhraní GitLab.Běžci mohou být specifičtí pro určité projekty nebo jsou k dispozici všem projektům.

tato dokumentace je zaměřena na použití běžců v GitLabu.Pokud potřebujete nainstalovat a nakonfigurovat Gitlab Runner, podívejte se na dokumentaci Gitlab Runner.

Typy běžců

V GitLab UI existují tři typy běžců, na základě toho, kdo chcete mít přístup:

• Sdílené běžci jsou k dispozici pro všechny skupiny a projekty v GitLab stupně.
• skupinové běžce jsou k dispozici všem projektům a podskupinám ve skupině.
• konkrétní běžci jsou spojeni s konkrétními projekty.Typicky se konkrétní běžci používají pro jeden projekt najednou.

sdílené běžce

sdílené běžce jsou k dispozici pro každý projekt v instanci GitLab.

použijte sdílené běžce, pokud máte více úloh s podobnými požadavky. Spíše než mít více běžců volnoběh pro mnoho projektů, můžete mít několik běžců, kteří zvládnou více projektů.

Pokud používáte self-managed instance GitLab:

• administrátor může nainstalovat a zaregistrovat sdílené běžci bygoing do projektu je Nastavení > CI/CD, rozšíření Běžci bod,a klepnutím na tlačítko Show runner pokyny k instalaci.Tyto pokyny jsou také k dispozici v dokumentaci.
• správce může také nakonfigurovat maximální počet sdílených runner potrubí minut foreach skupina.

Pokud používáte GitLab.com:

• můžete si vybrat ze seznamu sdílených běžců, které GitLab udržuje.
• sdílené běžci spotřebují potrubí minutyčleněné s vaším účtem.

jak sdílené běžce vybírají úlohy

sdílené běžce zpracovávají úlohy pomocí fronty spravedlivého použití. Tato fronta zabraňuje projektům vytvářet stovky pracovních míst a využívat všechny dostupné zdroje sdílených běžců.

algoritmus fair usage queue přiřazuje úlohy na základě projektů, které mají nejvíce úloh již spuštěných na sdílených běžcích.

Příklad 1

Pokud tyto úlohy jsou ve frontě:

• Práce 1 Projekt 1
• Úkol 2 Projekt 1
• úloha 3 pro Projekt 1
• Práce 4 pro Projekt 2
• Práce 5 Projekt 2
• Práce 6 Projekt 3

správné používání algoritmus přiřadí pracovních míst v tomto pořadí:

1. Práce 1 je vybrána jako první, protože to má nejnižší počet pracovních míst z projektů s žádné spuštěné úlohy (to znamená, že všechny projekty).
2. Práce 4 je další, protože 4 je nyní nejnižší počet pracovních míst z projektů s žádné spuštěné úlohy (Projektu 1 má práce běží).
3. úloha 6 je další, protože 6 je nyní nejnižší počet pracovních míst z projektů bez běžících úloh (projekty 1 a 2 mají spuštěné úlohy).
4. Úloha 2 je další, protože z projektů s nejnižším počtem spuštěných úloh (každá má 1) je to nejnižší číslo úlohy.
5. práce 5 je další, protože Projekt 1 má nyní spuštěné 2 úlohy a práce 5 je nejnižší zbývající počet pracovních míst mezi projekty 2 a 3.
6. konečně je Úloha 3 … protože je to jediná práce, která zbývá.

Příklad 2

Pokud tyto úlohy jsou ve frontě:

• Práce 1 Projekt 1
• Úkol 2 Projekt 1
• úloha 3 pro Projekt 1
• Práce 4 pro Projekt 2
• Práce 5 Projekt 2
• Práce 6 Projekt 3

správné používání algoritmus přiřadí pracovních míst v tomto pořadí:

1. Práce 1 je vybrána jako první, protože to má nejnižší počet pracovních míst z projektů s žádné spuštěné úlohy (to znamená, že všechny projekty).
2. dokončíme práci 1.
3. Úloha 2 je další, protože po dokončení úlohy 1 mají všechny projekty znovu spuštěno 0 úloh a 2 je nejnižší dostupné číslo úlohy.
4. Práce 4 je další, protože se Projekt 1 Práci, 4 je nejnižší počet z projektů běží bez práce (Projekty 2 a 3).
5. dokončíme práci 4.
6. úloha 5 je další, protože po dokončení úlohy 4 nemá Projekt 2 znovu spuštěné úlohy.
7. úloha 6 je další, protože Projekt 3 je jediný projekt, který nemá spuštěné úlohy.
8. nakonec zvolíme úlohu 3 … protože opět je to jediná práce, která zbývá.

povolit sdílené běžce

Zapnuto GitLab.com, sdílené běžci jsou povoleny ve všech projektech bydefault.

na samosprávných instancích GitLabu je musí administrátor nainstalovat a zaregistrovat.

můžete také povolit sdílené běžce pro jednotlivé projekty.

Chcete-li povolit sdílené běžce:

1. přejděte do Nastavení projektu > CI/CD a rozbalte sekci Běžci.
2. Vyberte povolit sdílené běžce pro tento projekt.

zakázat sdílené běžce

sdílené běžce můžete zakázat pro jednotlivé projekty nebo pro skupiny.Musíte mít oprávnění vlastníka pro projekt nebo skupinu.

Chcete-li zakázat sdílené běžce pro projekt:

1. přejděte do Nastavení projektu > CI/CD a rozbalte sekci Běžci.
2. v oblasti sdílených běžců vyberte Povolit sdílené běžce pro tento projekt, takže přepínač je šedý.

Sdílené běžci, jsou automaticky zakázány pro projekt:

• Pokud sdílené běžci nastavení nadřazené skupiny je zakázáno, a
• v Případě převažujícího toto nastavení není povoleno na úrovni projektu.

zakázat sdílené běžci pro skupinu:

1. Přejděte do skupiny Nastavení > CI/CD a rozšířit Běžci oddílu.
2. v oblasti sdílených běžců vypněte přepínač Povolit sdílené běžce pro tuto skupinu.
3. volitelně,Chcete-li povolit sdílené běžce pro jednotlivé projekty nebo podskupiny, klepněte na tlačítko Povolit projekty a podskupiny přepsat nastavení skupiny.

skupinové běžce

použijte skupinové běžce, pokud chcete, aby všechny projekty ve skupiněmít přístup k sadě běžců.

skupinové běžce zpracovávají úlohy pomocí fronty first in, first out (FIFO).

Vytvořit skupinu runner

můžete vytvořit skupinu runner pro vaše self-managed GitLab stupně, nebo pro GitLab.kom.Musíte mít oprávnění Vlastníka skupiny.

Chcete-li vytvořit skupinu runner:

1. nainstalujte Gitlab Runner.
2. přejděte do skupiny, pro kterou chcete, aby běžec pracoval.
3. přejděte na Nastavení > CI / CD a rozbalte sekci běžců.
4. poznamenejte si adresu URL a token.
5. zaregistrujte běžce.

Zobrazení a správa skupinových běžců

můžete zobrazit a spravovat všechny běžce pro skupinu, její podskupiny a projekty.Můžete to udělat pro vlastní instanci GitLab nebo pro GitLab. com.pro skupinu musíte mít oprávnění vlastníka.

1. přejděte do skupiny, kde chcete zobrazit běžce.
2. přejděte na Nastavení > CI / CD a rozbalte sekci běžců.

3. zobrazí se následující pole.

   Atribut	Popis
   Typ	Jeden nebo více z těchto států,: sdílené, skupina, konkrétní, zamčené, nebo pozastaveno
   Runner token	Token slouží k identifikaci runner, a že runner používá ke komunikaci s GitLab instance
   Popis	Popis běžec, když to bylo vytvořeno
   Verze	GitLab Runner verze
   IP adresa	IP adresu hostitele, na kterém běžec je registrována
   Projekty	počet projektů, na které běžec je přiřazena
   Míst	Celkem míst běh běžec
   Tagy	Značky spojené s runner
   Poslední kontakt	časové Razítko označující, kdy GitLab třeba včera kontaktoval runner

Z této stránky, můžete upravit, pozastavit a odstranit běžci ze skupiny, jeho podskupin a projektů.

Pozastavit nebo odstranit skupinu runner

můžete pozastavit nebo odstranit skupinu runner pro vaše self-managed GitLab stupně, nebo pro GitLab.kom.Musíte mít oprávnění Vlastníka skupiny.

1. přejděte do skupiny, pro kterou chcete běžce odebrat nebo pozastavit.
2. přejděte na Nastavení > CI / CD a rozbalte sekci běžců.
3. klikněte na Pozastavit nebo odebrat běžce.
   • pokud pozastavíte skupinového běžce, který používá více projektů, běžec pozastaví všechny projekty.
   • z pohledu skupiny nelze odebrat běžce, který je přiřazen k více než jednomu projektu.Nejprve je musíte z každého projektu odstranit.
4. v potvrzovacím dialogu klikněte na OK.

konkrétní běžci

použijte konkrétní běžce, pokud chcete použít běžce pro konkrétní projekty. Například, když máte:

• úlohy se specifickými požadavky, jako je nasazení úlohy, která vyžaduje pověření.
• projekty s velkou aktivitou CI, které mohou těžit z toho, že jsou odděleny od ostatních běžců.

můžete nastavit konkrétní běžec, který bude použit pro více projektů. Konkrétní runnersmusí být povolen pro každý projekt explicitně.

konkrétní běžci zpracovávají úlohy pomocí fronty first in, first out (FIFO).

Vytvořit konkrétní runner

můžete vytvořit konkrétní strategie pro self-managed GitLab stupně, nebo pro GitLab.kom.Musíte mít oprávnění Vlastníka projektu.

Chcete-li vytvořit konkrétní běžec:

1. nainstalujte běžec.
2. přejděte do Nastavení projektu > CI / CD a rozbalte sekci Běžci.
3. poznamenejte si adresu URL a token.
4. zaregistrujte běžce.

povolit konkrétního běžce pro konkrétní projekt

konkrétní běžec je k dispozici v projektu, pro který byl vytvořen. Správce může určit konkrétního běžce, který se přihlásí na další projekty.

• musíte mít oprávnění vlastníka projektu.
• konkrétní běžec nesmí být uzamčen.

povolit nebo zakázat konkrétní běžec na projekt:

1. Jít na projektu je Nastavení > CI/CD a rozšířit Běžci oddílu.
2. klikněte na Povolit pro tento projekt nebo zakázat pro tento projekt.

Zabránit konkrétní runner od být povoleno pro další projekty

můžete nastavit konkrétní běžec, takže to je „uzamčen“ a nemůže být povolena pro další projekty.Toto nastavení lze povolit při první registraci běžce, ale lze jej také později změnit.

Chcete-li běžce zamknout nebo odemknout:

1. přejděte do Nastavení projektu > CI/CD a rozbalte sekci Běžci.
2. Najděte běžce, kterého chcete zamknout nebo odemknout. Ujistěte se, že je povoleno.
3. klikněte na tlačítko tužky.
4. zaškrtněte možnost zamknout aktuální projekty.
5. klikněte na Uložit změny.

ručně vymažte mezipaměť běžce

čtení vymazání mezipaměti.

Nastavte maximální časový limit úlohy pro běžce

pro každého běžce můžete určit maximální časový limit úlohy. Tento časový limit, pokud je menší než časový limit definovaný projektem, má přednost.

Tato funkce může být použita k zabránění zahlcení sdíleného běžce projektem, který má úlohy s dlouhým časovým limitem (například jeden týden).

Pokud není nakonfigurován, běžci nemají přepsat časový limit projektu.

na GitLabu.s, nemůžete přepsat časový limit úlohy pro sdílené běžce a musíte použít časový limit definovaný projektem.

Chcete-li nastavit maximální práci timeout:

1. V projektu, přejděte na Nastavení > CI/CD > Běžci.
2. vyberte svého konkrétního běžce a upravte nastavení.
3. zadejte hodnotu do maximálního časového limitu úlohy.
4. vyberte Uložit změny.

jak tato funkce funguje:

Příklad 1 – Runner časový limit větší než projekt timeout

1. můžete nastavit maximální časový limit pro práci běžec do 24 hodin
2. nastavit CI/CD Timeout pro projekt na 2 hodiny
3. práci
4. práci, pokud běží déle, po 2 hodinách

Příklad 2 – Runner timeout není nakonfigurován tak,

1. odstranit maximální práci timeout konfigurace z běžce
2. nastavit CI/CD Timeout pro projekt na 2 hodiny
3. práci
4. práci, pokud běží déle, po 2 hodinách

Příklad 3 – Runner časový limit menší než projekt timeout

1. můžete nastavit maximální časový limit pro práci běžec na 30 minut
2. nastavit CI/CD Timeout pro projekt na 2 hodiny
3. práci
4. práci, pokud běží déle, vyprší po 30 minutách

Buďte opatrní s citlivými informacemi

U některých runner exekutory,pokud můžete spustit úlohu na běžce, můžete získat plný přístup k systému souborů,a tak žádný kód to běží, stejně jako symbol běžce. U sdílených běžců to znamená, že kdokoli, kdo běží na běžci, má přístup k kódu kohokoli jiného, který běží na běžci.

navíc, protože můžete získat přístup k tokenu runner, je to možnévytvořit klon běžce a odeslat například falešné úlohy.

výše uvedené je snadno vyhnout tím, že omezí používání sdílené runnerson velké veřejné GitLab případech, ovládající přístup k GitLab instance,a použití více bezpečné runner exekutory.

zabraňte běžcům odhalit citlivé informace

běžce můžete chránit, aby neodhalili citlivé informace.Když je běžec chráněn, běžec vybere úlohy vytvořené pouze na chráněných větvích nebo chráněných štítcích a ignoruje další úlohy.

Chcete-li chránit nebo odpojit běžce:

1. přejděte do Nastavení projektu > CI/CD a rozbalte sekci Běžci.
2. Najděte běžce, kterého chcete chránit, nebo jej nechráňte. Ujistěte se, že je povoleno.
3. klikněte na tlačítko tužky.
4. zkontrolujte chráněnou volbu.
5. klikněte na Uložit změny.

Vidličky

vždy, když projekt je rozeklaný, zkopíruje nastavení úlohy, které děti postupují. To znamená, že pokud máte sdílené běžce nastavené pro projekt aněkdo vidle tohoto projektu, sdílené běžce slouží pracovním místům tohoto projektu.

útočné vektory u běžců

byly krátce zmíněny dříve, ale lze využít následující věci běžců.Vždy hledáme příspěvky, které mohou tyto bezpečnostní aspekty zmírnit.

resetujte registrační token běžce pro projekt

Pokud si myslíte, že byl odhalen registrační token pro projekt, měli byste jej obnovit. Token lze použít k registraci jiného běžce pro projekt. Tento nový runnermůže být použit k získání hodnot tajných proměnných nebo ke klonování kódu projektu.

Chcete-li resetovat token:

1. přejděte do Nastavení projektu > CI/CD.
2. rozbalte sekci Obecné nastavení potrubí.
3. najděte pole formuláře tokenu Runner a klikněte na tlačítko odhalit hodnotu.
4. vymažte hodnotu a formulář uložte.
5. po obnovení stránky rozbalte sekci Nastavení Běžcůa zkontrolujte registrační token – měl by být změněn .

od této chvíle již starý token není platný a nezaregistruje žádné nové běžce do projektu. Pokud používáte nějaké nástroje k poskytování a registraci nových běžců, tokeny použité v těchto nástrojích by měly být aktualizovány tak, aby odrážely hodnotu nového tokenu.

Určete IP adresu běžce

může být užitečné znát IP adresu běžce, abyste mohli s tímto běžcem řešit problémy. GitLab ukládá a zobrazuje IP adresu zobrazenímzdroj požadavků HTTP, které dává GitLabu při dotazování na úlohy. TheIP adresa je vždy aktuální, takže pokud běžec IP změní itautomatically aktualizace v GitLabu.

IP adresu pro sdílené běžce a konkrétní běžce najdete na různých místech.

Určete IP adresu sdíleného běžce

Chcete-li zobrazit IP adresu sdíleného běžce, musíte mít přístup správce k instanci GitLab. Chcete-li zjistit toto:

1. navštivte administrátorskou oblast > přehled > Běžci.
2. vyhledejte běžce v tabulce a měli byste vidět sloupec pro IP adresu.

Zjistit IP adresu konkrétního běžce

můžete najít IP adresu běžec pro konkrétní projekt,musíte mít oprávnění Vlastníka projektu.

1. přejděte do Nastavení projektu > CI / CD a rozbalte sekci Běžci.
2. na stránce s podrobnostmi byste měli vidět řádek pro IP adresu.

Použít značky k omezení počtu pracovních míst pomocí runner

musíte nastavit běžec musí být schopen spustit všechny různé typy jobsthat to může narazit na projekty je společná všem. To by bylo problematické pro velké množství projektů, pokud by to nebylo pro značky.

značky GitLab CI nejsou stejné jako značky Git. Značky GitLab CI jsou spojeny s běžci.Značky Git jsou spojeny s commity.

označením běžce pro typy úloh, které zvládne, se můžete ujistit, že běžci budou provozovat pouze úlohy, které jsou k běhu vybaveny.

například v GitLabu máme běžce označené rails pokud obsahují příslušné závislosti pro spuštění testovacích sad Rails.

když zaregistrujete běžce, jeho výchozí chování je pouze picktagged jobs.To změňte to, musíte mít oprávnění vlastníka pro projekt.

Chcete-li, aby běžec vybral neoznačené úlohy:

1. přejděte do Nastavení projektu > CI / CD a rozbalte sekci Běžci.
2. Najděte běžce, který chcete vybrat neoznačené úlohy, a ujistěte se, že je povolen.
3. klikněte na tlačítko tužky.
4. zkontrolujte volbu Spustit neoznačené úlohy.
5. klikněte na tlačítko Uložit změny, aby se změny projevily.

níže jsou uvedeny příklady různých variant.

runner běží pouze označené úlohy

následující příklady ilustrují potenciální dopad běžce, který je setto spustit pouze označené úlohy.

Příklad 1:

1. běžec je nakonfigurován tak, aby spouštěl pouze označené úlohy a má značku docker.
2. úloha, která má značku hello, je spuštěna a zaseknuta.

Příklad 2:

1. běžec je nakonfigurován tak, aby spustit pouze tagged pracovních míst a má docker tag.
2. úloha, která má značku docker, je spuštěna a spuštěna.

příklad 3:

1. běžec je nakonfigurován tak, aby spouštěl pouze označené úlohy a má značku docker.
2. úloha, která nemá definované značky, je vykonána a zaseknuta.

runner je povoleno spuštění neoznačených míst

následující příklady ilustrují možný dopad runner být nastavena na spuštění označených a neoznačených míst.

Příklad 1:

1. běžec je nakonfigurován pro spouštění neoznačených úloh a má značku docker.
2. úloha, která nemá definované značky, je spuštěna a spuštěna.
3. druhá úloha, která má docker definovanou značku, je spuštěna a spuštěna.

příklad 2:

1. běžec je nakonfigurován pro spouštění neoznačených úloh a nemá definované značky.
2. úloha, která nemá definované značky, je spuštěna a spuštěna.
3. druhá úloha, která má definovanou značku docker, je zaseknutá.

konfigurace chování běžce pomocí proměnných

proměnné CI / CD můžete použít ke konfiguraci chování běžce Git globálně nebo pro jednotlivé úlohy:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (mělké klonování)
• GIT_CLONE_PATH (vlastní sestavení adresářů)

můžete také použít proměnné, konfigurace, kolikrát runnerattempts určitých fázích provádění úlohy.

strategie Git

můžete nastavit GIT_STRATEGY používá se pro načtení obsahu úložiště, eitherglobally nebo za práci v variables sekce:

variables: GIT_STRATEGY: clone

k Dispozici jsou tři možné hodnoty: clonefetchnone. Pokud je ponecháno nespecifikované,úlohy používají nastavení potrubí projektu.

clone je nejpomalejší volba. Klonuje úložiště od nuly pro everyjob, což zajišťuje, že místní pracovní kopie je vždy nedotčená.Pokud je nalezen existující pracovní strom, je před klonováním odstraněn.

fetch je rychlejší, jak to re-využívá místní pracovní kopii (padající zpět do clonepokud neexistuje). git clean se používá, aby se vrátit zpět všechny změny provedené lastjob, a git fetch se používá k načtení zavazuje provedené po poslední práci běžel.

fetch však vyžaduje přístup k předchozímu pracovnímu stromu. Tento workswell při používání shell nebo docker exekutor, protože thesetry zachovat worktrees a pokusit se re-použití je ve výchozím nastavení.

to má omezení při použití Docker Machine executor.

nefunguje pro kubernetes executor, ale existuje návrh funkce.kubernetes executor vždy klonuje do dočasného adresáře.

Git strategie none také re-využívá místní pracovní kopii, ale přeskočí všechny Gitoperations obvykle provádí GitLab. GitLab Runner pre-klon skripty jsou také přeskočeny, pokud jsou k dispozici. Tato strategie by mohla znamenat, že budete muset přidat fetchcheckout commandsto .gitlab-ci.yml skript.

může být použit pro úlohy, které pracují výhradně na artefaktech, jako je úloha nasazení.Data úložiště Git mohou být přítomna, ale pravděpodobně jsou zastaralá. Měli byste pouze soubory přenesené do místní pracovní kopie z mezipaměti nebo artefaktů.

Git submodul strategie

Vyžaduje GitLab Runner v1.10+.

GIT_SUBMODULE_STRATEGY proměnná se používá k ovládání, zda / jak Gitsubmodules jsou zahrnuty při načítání kódu, než stavět. Můžete je nastavit globálně nebo podle úlohy v sekci variables.

k Dispozici jsou tři možné hodnoty: nonenormalrecursive:

• none znamená, že submoduly nejsou zahrnuty při načítání projectcode. Toto je výchozí nastavení, které odpovídá chování před v1. 10.

• normal znamená, že jsou zahrnuty pouze submoduly nejvyšší úrovně. To je:

  git submodule syncgit submodule update --init

• recursive znamená, že všechny ostatní verze (včetně podmoduly rizika pro podmoduly rizika)jsou v ceně. Tato funkce potřebuje git v1. 8. 1 a novější. Pokud používáte Agitlab Runner s exekutorem, který není založen na Dockeru, ujistěte se, že verze Git splňuje tento požadavek. Je to ekvivalentní:

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

tato funkce pracovat správně, submoduly, musí být nakonfigurován(v .gitmodules) buď s:

• HTTP(S) URL veřejně přístupné úložiště, nebo
• relativní cesta do jiného úložiště na stejném GitLab server. Viz dokumentace submodulů git.

git checkout

GIT_CHECKOUT proměnná může být použita, když GIT_STRATEGY je nastavena naclone nebo fetch určit, zda git checkout by měl být spuštěn. Pokud není uvedeno, je výchozí hodnota true. Můžete je nastavit globálně nebo podle úlohy v sekcivariables.

Pokud je nastaven na false, běžec:

• když děláte fetch – aktualizace úložiště a listy pracovní kopie na aktuální revizi,
• když děláte clone – klony repozitáře a listy pracovní kopie na výchozí pobočky.

Pokud GIT_CHECKOUT je nastavena na trueclonefetch pracovat stejným způsobem.Běžec zkontroluje pracovní kopii revize související s potrubím CI:

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

Git čisté vlajky

GIT_CLEAN_FLAGS proměnná se používá k ovládání výchozí chovánígit clean po rezervování zdrojů. Můžete jej nastavit globálně nebo podle úlohy v sekcivariables.

GIT_CLEAN_FLAGS přijímá všechny možné možnosti příkazu git clean.

git clean je zakázáno, pokud je zadáno GIT_CHECKOUT: "false".

Pokud GIT_CLEAN_FLAGS je:

• nespecifikováno,git clean flags default to -ffdx.
• vzhledem k hodnotě nonegit clean není spuštěn.

například:

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

Git fetch další vlajky

proměnná GIT_FETCH_EXTRA_FLAGS se používá k řízení chovánígit fetch. Můžete jej nastavit globálně nebo podle úlohy v sekci variables.

GIT_FETCH_EXTRA_FLAGS přijímá všechny možnosti příkazu git fetch. Nicméně,GIT_FETCH_EXTRA_FLAGS příznaky jsou připojeny za výchozí příznaky, které nelze změnit.

výchozí příznaky jsou:

• GIT_DEPTH.
• seznam refspecs.
• dálkový ovladač nazvaný origin.

Pokud GIT_FETCH_EXTRA_FLAGS je:

• Není zadán, git fetch vlajky výchozí --prune --quiet spolu s výchozí vlajky.
• vzhledem k hodnotě none se git fetch provádí pouze s výchozími příznaky.

například, default vlajky jsou --prune --quiet, takže si můžete udělat git fetch více informací naléhavými to jen --prune:

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

konfigurace výše uvedených výsledků v git fetch být nazýván tímto způsobem:

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

Kde $REFSPECS je hodnota, za předpokladu, běžec interně GitLab.

mělké klonování

hloubku načítání a klonování můžete určit pomocí GIT_DEPTHGIT_DEPTH má mělký klon úložiště a může výrazně urychlit klonování.To může být užitečné pro úložiště s velkým počtem commitů, nebo staré, velké binární soubory. Hodnota je převedena na git fetch a git clone.

V GitLab 12.0 a novější, nově vytvořené projekty mají automaticky adefault git depth hodnota 50.

Pokud použijete hloubku 1 a máte frontu úloh nebo opakování, úlohy mohou selhat.

načítání a klonování Gitu je založeno na ref, jako je název větve, takže běžci nemohou klonovat konkrétní commit SHA. Pokud je ve frontě více úloh, nebo zkoušíte starou úlohu, musí být testovaný závazek v historii git, která je klonována. Nastavení příliš malé hodnoty pro GIT_DEPTH může přežil nemožné, aby tyto staré a zavazuje unresolved reference se zobrazí injob protokoly. Pak byste měli přehodnotit změnu GIT_DEPTH na vyšší hodnotu.

Míst, které spoléhají na git describe nemusí fungovat správně, když GIT_DEPTH isset, protože pouze část Git historie je přítomen.

Chcete-li načíst nebo klonovat pouze Poslední 3 odevzdání:

variables: GIT_DEPTH: "3"

můžete nastavit globálně, nebo per-práci v variables oddíl.

vlastní sestavení adresářů

ve výchozím nastavení GitLab Runner klony repozitáře v jedinečné subpath$CI_BUILDS_DIR adresář. Váš projekt však může vyžadovat kód v aspecifickém adresáři (například projekty Go). V takovém případě můžete zadatGIT_CLONE_PATH proměnnou, která řekne běžci adresář, ve kterém má klonovat:

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

GIT_CLONE_PATH musí být vždy do $CI_BUILDS_DIR. Adresář nastavený v $CI_BUILDS_DIRje závislý na vykonavateli a konfiguraci běžců.builds_dirsetting.

to lze použít pouze tehdy, když je v konfiguraci programu povoleno custom_build_dir.Toto je výchozí konfigurace pro docker a kubernetes executors.

zpracování souběžnosti

exekutor, který používá souběžnost větší než 1 může vést k selhání. Více úloh může pracovat ve stejném adresáři, pokud je builds_dirsdíleno mezi úlohami.

běžec se nesnaží této situaci zabránit. Je na správcea vývojáři, aby splnili požadavky na konfiguraci runner.

Aby se předešlo této situaci, můžete použít jedinečnou cestu do $CI_BUILDS_DIR, protože runnerexposes další dvě proměnné, které poskytují jedinečnou ID souběžnosti:

• $CI_CONCURRENT_ID: Unikátní ID pro všechny úlohy, běžící v rámci daného exekutora.
• $CI_CONCURRENT_PROJECT_ID: unikátní ID pro všechny úlohy běžící v rámci daného exekutora a projektu.

nejstabilnější konfigurace, které by měly dobře fungovat v jakékoliv situaci a na jakémkoliv executoris použít $CI_CONCURRENT_IDGIT_CLONE_PATH. Například:

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

$CI_CONCURRENT_PROJECT_ID by měl být použit ve spojení s $CI_PROJECT_PATH$CI_PROJECT_PATH poskytuje cestu úložiště. To znamená group/subgroup/project. Například:

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

Vnořené cesty

hodnota GIT_CLONE_PATH je rozšířen jednou a vnoření variableswithin není podporován.

například definujete obě proměnné níže v souboru.gitlab-ci.yml :

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

hodnota GIT_CLONE_PATH je rozšířen jednou do$CI_BUILDS_DIR/go/src/namespace/project, a výsledky v failurebecause $CI_BUILDS_DIR není rozšířen.

Job stages pokusy

můžete nastavit počet pokusů, které se běžící úloha pokusí provést následující fáze:

výchozí nastavení je jeden jediný pokus.

Příklad:

variables: GET_SOURCES_ATTEMPTS: 3

můžete nastavit globálně, nebo per-práci v variables oddíl.

systémová volání nejsou k dispozici na GitLab.com sdílené běžce

GitLab.com společné běžci běží na CoreOS. To znamená, že ze standardní knihovny C nelze použít některá systémová volání, například getlogin.

nastavení artefaktu a mezipaměti

nastavení artefaktu a mezipaměti řídí kompresní poměr artefaktů a mezipaměti.Pomocí těchto nastavení určete velikost archivu vytvořeného úlohou.

• v pomalé síti může být nahrávání rychlejší pro menší archivy.
• v rychlé síti, kde šířka pásma a úložiště nejsou problémem, může být nahrávání rychlejší pomocí nejrychlejšího kompresního poměru, přestože je produkovaný archiv větší.

Pro GitLab Stránky serveHTTP Rozsah požadavků, artifactsshould použít ARTIFACT_COMPRESSION_LEVEL: fastest nastavení, pouze jako nekomprimované zip archivessupport tuto funkci.

měřič může být také povolen, aby poskytoval rychlost přenosu pro nahrávání a stahování.

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"