• Soorten lopers
  • Gedeelde lopers
    • Hoe gedeelde lopers halen banen
    • Inschakelen gedeelde lopers
    • Uitschakelen gedeelde lopers
  • Groep lopers
    • Maken van een groep runner
    • Bekijk en beheer groep lopers
    • Pauzeren of verwijderen van een groep runner
  • het Specifieke lopers
    • het Maken van een specifieke runner
    • stel een specifieke loper voor een specifiek project
    • het Voorkomen van een specifieke loper worden ingeschakeld voor andere projecten
• Handmatig wissen van de runner-cache
• maximum time-out taak voor een loper
• Wees voorzichtig met gevoelige informatie
  • het Voorkomen van de lopers uit het onthullen van gevoelige informatie
  • Vorken
  • Aanval vectoren in runners
  • Reset de loper registratie token voor een project
• Bepaal het IP-adres van een runner
  • Bepaal het IP-adres van een gedeelde runner
  • Bepaal het IP-adres van een specifieke runner
• tags Gebruiken om het beperken van het aantal banen met behulp van de runner
  • loper loopt alleen tagged banen
  • runner is toegestaan voor het uitvoeren van niet-gelabelde banen
• Configureren runner gedrag met variabelen
  • Git-strategie
  • Git submodule strategie
  • Git checkout
  • Git schoon flags
  • Git fetch extra flags
  • Ondiep klonen
  • bouwen van Aangepaste mappen
    • Omgaan gelijktijdigheid
    • Geneste paden
  • Werk fasen pogingen
• Systeem oproepen niet beschikbaar op GitLab.com gedeelde lopers
• Artefact en cache-instellingen

In GitLab CI/CD, lopers lopen de code gedefinieerd in .gitlab-ci.yml.Een runner is een lichtgewicht, zeer schaalbare agent die een CI-taak opneemt via de coördinator API van GitLab CI / CD, de taak uitvoert en het resultaat terugstuurt naar de GitLab-instantie.

Runners worden aangemaakt door een beheerder en zijn zichtbaar in de GitLab UI.Runners kunnen specifiek zijn voor bepaalde projecten of beschikbaar zijn voor alle projecten.

Deze documentatie is gericht op het gebruik van runners in GitLab.Als je GitLab Runner moet installeren en configureren, zie dan de GitLab Runner documentatie.

typen runners

in de GitLab UI zijn er drie typen runners, gebaseerd op wie u toegang wilt hebben:

• gedeelde runners zijn beschikbaar voor alle groepen en projecten in een GitLab-instantie.
• groepsrunners zijn beschikbaar voor alle projecten en subgroepen in een groep.
• specifieke lopers worden geassocieerd met specifieke projecten.Meestal worden specifieke lopers gebruikt voor één project per keer.

gedeelde hardlopers

gedeelde hardlopers zijn beschikbaar voor elk project in een GitLab-instantie.

gebruik gedeelde runners wanneer u meerdere taken met vergelijkbare vereisten hebt. In plaats van het hebben van meerdere lopers stationair voor vele projecten, kunt u een paar lopers die handlemultiple projecten.

Als u een zelf beheerde instantie van GitLab:

• gebruikt, kan uw beheerder gedeelde runners installeren en registreren door naar de instellingen van uw project te gaan > CI/CD,de Runners sectie uit te breiden en te klikken op Runner installatie-instructies tonen.Deze instructies zijn ook beschikbaar in de documentatie.
• de beheerder kan ook een maximum aantal gedeelde Runner-pijplijn minuten configureren voor elke groep.

Als u GitLab.com:

• u kunt kiezen uit een lijst met gedeelde hardlopers die GitLab onderhoudt.
• de gedeelde runners verbruiken de pijplijn-minutenin uw account.

hoe gedeelde lopers taken kiezen

gedeelde lopers verwerken taken met behulp van een wachtrij voor eerlijk gebruik. Deze wachtrij voorkomt projecten van het creëren van honderden banen en het gebruik van alle beschikbare gedeelde runner resources.

Het fair use queue-algoritme wijst taken toe op basis van projecten met het kleinste aantal taken dat al op gedeelde runners wordt uitgevoerd.

Voorbeeld 1:

Als deze taken in de wachtrij:

• Taak 1 voor Project 1
• Taak 2 voor Project 1
• Taak 3 voor Project 1
• Baan 4 voor Project 2
• Job 5 voor Project 2
• Job 6 voor Project 3

Het fair use-algoritme toegewezen taken in deze volgorde:

1. Taak 1 wordt als eerste gekozen, omdat het de laagste job-nummer van projecten met geen lopende opdrachten (alle projecten).
2. taak 4 is de volgende, omdat 4 nu het laagste taaknummer is van projecten zonder lopende taken (Project 1 heeft een lopende taak).
3. taak 6 is de volgende, omdat 6 nu het laagste aantal taken is van projecten zonder lopende taken (projecten 1 en 2 hebben lopende taken).
4. Taak 2 is de volgende, omdat van projecten met het laagste aantal lopende banen (elk heeft 1), het laagste aantal banen is.
5. taak 5 is de volgende, omdat Project 1 nu 2 lopende banen heeft en Taak 5 het laagste resterende aantal banen is tussen projecten 2 en 3.
6. tenslotte is Taak 3… omdat het de enige taak is die overblijft.

Voorbeeld 2:

Als deze taken in de wachtrij:

• Taak 1 voor Project 1
• Taak 2 voor Project 1
• Taak 3 voor Project 1
• Baan 4 voor Project 2
• Job 5 voor Project 2
• Job 6 voor Project 3

Het fair use-algoritme toegewezen taken in deze volgorde:

1. Taak 1 wordt als eerste gekozen, omdat het de laagste job-nummer van projecten met geen lopende opdrachten (alle projecten).
2. We voltooien Taak 1.
3. Taak 2 is de volgende, omdat, nadat Taak 1 is voltooid, alle projecten weer 0 taken hebben, en 2 het laagst beschikbare taaknummer is.
4. taak 4 is de volgende, omdat met Project 1 dat een taak uitvoert, 4 het laagste aantal is van projecten die geen taken uitvoeren (projecten 2 en 3).
5. We voltooien taak 4.
6. taak 5 is de volgende, omdat Project 2, nadat taak 4 is voltooid, geen taken meer draait.
7. taak 6 is de volgende, omdat Project 3 het enige project is zonder lopende taken.
8. tot slot kiezen we taak 3… omdat, nogmaals, dit de enige taak is die overblijft.

gedeelde runners

inschakelen GitLab.com, gedeelde lopers zijn ingeschakeld in alle projecten bydefault.

Op zelf beheerde instanties van GitLab moet een beheerder deze installand registreren.

u kunt ook gedeelde lopers inschakelen voor individuele projecten.

om gedeelde runners in te schakelen:

1. ga naar de instellingen van het project > CI/CD en vouw de Runners sectie uit.
2. Selecteer gedeelde lopers inschakelen voor dit project.

gedeelde lopers uitschakelen

U kunt gedeelde lopers uitschakelen voor individuele projecten of voor groepen.U moet eigenaar-rechten hebben voor het project of de groep.

om gedeelde runners voor een project uit te schakelen:

1. ga naar de projectinstellingen > CI/CD en vouw de Runners sectie uit.
2. in het gedeelte gedeelde lopers selecteert u gedeelde lopers inschakelen voor dit project, zodat de schakelaar grijs is.

gedeelde runners worden automatisch uitgeschakeld voor een project:

• als de instelling Gedeelde runners voor de bovenliggende groep is uitgeschakeld, en
• als het overschrijven van deze instelling niet is toegestaan op projectniveau.

om gedeelde runners voor een groep uit te schakelen:

1. ga naar de instellingen van de groep > CI/CD en vouw de Runners sectie uit.
2. schakel in het gedeelte gedeelde lopers de schakelaar gedeelde lopers inschakelen voor deze groep uit.
3. Als u gedeelde lopers wilt inschakelen voor individuele projecten of subgroepen, klikt u op projecten en subgroepen toestaan om de groepsinstelling te overschrijven.

Groepsrunners

gebruik groepsrunners als u wilt dat alle projecten in een groep toegang hebben tot een set runners.

Groep runners verwerken taken met behulp van een FIFO-wachtrij (first in, first out).

Maak een groep runner

u kunt een groep runner maken voor uw zelf beheerde GitLab instantie of voor GitLab.com.u moet eigenaar rechten hebben voor de groep.

om een groep runner aan te maken:

1. installeer GitLab Runner.
2. ga naar de groep waarvoor u de loper wilt laten werken.
3. ga naar Instellingen > CI / CD en vouw de Runners sectie uit.
4. noteer de URL en token.
5. Registreer de runner.

Bekijk en beheer groepsrunners

u kunt alle lopers voor een groep, zijn subgroepen en projecten bekijken en beheren.Je kunt dit doen voor je zelf beheerde GitLab instantie of voor GitLab.com.je moet eigenaar rechten hebben voor de groep.

1. ga naar de groep waar u de lopers wilt bekijken.
2. ga naar Instellingen > CI / CD en vouw de Runners sectie uit.

3. de volgende velden worden weergegeven.

   attribuut	Description
   Type	één of meer van de volgende staten: gedeelde, groep, specifieke, gesloten, of onderbroken
   Runner-token	Token gebruikt voor het identificeren van de loper, en dat de loper gebruikt om te communiceren met de GitLab exemplaar
   Omschrijving	Beschrijving gegeven van de loper, toen het werd gemaakt
   Versie	GitLab Runner versie
   IP adres	IP-adres van de host waarop de loper is geregistreerd
   Projecten	De graaf van projecten die de agent is toegewezen
   Banen	Totaal van de taken uitgevoerd door de agent
   Tags	Tags geassocieerd met de runner
   laatste contact	tijdstempel dat aangeeft wanneer de GitLab-instantie het laatst contact had met de runner

vanaf deze pagina kunt u Runners bewerken, pauzeren en verwijderen uit de groep, de subgroepen en projecten.

een groepsrunner pauzeren of verwijderen

U kunt een groepsrunner pauzeren of verwijderen voor uw zelf beheerde GitLab-instantie of voor GitLab.com.u moet eigenaar-rechten hebben voor de groep.

1. ga naar de groep waarvoor u de loper wilt verwijderen of pauzeren.
2. ga naar Instellingen > CI / CD en vouw de Runners sectie uit.
3. klik op pauzeren of runner verwijderen.
   • Als u een groepsrunner pauzeert die door meerdere projecten wordt gebruikt, pauzeert de runner voor alle projecten.
   • in de groepsweergave kunt u geen runner verwijderen die aan meer dan één project is toegewezen.U moet het eerst uit elk project verwijderen.
4. klik in het bevestigingsvenster op OK.

specifieke lopers

gebruik specifieke lopers wanneer u lopers wilt gebruiken voor specifieke projecten. Bijvoorbeeld als u:

• taken hebt met specifieke vereisten, zoals een implementatietaak die referenties vereist.
• projecten met veel CI-activiteit die kunnen profiteren van het gescheiden zijn van andere lopers.

u kunt een specifieke runner instellen voor meerdere projecten. Specifieke runnersmoeten expliciet worden ingeschakeld voor elk project.

specifieke runners verwerken taken met behulp van een FIFO-wachtrij (first in, first out).

Maak een specifieke runner

U kunt een specifieke runner maken voor uw zelf beheerde GitLab-instantie of voor GitLab.com.u moet eigenaar-rechten hebben voor het project.

om een specifieke runner aan te maken:

1. Install runner.
2. ga naar de instellingen van het project > CI / CD en vouw de Runners sectie uit.
3. noteer de URL en token.
4. Registreer de runner.

een specifieke runner inschakelen voor een specifiek project

een specifieke runner is beschikbaar in het project waarvoor het is gemaakt. Een beheerder kan een specifieke runner toepassen op extra projecten.

• u moet eigenaar rechten hebben voor het project.
• de specifieke runner mag niet worden vergrendeld.

om een specifieke runner voor een project in of uit te schakelen:

1. ga naar de projectinstellingen > CI/CD en vouw de Runners sectie uit.
2. klik op Inschakelen voor dit project of uitschakelen voor dit project.

voorkomen dat een specifieke runner wordt ingeschakeld voor andere projecten

U kunt een specifieke runner zo instellen dat deze “vergrendeld” is en niet kan worden ingeschakeld voor andere projecten.Deze instelling kan worden ingeschakeld wanneer u voor het eerst een runner registreert,maar kan ook later worden gewijzigd.

om een runner te vergrendelen of te ontgrendelen:

1. ga naar de instellingen van het project > CI/CD en vouw de Runners sectie uit.
2. Zoek de runner die u wilt vergrendelen of ontgrendelen. Zorg ervoor dat het is ingeschakeld.
3. klik op de potloodknop.
4. controleer de optie Vergrendelen naar huidige projecten.
5. klik op Wijzigingen opslaan.

wis handmatig de runner-cache

lezen de cache wissen.

Stel de maximale tijdslimiet voor een runner in

voor elke runner kunt u een maximale tijdslimiet voor een taak opgeven. Deze time-out,indien kleiner dan de door het project gedefinieerde time-out, heeft voorrang.

deze functie kan worden gebruikt om te voorkomen dat uw gedeelde runner wordt overweldigd door een project dat taken heeft met een lange time-out (bijvoorbeeld een week).

indien niet geconfigureerd, overschrijven lopers de timeout van het project niet.

Op GitLab.com, kunt u de time-out van de taak voor gedeelde hardlopers niet overschrijven en MOET u de door het project gedefinieerde time-out gebruiken.

om de maximale tijdslimiet voor taken in te stellen:

1. in een project, ga naar Instellingen > CI/CD > Runners.
2. Selecteer uw specifieke runner om de instellingen te bewerken.
3. voer een waarde in onder Maximale tijdslimiet voor taak.
4. selecteer Wijzigingen opslaan.

Hoe werkt deze functie:

Voorbeeld 1 – Runner-out groter dan het project time-out

1. stelt U de maximale time-out van taak voor een loper om 24 uur
2. U stelt de CI/CD-Out voor een project om 2 uur
3. het starten van een baan
4. De baan, als het runnen van meer, na 2 uur

Voorbeeld 2 – Runner time-out niet geconfigureerd

1. het verwijderen van de maximale time-out van taak configuratie van een loper
2. U stelt de CI/CD-Out voor een project om 2 uur
3. het starten van een baan
4. De baan, als het runnen van meer, na 2 uur

Voorbeeld 3 – Loper timeout kleiner dan project timeout

1. u stelt de maximale taak timeout voor een runner in op 30 minuten
2. u stelt de CI/CD Timeout voor een project in op 2 uur
3. u start een taak
4. de taak, als deze langer loopt, time-out na 30 minuten

wees voorzichtig met gevoelige informatie

met sommige uitvoerders van runner,Als u een taak op de runner kunt uitvoeren, kunt u vol krijgen toegang tot het bestandssysteem,en dus elke code die het draait, evenals het token van de runner. Met gedeelde runners betekent dit dat iedereen die taken op de runner uitvoert, toegang heeft tot de code van iemand anders die op de Runner draait.

bovendien, omdat u toegang kunt krijgen tot het runner token, is het mogelijk om een kloon van een runner te maken en bijvoorbeeld valse taken in te dienen.

het bovenstaande wordt gemakkelijk vermeden door het gebruik van gedeelde Runners op grote publieke GitLab instances te beperken, de toegang tot je GitLab instance te controleren en veiliger Runner executors te gebruiken.

voorkom dat runners gevoelige informatie onthullen

u kunt lopers beschermen zodat ze geen gevoelige informatie onthullen.Wanneer een runner wordt beschermd, kiest de runner alleen taken die zijn gemaakt op beveiligde branches of beveiligde tags en negeert hij andere taken.

om een runner te beschermen of onbeschermd te maken:

1. ga naar de instellingen van het project > CI/CD en vouw de Runners sectie uit.
2. Zoek de runner die u wilt beschermen of opheffen. Zorg ervoor dat het is ingeschakeld.
3. klik op de potloodknop.
4. controleer de optie Protected.
5. klik op Wijzigingen opslaan.

vorken

wanneer een project wordt gevorkt, kopieert het de instellingen van de taken die erop betrekking hebben. Dit betekent dat als u gedeelde runners hebt ingesteld voor een project en een van de vorken die projecteren, de gedeelde runners taken van dit project dienen.

aanvalsvectoren in lopers

werden eerder kort genoemd, maar de volgende dingen van lopers kunnen worden benut.We zijn altijd op zoek naar bijdragen die deze veiligheidsoverwegingen kunnen verzachten.

Reset het runner registratie token voor een project

Als u denkt dat een registratie token voor een project werd onthuld, moet u het opnieuw instellen. Een token kan worden gebruikt om een andere runner voor het project te registreren. Die nieuwe runnermay wordt dan gebruikt om de waarden van geheime variabelen te verkrijgen of om projectcode te klonen.

om het token te resetten:

1. ga naar de instellingen van het project > CI / CD.
2. vouw de sectie Algemene instellingen voor pijpleidingen uit.
3. zoek het veld Runner token form en klik op de knop Reveal value.
4. verwijder de waarde en sla het formulier op.
5. nadat de pagina is ververst, vouw de Runners instellingen sectie uit en controleer het registratie token – het moet worden gewijzigd.

vanaf nu is het oude token niet langer geldig en registreert het geen nieuwe lopers meer in het project. Als u tools gebruikt om nieuwe runners aan te bieden en te registreren, moeten de tokens die in deze tools worden gebruikt worden bijgewerkt om de waarde van het nieuwe token weer te geven.

Bepaal het IP-adres van een runner

het kan nuttig zijn om het IP-adres van een runner te weten, zodat u problemen met die runner kunt oplossen. GitLab slaat het IP-adres op en geeft het weer door de bron te bekijken van de HTTP-verzoeken die het aan GitLab doet bij het opvragen van taken. Het IP-adres wordt altijd up-to-date gehouden, dus als het runner IP automatisch wordt bijgewerkt in GitLab.

het IP-adres voor gedeelde hardlopers en Specifieke hardlopers kan worden gevonden onverschillig plaatsen.

Bepaal het IP-adres van een gedeelde runner

om het IP-adres van een gedeelde runner te bekijken, moet u admin-toegang hebben tot de GitLab-instantie. Om dit te bepalen:

1. bezoek Admin Area > overzicht > Runners.
2. zoek naar de runner in de tabel en u zou een kolom voor het IP-adres moeten zien.

Bepaal het IP-adres van een specifieke runner

om het IP-adres van een runner voor een specifiek project te kunnen vinden,moet u eigenaar-rechten hebben voor het project.

1. ga naar de instellingen van het project > CI / CD en vouw de Runners sectie uit.
2. op de detailpagina ziet u een rij voor het IP-adres.

gebruik tags om het aantal taken met de runner

te beperken U moet een runner Instellen om alle verschillende soorten taken te kunnen uitvoeren die het kan tegenkomen op de projecten die het deelt. Dit zou problematisch zijn voor grote hoeveelheden projecten, als er geen tags waren.

GitLab CI tags zijn niet hetzelfde als Git tags. GitLab CI-tags worden geassocieerd met hardlopers.Git tags zijn geassocieerd met commits.

door een runner te taggen voor de soorten taken die hij aankan, kunt u ervoor zorgen dat gedeelde runners alleen de taken uitvoeren waarvoor ze zijn uitgerust.

bijvoorbeeld, bij GitLab hebben we runners gelabeld met rails als ze de juiste afhankelijkheden bevatten om Rails testsuites uit te voeren.

wanneer u een runner registreert, is het standaardgedrag alleen picktagged jobs.To als u dit wijzigt, moet u eigenaar-rechten hebben voor het project.

om een runner taken zonder tag te laten kiezen:

1. ga naar de instellingen van het project > CI / CD en vouw de Runners sectie uit.
2. Zoek de runner die u niet-tagged taken wilt kiezen en zorg ervoor dat deze is ingeschakeld.
3. klik op de potloodknop.
4. controleer de optie taken zonder tag uitvoeren.
5. klik op de knop Wijzigingen opslaan om de wijzigingen door te voeren.

hieronder staan enkele voorbeelden van verschillende variaties.

runner draait alleen gelabelde taken

de volgende voorbeelden illustreren het potentiële effect van de runner die wordt ingesteld om alleen gelabelde taken uit te voeren.

Voorbeeld 1:

1. De Loper is geconfigureerd om alleen getagde taken uit te voeren en heeft de docker tag.
2. een taak met een hello – tag wordt uitgevoerd en geplakt.

Voorbeeld 2:

1. De Loper is geconfigureerd om alleen getagde taken uit te voeren en heeft de docker tag.
2. een taak met een docker – tag wordt uitgevoerd en uitgevoerd.

Voorbeeld 3:

1. De Loper is geconfigureerd om alleen getagde taken uit te voeren en heeft de docker tag.
2. een taak die geen tags heeft, wordt uitgevoerd en geplakt.

runner mag taken zonder label uitvoeren

De volgende voorbeelden illustreren het potentiële effect van de runner die wordt ingesteld op taken met label en zonder label uitvoeren.

Voorbeeld 1:

1. De Loper is geconfigureerd om taken zonder Tag uit te voeren en heeft de docker tag.
2. een taak zonder tags wordt uitgevoerd en uitgevoerd.
3. een tweede taak met eendocker – tag wordt uitgevoerd en uitgevoerd.

Voorbeeld 2:

1. De Loper is geconfigureerd om taken zonder Tag uit te voeren en heeft geen tags gedefinieerd.
2. een taak zonder tags wordt uitgevoerd en uitgevoerd.
3. een tweede taak die een docker – tag heeft, zit vast.

runner-gedrag configureren met variabelen

U kunt CI/CD-variabelen gebruiken om runner Git-gedrag globaal of voor individuele taken te configureren:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (ondiepe klonen)
• GIT_CLONE_PATH (custom build map)

U kunt ook gebruik maken van variabelen om te bepalen hoe vaak een runnerattempts bepaalde fasen van het uitvoeren van de taak.

Git strategie

Je kunt het GIT_STRATEGY gebruikt voor het ophalen van het archief inhoud, eitherglobally of per opdracht in de variables sectie:

variables: GIT_STRATEGY: clone

Er zijn drie mogelijke waarden: clonefetch, en none. Indien niet opgegeven gelaten,gebruiken taken de pijplijn-instelling van het project.

clone is de langzaamste optie. Het klonen van de repository vanaf nul voor elke taak, ervoor te zorgen dat de lokale werkkopie altijd ongerept is.Als een bestaande worktree wordt gevonden, wordt deze verwijderd voor het klonen.

fetch is sneller omdat het de lokale werkkopie hergebruikt (terugvallen op cloneals het niet bestaat). git clean wordt gebruikt om alle wijzigingen van de lastjob ongedaan te maken, en git fetch wordt gebruikt om commits op te halen die zijn gemaakt nadat de laatste taak was uitgevoerd.

echter, fetch vereist toegang tot de vorige werkboom. Deze workswell bij het gebruik van deshell ofdocker uitvoerder omdat de methode om worktrees te behouden en proberen om ze standaard te hergebruiken.

Dit heeft beperkingen bij het gebruik van de Docker Machine uitvoerder.

Het werkt niet voor de kubernetes uitvoerder,maar er bestaat een feature-voorstel.Dekubernetes uitvoerder klonen altijd in een tijdelijke map.

een Git-strategie van none gebruikt ook de lokale werkkopie, maar slaat alle Gitoperaties over die normaal door GitLab worden gedaan. GitLab Runner pre-clone scripts worden ook overgeslagen, indien aanwezig. Deze strategie kan betekenen dat u fetch en checkout commando ‘ s moet toevoegen aan uw .gitlab-ci.yml script.

het kan worden gebruikt voor taken die uitsluitend op artefacten werken, zoals een implementatietaak.Git repository gegevens kunnen aanwezig zijn, maar het is waarschijnlijk verouderd. U moet alleen op bestanden gebracht in de lokale werkkopie van cache of artefacten.

Git submodule strategy

vereist GitLab Runner v1.10+.

de GIT_SUBMODULE_STRATEGY variabele wordt gebruikt om te bepalen of / hoe Gitsubmodules worden opgenomen bij het ophalen van de code voor een build. U kunt ze globaal of per taak instellen in de variables sectie.

Er zijn drie mogelijke waarden: nonenormal, en recursive:

• none betekent dat submodules niet zijn opgenomen bij het ophalen van de projectcode. Dit is de standaard, die overeenkomt met het pre-v1.10 gedrag.

• normal betekent dat alleen de submodules op het hoogste niveau zijn opgenomen. Het is equivalent aan:

  git submodule syncgit submodule update --init

• recursive betekent dat alle submodules (inclusief submodules van submodules)zijn opgenomen. Deze functie heeft Git v1. 8.1 en hoger nodig. Als je aGitLab Runner gebruikt met een uitvoerder die niet gebaseerd is op Docker, zorg er dan voor dat de Git version deze vereiste opvat. Het is gelijk aan:

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

om deze functie correct te laten werken, moeten de submodules worden geconfigureerd(in .gitmodules) met ofwel:

• de HTTP(S) URL van een publiek toegankelijke repository, of
• a relatief pad naar een andere repository op dezelfde GitLab server. Zie de git submodules documentatie.

Git checkout

de GIT_CHECKOUT variabele kan worden gebruikt wanneer de GIT_STRATEGY is ingesteld op ofwelclone of fetch om aan te geven of een git checkout moet worden uitgevoerd. Indien niet gespecificeerd, is het standaard true. U kunt ze globaal of per taak instellen in devariables sectie.

indien ingesteld op false, de loper:

• bij het uitvoeren van fetch – werkt de repository bij en verlaat de werkkopie op de huidige revisie,
• bij het uitvoeren van clone – kloont de repository en laat de werkkopie op de standaardtak.

als GIT_CHECKOUT is ingesteld op true, werken beide clone en fetch op dezelfde manier.De runner controleert de werkkopie van een revisie met betrekking tot de CI-pijplijn:

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

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

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"