• futók típusai
  • megosztott futók
    • hogyan választanak munkát a megosztott futók
    • engedélyezze a megosztott futókat
    • tiltsa le a megosztott futókat
  • Csoportos futók
    • Csoportos futó létrehozása
    • Csoportos futók megtekintése és kezelése
    • szüneteltetése vagy eltávolítása csoport futó
  • specifikus futók
    • egy adott futó létrehozása
    • egy adott futó engedélyezése egy adott projekthez
    • egy adott futó engedélyezése más projektekhez
• manuálisan törölje a futó gyorsítótárát
• maximális munka időtúllépés beállítása egy futó számára
• legyen óvatos az érzékeny információkkal
  • megakadályozza, hogy a futók érzékeny információkat fedjenek fel
  • villák
  • támadási vektorok a futókban
  • állítsa vissza a futó regisztrációs tokenjét egy projekthez
• határozza meg a futó IP-címét
  • határozza meg a megosztott futó IP-címét
  • /li>
  • határozza meg egy adott futó IP-címét
• címkékkel korlátozhatja a futó használatával végzett feladatok számát
  • a futó csak címkézett feladatokat fut
  • a futó futtathat címkézetlen feladatokat
• konfigurálja a futó viselkedését változókkal
  • Git stratégia
  • Git submodule stratégia
  • Git checkout
  • Git clean zászlók
  • Git fetch extra zászlók
  • sekély klónozás
  • egyedi építésű könyvtárak
    • párhuzamosság kezelése
    • beágyazott útvonalak
  • job szakaszok kísérletek
• rendszerhívások nem érhetők el GitLab.com megosztott futók
• Artifact and cache settings

a GitLab CI/CD-ben a futók a .gitlab-ci.yml alatt definiált kódot futtatják.A runner egy könnyű, nagymértékben skálázható ügynök, amely felveszi a CI munkát a GitLab CI / CD koordinátor API-ján keresztül, futtatja a feladatot, és visszaküldi az eredményt a GitLab példánynak.

a futókat egy adminisztrátor hozza létre, és a GitLab felhasználói felületén láthatók.A futók specifikusak lehetnek bizonyos projektekre, vagy minden projekt számára elérhetők.

Ez a dokumentáció a GitLab futóinak használatára összpontosít.Ha telepítenie és konfigurálnia kell a GitLab Runnert, olvassa el a GitLab Runner dokumentációját.

futótípusok

a GitLab felhasználói felületén három futótípus létezik, attól függően, hogy kihez szeretne hozzáférni:

• a megosztott futók minden csoport és projekt számára elérhetők egy GitLab példányban.
• a csoportos futók a csoport összes projektje és alcsoportja számára elérhetők.
• Az egyes futók konkrét projektekhez vannak társítva.Jellemzően meghatározott futókat használnak egyszerre egy projekthez.

megosztott futók

a megosztott futók minden projekt számára elérhetők egy GitLab példányban.

használjon megosztott futókat, ha több, hasonló követelményekkel rendelkező munkája van. Ahelyett, hogy több futó üresjáratban lenne sok projektnél, lehet néhány futó, aki több projektet kezel.

Ha a GitLab saját kezű példányát használja:

• a rendszergazda telepítheti és regisztrálhatja a megosztott futókat a projekt beállításainál > CI / CD, kibontva a futók részt,majd a futók telepítési útmutatójának megjelenítése gombra kattintva.Ezek az utasítások a dokumentációban is megtalálhatók.
• a rendszergazda is beállíthatja a maximális számú megosztott futó folyamat perc foreach csoport.

Ha Ön GitLab.com:

• a GitLab által fenntartott megosztott futók listájából választhat.
• a megosztott futók felhasználják a fiókjához tartozó csővezetékek perceit.

A megosztott futók hogyan választanak munkát

a megosztott futók tisztességes használati sor használatával dolgozzák fel a feladatokat. Ez a sor megakadályozza, hogy a projektek több száz munkahelyet hozzanak létre, és felhasználják az összes rendelkezésre álló megosztott futó erőforrást.

a fair usage queue algoritmus azon projektek alapján rendel hozzá feladatokat, amelyeknél a legkevesebb feladat már fut megosztott futókon.

1.példa

Ha ezek a feladatok a sorban vannak:

• 1. feladat 1. projekthez
• 2. feladat 1. projekthez
• 3. feladat 1. projekthez
• 4. feladat 2. projekthez
• 5. feladat 2. projekthez
• 6. feladat 3. projekthez

a fair usage algoritmus a következő sorrendben rendel feladatokat:

1. az 1. feladat kerül először kiválasztásra, mert a futó feladatok nélküli projektek (azaz az összes projekt) közül a legalacsonyabb a Feladatszáma.
2. A 4.feladat a következő, mert a 4 most a legalacsonyabb feladatszám a futó feladatok nélküli projektekből (az 1. projektnek futó feladata van).
3. a 6.feladat a következő, mert a 6 most a legalacsonyabb feladatszám a futó feladatok nélküli projektek közül (az 1. és 2. projektekben futó feladatok vannak).
4. a 2.feladat a következő, mert a legkevesebb futó feladatot futtató projektek közül (mindegyiknek 1 van) ez a legalacsonyabb feladatszám.
5. az 5.feladat a következő, mert az 1. projektnek most 2 munkája fut, és az 5. feladat a legalacsonyabb hátralévő feladatszám a 2. és a 3. Projekt között.
6. végül a 3. feladat … mert ez az egyetlen munka maradt.

2.példa

Ha ezek a feladatok a sorban vannak:

• 1. feladat 1. projekthez
• 2. feladat 1. projekthez
• 3. feladat 1. projekthez
• 4. feladat 2. projekthez
• 5. feladat 2. projekthez
• 6. feladat 3. projekthez

a fair usage algoritmus a következő sorrendben rendel feladatokat:

1. először az 1. feladat kerül kiválasztásra, mert a futó feladatok nélküli projektek (azaz az összes projekt) közül a legalacsonyabb a Feladatszáma.
2. befejezzük az 1. munkát.
3. a 2.feladat a következő, mert az 1. Feladat befejezése után minden projektnek újra 0 munkája fut, a 2 pedig a legalacsonyabb elérhető feladatszám.
4. A 4.feladat a következő, Mert ha az 1. projekt futtat egy feladatot, akkor a 4 a legalacsonyabb szám a nem futó projektek közül (2. és 3. projekt).
5. befejezzük a 4. munkát.
6. az 5.feladat a következő, mert a 4. feladat befejezése után a 2. projekt nem fut újra.
7. a 6.feladat a következő, mert a 3. projekt az egyetlen projekt, amely nem tartalmaz futó feladatokat.
8. végül a 3. munkát választjuk … mert ismét ez az egyetlen munka maradt.

megosztott futók engedélyezése

be GitLab.com, a megosztott futók minden projektben engedélyezve vannakalapértelmezés szerint.

a GitLab saját kezű példányain a rendszergazdának telepítenie kellés regisztrálnia kell őket.

az egyes projektekhez megosztott futókat is engedélyezhet.

a megosztott futók engedélyezése:

1. lépjen a projekt beállításaihoz> CI / CD és bontsa ki a futók részt.
2. válassza a megosztott futók engedélyezése lehetőséget ehhez a projekthez.

A megosztott futók letiltása

letilthatja a megosztott futókat az egyes projektek vagy csoportok számára.A projekthez vagy csoporthoz tulajdonosi engedélyekkel kell rendelkeznie.

a megosztott futók letiltása egy projekthez:

1. lépjen a projekt beállításaihoz > CI/CD és bontsa ki a futók részt.
2. a megosztott futók területen válassza a megosztott futók engedélyezése ehhez a projekthez lehetőséget, így a kapcsoló szürkén jelenik meg.

a megosztott futók automatikusan le vannak tiltva egy projektnél:

• ha a szülőcsoport megosztott futók beállítása le van tiltva, és
• ha a Beállítás felülbírálása nem engedélyezett a projekt szintjén.

a megosztott futók letiltása egy csoporthoz:

1. lépjen a csoport beállításaihoz > CI/CD majd bontsa ki a futók részt.
2. a megosztott futók területen kapcsolja ki a megosztott futók engedélyezése ehhez a csoporthoz kapcsolót.
3. Ha azt szeretné, hogy a megosztott futók engedélyezve legyenek az egyes projektekhez vagy alcsoportokhoz,kattintson a projektek és alcsoportok engedélyezése lehetőségre a csoportbeállítás felülbírálásához.

Csoportos futók

használja a csoportos futókat, ha azt szeretné, hogy a csoport összes projektje hozzáférjen egy futókészlethez.

a csoportos futók a first in, first out (FIFO) sor használatával dolgozzák fel a feladatokat.

hozzon létre egy csoport futót

létrehozhat egy csoport futót a saját kezű GitLab-példányhoz vagy a GitLab.com-hoz.a csoporthoz tulajdonosi engedélyekkel kell rendelkeznie.

Csoportos futó létrehozása:

1. telepítse a GitLab Runnert.
2. LÉPJEN abba a csoportba, amelynek a futót működtetni szeretné.
3. lépjen a Beállítások > CI/CD elemre, majd bontsa ki a futók részt.
4. jegyezze fel az URL-t és a tokent.
5. regisztrálja a futót.

Csoportos futók megtekintése és kezelése

megtekintheti és kezelheti a csoport összes futóját, annak alcsoportjait és projektjeit.Ezt a saját kezű GitLab-példány vagy a GitLab.com esetében teheti meg.a csoporthoz tulajdonosi engedélyekkel kell rendelkeznie.

1. LÉPJEN abba a csoportba, ahol meg szeretné tekinteni a futókat.
2. lépjen a Beállítások > CI/CD elemre, majd bontsa ki a futók részt.

3. a következő mezők jelennek meg.

   attribútum	leírás
   Típus	a következő állapotok közül egy vagy több: megosztott, Csoportos, specifikus, zárolt vagy szüneteltetett
   futó token	Token a futó azonosítására szolgál, és amelyet a futó a GitLab példányával való kommunikációhoz használ
   leírás	leírás a futónak a létrehozásakor adott leírás
   Verzió	GitLab futó verzió
   IP-cím	annak a gazdagépnek az IP-címe, amelyen a futó regisztrálva van
   projektek	azoknak a projekteknek a száma, amelyekhez a futó hozzá van rendelve
   jobs	a futó által futtatott feladatok összesen
   címkék	a futóhoz Kapcsolódó címkék
   Utolsó kapcsolat	időbélyeg, amely jelzi, hogy a GitLab példány mikor lépett utoljára kapcsolatba a futóval

ezen az oldalon szerkesztheti, szüneteltetheti és eltávolíthatja a futókat a csoportból, annak alcsoportjaiból és projektjeiből.

csoportfuttató szüneteltetése vagy eltávolítása

a csoportfuttatót szüneteltetheti vagy eltávolíthatja a saját kezű GitLab-példányhoz vagy a GitLab.com-hoz.a csoporthoz tulajdonosi engedélyekkel kell rendelkeznie.

1. LÉPJEN abba a csoportba, amelynek el szeretné távolítani vagy szüneteltetni a futót.
2. lépjen a Beállítások > CI/CD elemre, majd bontsa ki a futók részt.
3. kattintson a futó szüneteltetése vagy eltávolítása elemre.
   • ha szünetelteti a több projekt által használt csoportos futót, a futó minden projektnél szünetel.
   • a csoportnézetből nem távolíthat el egynél több projekthez rendelt futót.Először minden projektből el kell távolítania.
4. a megerősítő párbeszédpanelen kattintson az OK gombra.

specifikus futók

használjon konkrét futókat, ha konkrét projektekhez szeretne futókat használni. Például, ha:

• feladatok vannak speciális követelményekkel, például egy hitelesítő adatokat igénylő telepítési feladat.
• sok CI tevékenységet folytató projektek, amelyek számára előnyös lehet, ha elkülönülnek a többi futótól.

beállíthat egy adott futót, amelyet több projekt használ. Az egyes projektekhez kifejezetten engedélyezni kell az egyes futtatókat.

Az egyes futók a first in, first out (FIFO) sor használatával dolgozzák fel a feladatokat.

hozzon létre egy adott futót

létrehozhat egy adott futót a saját kezű GitLab-példányhoz vagy a GitLab.com-hoz.a projekthez tulajdonosi engedélyekkel kell rendelkeznie.

egy adott futó létrehozása:

1. telepítse a futót.
2. nyissa meg a projekt beállításait > CI/CD és bontsa ki a futók részt.
3. jegyezze fel az URL-t és a tokent.
4. regisztrálja a futót.

egy adott futó engedélyezése egy adott projekthez

egy adott futó elérhető abban a projektben, amelyhez létrehozták. Az adminisztrátor engedélyezheti egy adott futó alkalmazását további projektekre.

• a projekthez tulajdonosi engedélyekkel kell rendelkeznie.
• az adott futót nem szabad lezárni.

egy adott futó engedélyezése vagy letiltása egy projekthez:

1. lépjen a projekt beállításaihoz > CI/CD és bontsa ki a futók részt.
2. kattintson a projekt engedélyezése vagy letiltása elemre.

egy adott futó engedélyezésének megakadályozása más projektekhez

beállíthat egy adott futót úgy, hogy az “zárolva” legyen, és más projektekhez nem engedélyezhető.Ez a Beállítás engedélyezhető, amikor először regisztrál egy futót, de később is módosítható.

futó zárolása vagy feloldása:

1. lépjen a projekt beállításaihoz> CI / CD és bontsa ki a futók részt.
2. keresse meg a zárolni vagy feloldani kívánt futót. Ellenőrizze, hogy engedélyezve van-e.
3. kattintson a ceruza gombra.
4. jelölje be az aktuális projektek zárolása opciót.
5. kattintson a módosítások mentése gombra.

manuálisan törölje a futó gyorsítótárát

olvassa el a gyorsítótár törlését.

maximális feladat időtúllépés beállítása egy futó számára

minden futó esetében megadhat egy maximális feladat időtúllépést. Ez az időtúllépés,ha kisebb, mint a projekt által meghatározott időtúllépés, elsőbbséget élvez.

ezzel a funkcióval megakadályozható, hogy a megosztott futót túlterhelje egy olyan projekt, amely hosszú időtúllépéssel (például egy héttel) rendelkezik.

ha nincs konfigurálva, a futók nem írják felül a projekt időtúllépését.

a GitLab-on.com, nem írhatja felül a feladat időtúllépését a megosztott futók számára, és a projekt által meghatározott időtúllépést kell használnia.

a feladat maximális időtúllépésének beállításához:

1. egy projektben lépjen a Beállítások > CI/CD > Futók menüpontra.
2. válassza ki az adott futót a beállítások szerkesztéséhez.
3. adjon meg egy értéket a maximális munka időtúllépés alatt.
4. válassza a módosítások mentése lehetőséget.

hogyan működik ez a funkció:

1. példa – a futó időtúllépése nagyobb, mint a projekt időtúllépése

1. a futó maximális időtúllépését 24 órára állítod be
2. a projekt CI/CD időtúllépését 2 órára állítod
3. munkát kezdesz
4. a feladat, ha hosszabb ideig fut, 2 óra elteltével időtúllépés

2. példa – a futó időtúllépése nincs konfigurálva

1. eltávolítja a futó maximális időtúllépését
   1. job timeout konfiguráció futóból
   2. a projekt CI/CD időtúllépését 2 órára állítod
   3. munkát kezdesz
   4. a feladat, ha hosszabb ideig fut, 2 óra elteltével időtúllépést jelent

   3. példa – futó időtúllépés kisebb, mint a projekt időtúllépés

   1. Beállítja a futó maximális időtúllépését 30 percre
   2. Beállítja a projekt CI/CD időtúllépését 2 órára
   3. elindít egy munkát
   4. a feladat, ha hosszabb ideig fut,30 perc elteltével időkorlátot kap

   legyen óvatos az érzékeny információkkal

   néhány futó végrehajtóval, ha futtathat egy munkát a futón,akkor kap teljes hozzáférést biztosít a fájlrendszer, és így minden kódot fut, valamint a token a futó. A megosztott futókkal ez azt jelenti, hogy bárki, aki fut a futón, hozzáférhet bárki más kódjához, amely fut a futón.

   Ezen túlmenően, mivel hozzáférhet a futó tokenhez, lehetőség van egy futó klónjának létrehozására, és például hamis feladatok benyújtására.

   a fentiek könnyen elkerülhetők, ha korlátozzuk a megosztott futtatók használatát a nagy nyilvános GitLab példányokon,szabályozzuk a hozzáférést a GitLab példányhoz, és biztonságosabb futtatókat használunk.

   megakadályozza, hogy a futók érzékeny információkat tárjanak fel

   bevezetett GitLab 10.0.

   megvédheti a futókat, hogy ne fedjenek fel érzékeny információkat.Ha egy futó védett, a futó csak védett ágakon vagy védett címkéken létrehozott munkákat választ, más feladatokat pedig figyelmen kívül hagy.

   futó védelme vagy védelme:

   1. lépjen a projekt beállításaihoz> CI / CD és bontsa ki a futók részt.
   2. keresse meg a védeni vagy védeni kívánt futót. Ellenőrizze, hogy engedélyezve van-e.
   3. kattintson a ceruza gombra.
   4. ellenőrizze a Védett opciót.
   5. kattintson a módosítások mentése gombra.

   

   Forks

   amikor egy projekt villás, másolja a beállításokat a feladatok relateto rá. Ez azt jelenti, hogy ha megosztott futókat állított be egy projekthez, és valaki villát adott a projekthez, akkor a megosztott futók a projekt feladatait szolgálják fel.

   támadási vektorok a futókban

   röviden említettük korábban, de a futók következő dolgai kihasználhatók.Mindig olyan hozzájárulásokat keresünk, amelyek enyhíthetik ezeket a biztonsági megfontolásokat.

   állítsa vissza a futó regisztrációs tokenjét egy projekthez

   Ha úgy gondolja, hogy egy projekt regisztrációs tokenje kiderült, akkor vissza kell állítania. Egy token használható egy másik futó regisztrálására a projekthez. Ezt az új futtatót ezután felhasználhatjuk titkos változók értékeinek megszerzésére vagy a projektkód klónozására.

   a token alaphelyzetbe állítása:

   1. lépjen a projekt beállításaihoz > CI/CD.
   2. bontsa ki az Általános csővezetékek beállításai részt.
   3. keresse meg a futó token űrlapmezőt, majd kattintson az érték felfedése gombra.
   4. törölje az értéket és mentse az űrlapot.
   5. az oldal frissítése után bontsa ki a futók beállításaités ellenőrizze a regisztrációs tokent – meg kell változtatni.

   mostantól a régi token már nem érvényes, és nem regisztrál új futókat a projektbe. Ha bármilyen eszközt használ az új futók biztosításához és regisztrálásához, az ezekben az eszközökben használt tokeneket frissíteni kell, hogy tükrözzék az új token értékét.

   határozza meg a futó IP-címét

   bevezetett GitLab 10.6.

   hasznos lehet tudni egy futó IP-címét, így hibaelhárítást végezhet az adott futóval. A GitLab tárolja és megjeleníti az IP-címet azáltal, hogy megtekinti a Gitlabnak küldött HTTP-kérések forrását a feladatok lekérdezésekor. TheIP cím mindig naprakész, így ha a futó IP megváltoztatja itautomatikusan frissíti GitLab.

   a megosztott Futók és az egyes futók IP-címe különböző helyeken található.

   határozza meg a megosztott futó IP-címét

   a megosztott futó IP-címének megtekintéséhez rendszergazdai hozzáféréssel kell rendelkeznie a GitLab példányhoz. Ennek meghatározásához:

   1. látogasson el az adminisztrációs területre > áttekintés > Futók.
   2. keresse meg a futót a táblázatban, és látnia kell egy oszlopot az IP-címhez.

   

   határozza meg egy adott futó IP-címét

   hogy megtalálja egy futó IP-címét egy adott projekthez,tulajdonosi engedélyekkel kell rendelkeznie a projekthez.

   1. nyissa meg a projekt beállításait > CI/CD és bontsa ki a futók részt.
   2. A részletek oldalon látnia kell egy sort az IP-címhez.

   

   címkékkel korlátozhatja a futó által használt feladatok számát

   be kell állítania egy futót, hogy képes legyen futtatni az összes különböző típusú munkát, amellyel találkozhat a megosztott projektekben. Ez problémát jelentene nagy mennyiségű projekt esetében, ha nem lenne címke.

   a GitLab CI címkék nem azonosak a Git címkékkel. A GitLab CI címkék a futókhoz vannak társítva.Git címkék társított elköveti.

   ha megcímkézi a futót az általa kezelhető feladatok típusaihoz, akkor megbizonyosodhat arról, hogy a megosztott futók csak azokat a munkákat futtatják, amelyekre fel vannak szerelve.

   például a GitLab-nál a rails címkével ellátott futók vannak, ha tartalmazzák a megfelelő függőségeket a Rails tesztkészletek futtatásához.

   amikor regisztrál egy futót, az alapértelmezett viselkedése csak a picktagged jobs.To ha ezt megváltoztatja, rendelkeznie kell a projekt tulajdonosi engedélyeivel.

   ahhoz, hogy egy futó válasszon címkézetlen feladatokat:

   1. nyissa meg a projekt beállításait > CI/CD és bontsa ki a futók részt.
   2. keresse meg azt a futót, akit ki szeretne választani, és ellenőrizze, hogy engedélyezve van-e.
   3. kattintson a ceruza gombra.
   4. jelölje be a címkézetlen feladatok futtatása opciót.
   5. kattintson a Változtatások mentése gombra a módosítások érvénybe lépéséhez.
   megjegyzésa futó címkék listája nem lehet üres, ha nem szabad címkézetlen feladatokat választani.

   Az alábbiakban néhány példa forgatókönyvek különböző variációk.

   a futó csak címkézett feladatokat futtat

   az alábbi példák szemléltetik annak lehetséges hatását, hogy a futó csak címkézett feladatokat futtat.

   1. példa:

   1. a futó úgy van beállítva, hogy csak címkézett feladatokat futtasson, és a docker címkével rendelkezik.
   2. ahello címkével rendelkező feladat végrehajtásra kerül és beragad.

   2. példa:

   1. a futó úgy van beállítva, hogy csak címkézett feladatokat futtasson, és a docker címkével rendelkezik.
   2. a docker címkével rendelkező feladat végrehajtásra és futtatásra kerül.

   3. példa:

   1. a futó csak címkézett feladatok futtatására van konfigurálva, és adocker címkével rendelkezik.
   2. egy olyan feladat, amelynek nincs definiálva címkéje, végrehajtásra kerül és beragad.

   a futónak engedélyezett a címkézetlen feladatok futtatása

   az alábbi példák szemléltetik a futó címkézett és címkézetlen feladatok futtatásának lehetséges hatását.

   1. példa:

   1. a futó címkézetlen feladatok futtatására van konfigurálva, és a docker címkével rendelkezik.
   2. egy olyan feladat kerül végrehajtásra és futtatásra, amely nem tartalmaz címkéket.
   3. a docker címkével definiált második feladat végrehajtásra és futtatásra kerül.

   2. példa:

   1. a futó úgy van konfigurálva, hogy címkézetlen feladatokat futtasson, és nincsenek definiálva címkék.
   2. egy olyan feladat kerül végrehajtásra és futtatásra, amely nem tartalmaz címkéket.
   3. adocker tag definiált második feladat beragadt.

   konfigurálja a futó viselkedését változókkal

   A CI / CD változók segítségével konfigurálhatja a futó Git viselkedésétlobálisan vagy egyedi feladatokhoz:

   • GIT_STRATEGY
   • GIT_SUBMODULE_STRATEGY
   • GIT_CHECKOUT

   GIT_CLEAN_FLAGS

2. GIT_FETCH_EXTRA_FLAGS
3. GIT_DEPTH(sekély klónozás)
4. GIT_CLONE_PATH(custom build libraries)

a változók segítségével beállíthatja, hogy egy futó hányszor kísérelje meg a feladat végrehajtásának bizonyos szakaszait.

Git stratégia

Version history
• bevezetett GitLab 8.9 mint kísérleti funkció.
• GIT_STRATEGY=none szükséges GitLab Runner v1.7+.

beállíthatja a GIT_STRATEGY a tároló tartalmának letöltéséhez használt, akár globálisan, akár feladatonként a variables szakasz:

variables: GIT_STRATEGY: clone

három lehetséges érték létezik: clonefetch, és none. Ha nincs megadva, a feladatok a projekt folyamatbeállítását használják.

clone A leglassabb lehetőség. Ez klónozza az adattár a semmiből everyjob, biztosítva, hogy a helyi munkapéldány mindig érintetlen.Ha egy meglévő worktree megtalálható, akkor a klónozás előtt eltávolítják.

fetchgyorsabb, mivel újra felhasználja a helyi munkapéldányt (visszaesik a clone értékre, ha nem létezik). git cleanaz utolsó feladat által végrehajtott módosítások visszavonására szolgál, a git fetch pedig az utolsó feladat futtatása után végrehajtott kötelezettségvállalások lekérésére szolgál.

azonban a fetch hozzáférést igényel az előző munkafához. Ez akkor működik jól, ha a shell vagy docker végrehajtót használja, mert ezekpróbálja meg megőrizni a munka fákat, és alapértelmezés szerint megpróbálja újra használni őket.

ennek korlátai vannak a Docker Machine executor használatakor.

nem működik a kubernetes végrehajtónál,de létezik egy funkciójavaslat.Akubernetes végrehajtó mindig ideiglenes könyvtárba klónoz.

a none Git stratégiája a helyi munkapéldányt is újra felhasználja, de kihagyja az összes Gitműveletet, amelyet általában a GitLab végez. GitLab Runner pre-klón szkriptek is kimarad,ha van. Ez a stratégia azt jelentheti, hogy hozzá kell adnia a fetch és a checkout parancsokat a .gitlab-ci.yml parancsfájlhoz.

használható olyan feladatokhoz, amelyek kizárólag melléktermékeken működnek, például telepítési feladatokhoz.A Git adattár adatai jelen lehetnek, de valószínűleg elavultak. Csak meg kelltámaszkodjon a gyorsítótárból vagy tárgyakból a helyi munkapéldányba hozott fájlokra.

Git submodule stratégia

Gitlab Runner v1.10+Szükséges.

a GIT_SUBMODULE_STRATEGY változó annak szabályozására szolgál, hogy a Gitsubmodules / hogyan kerül beépítésre a kód lekérésekor egy build előtt. Beállíthatja őket globálisan vagy feladatonként a variables szakaszban.

három lehetséges érték létezik: nonenormal, and recursive:

• none azt jelenti, hogy az almodulok nem szerepelnek a Projektkód lekérésekor. Ez az alapértelmezett, amely megfelel a v1.10 előtti viselkedésnek.

• normal azt jelenti, hogy csak a legfelső szintű almodulok szerepelnek. Ez egyenértékű a következővel:

  git submodule syncgit submodule update --init

• recursive azt jelenti, hogy az összes részmodul (beleértve az almodulokat is)benne van. Ehhez a szolgáltatáshoz Git v1.8.1 vagy újabb verzióra van szükség. Ha az aGitLab Runnert olyan végrehajtóval használja, amely nem Docker alapú, ellenőrizze, hogy a Git verzió megfelel-e ennek a követelménynek. Ez egyenértékű:

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

ahhoz, hogy ez a funkció megfelelően működjön, az almodulokat be kell állítani (.gitmodules) a következőkkel:

• egy nyilvánosan hozzáférhető adattár HTTP(S) URL-je, vagy
• relatív elérési út egy másik adattárhoz ugyanazon a GitLab szerveren. Lásd theGit submodules dokumentáció.

Git checkout

a GIT_CHECKOUT változó akkor használható, ha a GIT_STRATEGY értéke vagyclone vagy fetch annak megadásához, hogy egy git checkout kell futtatni. Ha nincs megadva, akkor alapértelmezés szerint igaz. Ezeket globálisan vagy feladatonként beállíthatja avariables szakaszban.

ha false értékre van állítva, a futó:

• fetch – frissíti az adattárat, és a munkapéldányt az aktuális verzióra hagyja,
• clone – klónozza az adattárat, és a munkapéldányt az alapértelmezett ágon hagyja.

Ha a GIT_CHECKOUTértéke true, akkor mind a clone, mind a fetch ugyanúgy működik.A futó ellenőrzi a CI csővezetékhez kapcsolódó felülvizsgálat munkapéldányát:

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

Git clean flags

a GIT_CLEAN_FLAGS változó aGIT_CLEAN_FLAGS változó a git clean a források ellenőrzése után. Beállíthatja globálisan vagy feladatonként avariables szakaszban.

GIT_CLEAN_FLAGSelfogadja a git clean parancs összes lehetséges lehetőségét.

git cleanle van tiltva, ha a GIT_CHECKOUT: "false" meg van adva.

If GIT_CLEAN_FLAGS van:

• nincs megadva,git cleanalapértelmezett zászlók-ffdx.
• adott érték nonegit clean nem kerül végrehajtásra.

például:

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

Git fetch extra zászlók

a GIT_FETCH_EXTRA_FLAGSváltozó agit fetch viselkedésének szabályozására szolgál. Beállíthatja globálisan vagy feladatonként a variables szakaszban.

GIT_FETCH_EXTRA_FLAGSelfogadja a git fetch parancs összes opcióját. Azonban a GIT_FETCH_EXTRA_FLAGS zászlók az alapértelmezett zászlók után kerülnek hozzáadásra, amelyeket nem lehet módosítani.

Az alapértelmezett zászlók:

• GIT_DEPTH.
• a refspecs listája.
• egy távoli nevűorigin.

If GIT_FETCH_EXTRA_FLAGS is:

• nincs megadva, git fetchflags default to --prune --quiet az alapértelmezett zászlókkal együtt.
• adott érték nonegit fetch csak az alapértelmezett zászlókkal kerül végrehajtásra.

például az alapértelmezett zászlók --prune --quiet, így lehet, hogy git fetch több részletes felülírásával ezt csak --prune:

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

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

variables: GIT_DEPTH: "3"

globálisan vagy feladatonként beállíthatja avariables szakaszban.

egyéni build könyvtárak

alapértelmezés szerint a GitLab Runner a$CI_BUILDS_DIR könyvtár egyedi alútjában klónozza a tárolót. A projekthez azonban szükség lehet a kódra aspecifikus könyvtárban (például Go projektek). Ebben az esetben megadhatjaaGIT_CLONE_PATH változó, hogy megmondja a futónak a könyvtárat, hogy klónozza a könyvtárat:

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

a GIT_CLONE_PATHmindig belül kell lennie $CI_BUILDS_DIR. A $CI_BUILDS_DIRkönyvtár a végrehajtótól és a futók konfigurációjától függ.builds_dirsetting.

Ez csak akkor használható, ha a custom_build_dir engedélyezve van a futtató konfigurációjában.Ez a docker és kubernetes végrehajtók alapértelmezett konfigurációja.

egyidejűség kezelése

a1 – nél nagyobb egyidejűséget használó végrehajtó hibákhoz vezethet. Több feladat is működhet ugyanazon a könyvtáron, ha abuilds_dirmeg van osztva a feladatok között.

a futó nem próbálja megakadályozni ezt a helyzetet. Ez akár a administratorand fejlesztők, hogy megfeleljenek a követelményeknek futó konfiguráció.

ennek a forgatókönyvnek a elkerülése érdekében használhat egy egyedi elérési utat a $CI_BUILDS_DIR belül, mert a runnerexposes két további változót biztosít, amelyek egyedi ID a párhuzamosság:

• $CI_CONCURRENT_ID: egyedi azonosító az összes, a adott végrehajtó.
• $CI_CONCURRENT_PROJECT_ID: egyedi azonosító az adott végrehajtón és projekten belül futó összes feladathoz.

a legstabilabb konfiguráció, amely jól működik minden forgatókönyvben és bármely végrehajtón, a $CI_CONCURRENT_IDhasználatához a GIT_CLONE_PATH alatt. Például:

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

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

variables: GET_SOURCES_ATTEMPTS: 3

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"