• tipuri de alergători
  • alergători partajate
    • cum alergători partajate alege locuri de muncă
    • activați alergători partajate
    • dezactivați alergători partajate
  • alergători de grup
    • creați un alergător grup
    • Vizualizați și gestionați alergători de grup
    • alergător de grup
  • alergători specifici
    • creați un alergător specific
    • activați un alergător specific pentru un anumit proiect
    • împiedicați activarea unui alergător specific pentru alte proiecte
• ștergeți manual memoria cache a alergătorului
• setați timeout-ul maxim de lucru pentru un alergător
• aveți grijă cu informațiile sensibile
  • împiedicați alergătorii să dezvăluie informații sensibile
  • furci
  • vectori de atac în alergători
  • Resetați jetonul de înregistrare a alergătorului pentru un proiect
• determinați adresa IP a unui alergător
  • determinați adresa IP a unui alergător partajat
  • determinați adresa IP a unui anumit alergător
• utilizați etichete pentru a limita numărul de joburi folosind alergătorul
  • alergătorul rulează numai joburi etichetate
  • runner este permis să ruleze locuri de muncă netichetate
• configurați comportamentul alergător cu variabile
  • strategie Git
  • strategie submodule Git
  • git checkout
  • git steaguri curate
  • git fetch steaguri suplimentare
  • clonare superficială
  • directoare personalizate construi
    • manipularea concurenței
    • căi
  • etape de locuri de muncă încercări
• apeluri de sistem nu este disponibil pe GitLab.com runners partajate
• artefact și cache Setări

în GitLab CI/CD, runners rula codul definit în.gitlab-ci.yml.Un alergător este un agent ușor, foarte scalabil, care preia o lucrare CI prin API-ul coordonator al GitLab CI/CD, execută lucrarea și trimite rezultatul înapoi la instanța GitLab.

alergătorii sunt creați de un administrator și sunt vizibili în interfața de Utilizare GitLab.Alergătorii pot fi specifici anumitor proiecte sau disponibili pentru toate proiectele.

această documentație este axată pe utilizarea alergătorilor în GitLab.Dacă trebuie să instalați și să configurați Gitlab Runner, consultați documentația Gitlab Runner.

tipuri de alergători

în interfața de utilizare GitLab există trei tipuri de alergători, în funcție de cine doriți să aveți acces:

• alergătorii Partajați sunt disponibili pentru toate grupurile și proiectele dintr-o instanță GitLab.
• alergătorii de grup sunt disponibili pentru toate proiectele și subgrupurile dintr-un grup.
• alergătorii specifici sunt asociați cu proiecte specifice.De obicei, alergătorii specifici sunt folosiți pentru un proiect la un moment dat.

alergători partajate

alergători partajate sunt disponibile pentru fiecare proiect într-o instanță GitLab.

utilizați alergători partajate atunci când aveți mai multe locuri de muncă cu cerințe similare. Mai degrabă decâtavând mai mulți alergători la ralanti pentru multe proiecte, puteți avea câțiva alergători care manipuleazăproiecte multiple.

dacă utilizați o instanță autogestionată a GitLab:

• administratorul dvs. poate instala și înregistra alergători partajați accesând setările proiectului> CI / CD, extinzând secțiunea alergători și făcând clic pe Afișați instrucțiunile de instalare a alergătorului.Aceste instrucțiuni sunt disponibile și în documentație.
• administratorul poate configura, de asemenea, un număr maxim de minute comune de conducte runner forefiecare grup.

dacă utilizați GitLab.com:

• puteți selecta dintr-o listă de alergători partajate pe care GitLab menține.
• alergătorii partajate consuma conductele minutesinclused cu contul dvs.

cum aleg alergătorii comuni joburi

alergătorii comuni procesează joburi folosind o coadă de utilizare corectă. Această coadă împiedică proiectele să creeze sute de locuri de muncă și să utilizeze toate resursele disponibile pentru alergători.

algoritmul cozii de utilizare corectă atribuie locuri de muncă pe baza proiectelor care au cel mai mic număr de locuri de muncă care rulează deja pe alergători partajate.

Exemplul 1

dacă aceste joburi sunt în coadă:

• Job 1 pentru proiectul 1
• Job 2 pentru proiectul 1
• Job 3 pentru proiectul 1
• Job 4 pentru proiectul 2
• Job 5 pentru proiectul 2
• Job 6 pentru proiectul 3

algoritmul de utilizare corectă atribuie Joburi în această ordine:

1. Job 1 este ales mai întâi, deoarece are cel mai mic număr de joburi din proiecte fără joburi care rulează (adică toate proiectele).
2. Locul de muncă 4 este următorul, deoarece 4 este acum cel mai mic număr de locuri de muncă din proiecte fără locuri de muncă în desfășurare (Proiectul 1 are un loc de muncă în desfășurare).
3. Locul de muncă 6 este următorul, deoarece 6 este acum cel mai mic număr de locuri de muncă din proiectele fără locuri de muncă în desfășurare (proiectele 1 și 2 au locuri de muncă în desfășurare).
4. Job 2 este următorul, deoarece, din proiectele cu cel mai mic număr de locuri de muncă care rulează (fiecare are 1), este cel mai mic număr de locuri de muncă.
5. Job 5 este următorul, deoarece proiectul 1 are acum 2 locuri de muncă în desfășurare și Job 5 este cel mai mic număr de locuri de muncă rămase între proiectele 2 și 3.
6. în cele din urmă este de locuri de muncă 3… pentru că este singurul loc de muncă stânga.

Exemplul 2

dacă aceste joburi sunt în coadă:

• Job 1 pentru proiectul 1
• Job 2 pentru proiectul 1
• Job 3 pentru proiectul 1
• Job 4 pentru proiectul 2
• Job 5 pentru proiectul 2
• Job 6 pentru proiectul 3

algoritmul de utilizare corectă atribuie Joburi în această ordine:

1. jobul 1 este ales primul, deoarece are cel mai mic număr de joburi din proiecte fără joburi rulante (adică toate proiectele).
2. terminăm treaba 1.
3. Job 2 este următorul, deoarece, după ce a terminat Job 1, toate proiectele au 0 locuri de muncă care rulează din nou, iar 2 este cel mai mic număr de locuri de muncă disponibile.
4. Locul de muncă 4 este următorul, deoarece cu Proiectul 1 care rulează un loc de muncă, 4 este cel mai mic număr din proiectele care nu rulează niciun loc de muncă (proiectele 2 și 3).
5. terminăm treaba 4.
6. Job 5 este următorul, deoarece după ce a terminat Job 4, Project 2 nu are joburi care rulează din nou.
7. Job 6 este următorul, deoarece proiectul 3 este singurul proiect rămas fără locuri de muncă care rulează.
8. în cele din urmă alegem Job 3… pentru că, din nou, este singurul loc de muncă rămas.

activați alergători partajate

pe GitLab.com, runners partajate sunt activate în toate proiectele bydefault.

în instanțele autogestionate ale GitLab, un administrator trebuie să le instaleze și să le înregistreze.

puteți activa, de asemenea, alergători partajate pentru proiecte individuale.

pentru a activa runners partajate:

1. mergeți la setările proiectului> CI / CD și extindeți secțiunea Runners.
2. selectați Activați alergători partajate pentru acest proiect.

Disable shared runners

puteți dezactiva runners partajate pentru proiecte individuale sau pentru grupuri.Trebuie să aveți permisiuni de proprietar pentru proiect sau grup.

pentru a dezactiva alergătorii partajați pentru un proiect:

1. accesați setările proiectului> CI / CD și extindeți secțiunea alergători.
2. în zona Shared runners, selectați Enable shared runners pentru acest proiect, astfel încât comutarea să fie estompată.

alergătorii Partajați sunt dezactivați automat pentru un proiect:

• Dacă setarea alergătorilor partajați pentru grupul părinte este dezactivată și
• dacă suprascrierea acestei setări nu este permisă la nivel de proiect.

pentru a dezactiva alergătorii partajați pentru un grup:

1. accesați setările grupului> CI / CD și extindeți secțiunea alergători.
2. în zona runners partajat, dezactivați comutarea activare runners partajat pentru acest grup.
3. opțional, pentru a permite activarea alergătorilor partajați pentru proiecte sau subgrupuri individuale,faceți clic pe Permiteți proiecte și subgrupuri pentru a suprascrie setarea de grup.

alergători de grup

folosiți alergători de grup atunci când doriți ca toate proiectele dintr-un grup să aibă acces la un set de alergători.

alergătorii de grup procesează joburile folosind o coadă first in, first out (FIFO).

crearea unui alergător de grup

puteți crea un alergător de grup pentru instanța GitLab autogestionată sau pentru GitLab.com.trebuie să aveți permisiuni de proprietar pentru grup.

pentru a crea un alergător de grup:

1. instalați Gitlab Runner.
2. mergeți la grupul pentru care doriți să lucrați alergătorul.
3. accesați Setări> CI / CD și extindeți secțiunea alergători.
4. notați adresa URL și jetonul.
5. înregistrați alergătorul.

Vizualizați și gestionați alergătorii de grup

puteți vizualiza și gestiona toți alergătorii pentru un grup, subgrupurile sale și proiectele.Puteți face acest lucru pentru instanța GitLab autogestionată sau pentru GitLab.com.trebuie să aveți permisiuni de proprietar pentru grup.

1. mergeți la grupul în care doriți să vizualizați alergătorii.
2. accesați Setări> CI / CD și extindeți secțiunea alergători.

3. sunt afișate următoarele câmpuri.

   atribut	descriere
   Tip	una sau mai multe dintre următoarele stări: shared, group, specific, locked sau paused
   Runner token	Token folosit pentru a identifica alergătorul și pe care alergătorul îl folosește pentru a comunica cu instanța GitLab
   descriere	Descriere dată alergătorului când a fost creat
   Versiune	Gitlab Runner versiunea
   adresa IP	adresa IP a gazdei pe care este înregistrat alergătorul
   proiecte	numărul de proiecte cărora le este atribuit alergătorul
   locuri de muncă	total de locuri de muncă conduse de alergător
   Tag-uri	Tag-uri asociate cu alergătorul
   ultimul contact	Timestamp care indică când instanța GitLab a contactat ultima dată alergătorul

din această pagină, puteți edita, întrerupe și elimina alergătorii din grup, din subgrupurile sale și din proiecte.

întrerupeți sau eliminați un alergător de grup

Puteți întrerupe sau elimina un alergător de grup pentru instanța GitLab autogestionată sau pentru GitLab.com.trebuie să aveți permisiuni de proprietar pentru grup.

1. mergeți la grupul pentru care doriți să eliminați sau să întrerupeți alergătorul.
2. accesați Setări> CI / CD și extindeți secțiunea alergători.
3. Faceți clic pe pauză sau eliminați runner.
   • dacă întrerupeți un alergător de grup care este utilizat de mai multe proiecte, alergătorul se oprește pentru toate proiectele.
   • din vizualizarea grup, nu puteți elimina un alergător care este atribuit mai multor proiecte.Trebuie să îl eliminați mai întâi din fiecare proiect.
4. în dialogul de confirmare, faceți clic pe OK.

alergători specifici

utilizați alergători specifici atunci când doriți să utilizați alergători pentru proiecte specifice. De exemplu, atunci când aveți:

• locuri de muncă cu cerințe specifice, cum ar fi un loc de muncă deploy care necesită acreditări.
• proiecte cu multă activitate CI care pot beneficia de a fi separate de alți alergători.

puteți configura un alergător specific pentru a fi utilizat de mai multe proiecte. Runners specifice trebuie să fie activat pentru fiecare proiect în mod explicit.

alergătorii specifici procesează joburi folosind o coadă first in, first out (FIFO).

creați un alergător specific

puteți crea un alergător specific pentru instanța GitLab autogestionată sau pentru GitLab.com.trebuie să aveți permisiuni de proprietar pentru proiect.

pentru a crea un alergător specific:

1. Install runner.
2. accesați setările proiectului> CI / CD și extindeți secțiunea Runners.
3. notați adresa URL și jetonul.
4. înregistrați alergătorul.

activați un alergător specific pentru un anumit proiect

un alergător specific este disponibil în proiectul pentru care a fost creat. Un administrator poate activa un anumit alergător pentru a aplica la proiecte suplimentare.

• trebuie să aveți permisiuni de proprietar pentru proiect.
• alergătorul specific nu trebuie blocat.

pentru a activa sau dezactiva un anumit alergător pentru un proiect:

1. accesați setările proiectului> CI / CD și extindeți secțiunea alergători.
2. Faceți clic pe Activare pentru acest proiect sau dezactivare pentru acest proiect.

împiedicați activarea unui anumit alergător pentru alte proiecte

puteți configura un anumit alergător astfel încât să fie „blocat” și să nu poată fi activat pentru alte proiecte.Această setare poate fi activată la prima înregistrare a unui alergător, dar poate fi modificată și ulterior.

pentru a bloca sau debloca un alergător:

1. accesați setările proiectului> CI / CD și extindeți secțiunea alergători.
2. găsiți alergătorul pe care doriți să îl blocați sau să îl deblocați. Asigurați-vă că este activat.
3. Faceți clic pe butonul Creion.
4. verificați opțiunea Blocare la proiecte curente.
5. Faceți clic pe Salvare modificări.

ștergeți manual memoria cache a alergătorului

citiți ștergerea memoriei cache.

setarea timeout-ului maxim al lucrării pentru un alergător

pentru fiecare alergător, puteți specifica un timeout maxim al lucrării. Acest timeout, dacă este mai mic decât timeout-ul definit de proiect, are prioritate.

această caracteristică poate fi utilizată pentru a împiedica alergătorul dvs. partajat să fie copleșit de un proiect care are locuri de muncă cu o perioadă lungă de timp (de exemplu, o săptămână).

când nu este configurat, alergători nu suprascrie timeout proiect.

pe GitLab.com, nu puteți suprascrie timeout de locuri de muncă pentru alergători partajate și trebuie să utilizeze timeout proiect definit.

pentru a seta timeout-ul maxim al lucrării:

1. într-un proiect, accesați Setări > CI/CD > alergători.
2. selectați alergătorul dvs. specific pentru a edita setările.
3. introduceți o valoare sub timeout maxim de lucru.
4. selectați Salvare modificări.

cum funcționează această caracteristică:

exemplu 1 – Timeout Runner mai mare decât timeout proiect

1. setați timeout maxim de locuri de muncă pentru un alergător la 24 de ore
2. setați Timeout CI/CD pentru un proiect la 2 ore
3. începe un loc de muncă
4. de locuri de muncă, în cazul în care rulează mai mult, ori după 2 ore

exemplu 2 – Timeout Runner configurare timeout de locuri de muncă de la un alergător

exemplu 3 – Runner timeout mai mic decât timeout proiect

1. setați timeout maxim de locuri de muncă pentru un alergător la 30 de minute
2. setați Timeout CI/CD pentru un proiect la 2 ore
3. începe un loc de muncă
4. de locuri de muncă, în cazul în care rulează mai mult, ori după 30 de minute

fii atent cu informații sensibile

cu unele executori alergător,dacă puteți rula un loc de muncă obțineți acces complet la sistemul de fișiere și, astfel,orice cod pe care îl rulează, precum și simbolul alergătorului. Cu runners partajate, acest lucru înseamnă că oricinecare rulează locuri de muncă pe alergător, poate accesa codul altcuiva care rulează pe therunner.

în plus, pentru că puteți obține acces la jetonul runner, este posibilpentru a crea o clonă a unui alergător și a trimite locuri de muncă false, de exemplu.

cele de mai sus sunt ușor evitate prin restricționarea utilizării runnerson-urilor publice mari instanțe GitLab, controlul accesului la instanța dvs. GitLab și utilizarea Executorilor de alergători mai siguri.

împiedicați alergătorii să dezvăluie informații sensibile

puteți proteja alergătorii astfel încât să nu dezvăluie informații sensibile.Atunci când un alergător este protejat, alergătorul alege locuri de muncă create pe ramuri protejate sau etichete protejate numai,și ignoră alte locuri de muncă.

pentru a proteja sau a proteja un alergător:

1. accesați setările proiectului> CI / CD și extindeți secțiunea alergători.
2. găsiți alergătorul pe care doriți să îl protejați sau să îl protejați. Asigurați-vă că este activat.
3. Faceți clic pe butonul Creion.
4. verificați opțiunea protejat.
5. Faceți clic pe Salvare modificări.

furci

ori de câte ori un proiect este bifurcat, Copiază setările de locuri de muncă care relateto. Acest lucru înseamnă că, dacă ați partajat alergători înființat pentru un proiect șicineva forks acel proiect, alergători partajate servi locuri de muncă ale acestui proiect.

vectori de atac în alergători

menționat Pe scurt mai devreme, dar următoarele lucruri de alergători pot fi exploatate.Căutăm mereu contribuții care pot atenua aceste considerente de securitate.

Resetați jetonul de înregistrare runner pentru un proiect

dacă credeți că a fost dezvăluit un jeton de înregistrare pentru un proiect, ar trebui să îl resetați. Un jeton poate fi folosit pentru a înregistra un alt alergător pentru proiect. Această nouă rulare poate fi apoi utilizată pentru a obține valorile variabilelor secrete sau pentru a clona codul proiectului.

pentru a reseta tokenul:

1. accesați setările proiectului> CI / CD.
2. extindeți secțiunea Setări conducte generale.
3. găsiți câmpul Formular Runner token și faceți clic pe butonul Reveal value.
4. ștergeți valoarea și salvați formularul.
5. după ce pagina este reîmprospătată, extindeți secțiunea Setări Alergătoriși verificați tokenul de înregistrare-ar trebui schimbat.

de acum înainte vechiul jeton nu mai este valabil și nu se înregistreazăorice alergători noi la proiect. Dacă utilizați orice instrumente pentru furnizarea și înregistrarea de noi alergători, jetoanele utilizate în aceste instrumente ar trebui actualizate pentru a reflecta valoarea noului jeton.

determinați adresa IP a unui alergător

poate fi util să cunoașteți adresa IP a unui alergător, astfel încât să puteți depana probleme cu acel alergător. GitLab stochează și afișează adresa IP vizualizândsursa cererilor HTTP pe care le face către GitLab atunci când sondează pentru locuri de muncă. Adresa IP este întotdeauna actualizată, deci dacă IP-ul alergătorului îl schimbăactualizări automate în GitLab.

adresa IP pentru alergători partajate și alergători specifice pot fi găsite în locuri diferite.

determinați adresa IP a unui alergător partajat

pentru a vizualiza adresa IP a unui alergător partajat, trebuie să aveți acces de administrator la instanța GitLab. Pentru a determina acest lucru:

1. vizitați zona de administrare > Prezentare generală > alergători.
2. căutați alergătorul în tabel și ar trebui să vedeți o coloană pentru adresa IP.

determinați adresa IP a unui alergător specific

pentru a putea găsi adresa IP a unui alergător pentru un anumit proiect,trebuie să aveți permisiuni de proprietar pentru proiect.

1. accesați setările proiectului> CI / CD și extindeți secțiunea Runners.
2. pe pagina de detalii ar trebui să vedeți un rând pentru adresa IP.

utilizați etichete pentru a limita numărul de joburi folosind alergătorul

trebuie să configurați un alergător pentru a putea rula toate tipurile diferite de joburi pe care le poate întâlni în proiectele pe care le-a distribuit. Acest lucru ar fiproblematic pentru cantități mari de proiecte, dacă nu ar fi etichete.

etichetele GitLab CI nu sunt aceleași cu etichetele Git. Etichetele GitLab CI sunt asociate cu alergătorii.Etichetele Git sunt asociate cu comiteri.

etichetând un alergător pentru tipurile de lucrări pe care le poate gestiona, puteți să vă asigurați că alergătorii împărțiți vor rula doar lucrările pe care sunt echipate să le ruleze.

de exemplu, la GitLab avem alergători etichetați curails dacă conțin dependențele adecvate pentru a rula suitele de testare a șinelor.

când înregistrați un alergător, comportamentul său implicit este de a picktagged numai jobs.To modificați acest lucru, trebuie să aveți permisiuni de proprietar pentru proiect.

pentru a face un alergător alege locuri de muncă neetichetate:

1. accesați setările proiectului> CI / CD și extindeți secțiunea Runners.
2. găsiți alergătorul pe care doriți să-l alegeți și asigurați-vă că este activat.
3. Faceți clic pe butonul Creion.
4. verificați opțiunea Run untagged jobs.
5. Faceți clic pe butonul Salvați modificările pentru ca modificările să aibă efect.

mai jos sunt câteva exemple de scenarii ale diferitelor variații.

runner rulează numai locuri de muncă etichetate

următoarele exemple ilustrează impactul potențial al alergătorului fiind setto rula numai locuri de muncă etichetate.

Exemplul 1:

1. alergătorul este configurat să ruleze numai joburi etichetate și are etichetadocker.
2. un loc de muncă care are unhello tag-ul este executat și blocat.

Exemplul 2:

1. alergătorul este configurat să ruleze numai joburi etichetate și are etichetadocker.
2. un loc de muncă care are undocker tag-ul este executat și a alerga.

Exemplul 3:

1. alergătorul este configurat să ruleze numai joburi etichetate și are etichetadocker.
2. un loc de muncă care nu are tag-uri definite este executat și blocat.

runner este permis să ruleze locuri de muncă neetichetate

următoarele exemple ilustrează impactul potențial al alergător fiind setto rula etichetate și locuri de muncă neetichetate.

Exemplul 1:

1. alergătorul este configurat să ruleze lucrări neetichetate și are etichetadocker.
2. o lucrare care nu are etichete definite este executată și executată.
3. un al doilea job care are un docker tag definit este executat și executat.

Exemplul 2:

1. alergătorul este configurat pentru a rula lucrări neetichetate și nu are etichete definite.
2. o lucrare care nu are etichete definite este executată și executată.
3. un al doilea loc de muncă care are un docker tag-ul definit este blocat.

configurați comportamentul alergătorului cu variabile

puteți utiliza variabile CI/CD pentru a configura comportamentul alergătorului gitlobal sau pentru lucrări individuale:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (clonare superficială)
• GIT_CLONE_PATH (directoare de construire personalizate)

de asemenea, puteți utiliza variabile pentru a configura de câte ori un alergătorîncearcă anumite etape de execuție a lucrării.

strategia Git

puteți seta GIT_STRATEGY folosit pentru a prelua conținutul depozitului, fie la nivel global, fie per-job în secțiunea variables:

variables: GIT_STRATEGY: clone

există trei valori posibile: clonefetch și none. Dacă sunt lăsate nespecificate,lucrările utilizează setarea conductei proiectului.

clone este cea mai lentă opțiune. Clonează depozitul de la zero pentru fiecarelucru, asigurându-se că copia locală de lucru este întotdeauna curată.Dacă se găsește un arbore de lucru existent, acesta este eliminat înainte de clonare.

fetch este mai rapid deoarece reutilizează copia de lucru locală (revenind laclonedacă nu există). git cleaneste folosit pentru a anula orice modificări făcute de lastjob, șigit fetch este folosit pentru a prelua comiterile făcute după ultima lucrare rulată.

cu toate acestea,fetch necesită acces la arborele de lucru anterior. Acest workswell atunci când se utilizeazăshell saudocker executor deoarece thesîncercați să păstrați worktrees și să încerce să le reutilizeze în mod implicit.

Acest lucru are limitări atunci când se utilizează Docker machine executor.

nu funcționează pentrukubernetes executor,dar există o propunere caracteristică.kubernetes executorul clonează întotdeauna într-un director temporar.

o strategie Git denone reutilizează și copia de lucru locală, dar omite toate Gitoperațiile efectuate în mod normal de GitLab. Scripturile GitLab Runner pre-clone sunt,de asemenea, omise, dacă sunt prezente. Această strategie ar putea însemna că trebuie să adăugațifetch șicheckout comandăla.gitlab-ci.yml script.

poate fi folosit pentru lucrări care funcționează exclusiv pe artefacte, cum ar fi o lucrare de implementare.Datele depozitului Git pot fi prezente, dar probabil că sunt depășite. Ar trebui doarse bazează pe fișierele aduse în copia de lucru locală din cache sau artefacte.

strategia submodulului Git

necesită Gitlab Runner v1.10+.

variabilaGIT_SUBMODULE_STRATEGY este utilizată pentru a controla dacă / cum sunt incluse Gitsubmodules la preluarea codului înainte de o compilare. Puteți să le setațiglobal sau per-job în secțiunea variables.

există trei valori posibile: nonenormal și recursive:

• none înseamnă că submodulele sunt nu sunt incluse la preluarea projectcode. Aceasta este valoarea implicită, care se potrivește cu comportamentul pre-v1.10.

• normal înseamnă că sunt incluse numai submodulele de nivel superior. Este echivalent cu:

  git submodule syncgit submodule update --init

• recursive înseamnă că sunt incluse toate submodulele (inclusiv submodulele submodulelor). Această caracteristică are nevoie de Git v1.8. 1 și mai târziu. Când utilizați aGitLab Runner cu un executor care nu se bazează pe Docker, asigurați-vă că versiunea Git îndeplinește această cerință. Este echivalent cu:

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

pentru ca această caracteristică să funcționeze corect, submodulele trebuie configurate(în .gitmodules) cu:

• URL-ul HTTP al unui depozit accesibil publicului sau
• o cale relativă la un alt depozit pe același server GitLab. A se vedeadocumentația submodulelor git.

Git checkout

GIT_CHECKOUT variabila poate fi utilizată atunci când GIT_STRATEGY este setat fieclone sau fetch pentru a specifica dacă un git checkout ar trebui să fie rulat. Dacă notspecified, implicit la true. Puteți să le setați global sau per-job în secțiuneavariables.

dacă este setat la false, alergătorul:

• când facețifetch – actualizează depozitul și lasă copia de lucru pe revizuirea curentă,
• când facețiclone – clonează depozitul și lasă copia de lucru pe ramura implicită.

dacăGIT_CHECKOUT este setat latrue, ambeleclone șifetch funcționează în același mod.Alergătorul verifică copia de lucru a unei revizuiri legate de conducta CI:

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

git steaguri curate

GIT_CLEAN_FLAGS variabila este utilizată pentru a controla comportamentul implicit algit clean după verificarea surselor. Puteți să o setați global sau per-job în secțiunea variables.

GIT_CLEAN_FLAGS acceptă toate opțiunile posibile ale comenziigit clean.

git clean este dezactivat dacăGIT_CHECKOUT: "false" este specificat.

dacă GIT_CLEAN_FLAGS este:

• nespecificat,git clean steaguri implicit la-ffdx.
• având în vedere valoareanonegit clean nu este executată.

de exemplu:

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

git aduce steaguri suplimentare

variabilaGIT_FETCH_EXTRA_FLAGS este utilizată pentru a controla comportamentulgit fetch. Puteți să o setați global sau per-job în secțiunea variables.

GIT_FETCH_EXTRA_FLAGS acceptă toate opțiunile comenziigit fetch. Cu toate acestea,GIT_FETCH_EXTRA_FLAGS steagurile sunt adăugate după steagurile implicite care nu pot fi modificate.

steagurile implicite sunt:

• GIT_DEPTH.
• lista de refspecs.
• o telecomandă numităorigin.

dacăGIT_FETCH_EXTRA_FLAGS este:

• nu este specificat,git fetch steaguri implicite la--prune --quiet împreună cu steagurile implicite.
• având în vedere valoareanonegit fetch se execută numai cu steagurile implicite.

de exemplu, steagurile implicite sunt --prune --quiet, astfel încât să puteți face git fetch mai detaliat prin suprascrierea acest lucru cu doar --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

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"