• hvordan delte løbere vælger job
• aktiver delte løbere
• Deaktiver delte løbere

• Opret en gruppeløber
• se og administrer gruppeløbere
• sæt en Gruppeløber på pause eller Fjern

• opret en bestemt løber
• aktiver en bestemt løber for et specifikt projekt
• undgå, at en bestemt løber aktiveres for andre projekter

• Bestem IP-adressen for en løber
  • af en delt løber
  • bestem IP-adressen for en bestemt løber
• Brug tags til at begrænse antallet af job ved hjælp af løberen
  • runner kører kun taggede job
  • runner er tilladt at køre untagged job
• Konfigurer runner adfærd med variabler
  • Git strategi
  • Git submodule strategi
  • Git checkout
  • Git clean flag
  • Git hente ekstra flag
  • lavvandet kloning
  • brugerdefinerede build mapper
    • håndtering samtidighed
    • indlejrede stier
  • jobstadieforsøg
• systemopkald er ikke tilgængelige på GitLab.com delte løbere
• Indstillinger for artefakt og cache

i GitLab CI/CD kører løbere koden defineret i.gitlab-ci.yml.En løber er en let, meget skalerbar agent, der henter et CI-job gennem koordinator API for GitLab CI/CD, kører jobbet og sender resultatet tilbage til GitLab-forekomsten.

løbere oprettes af en administrator og er synlige i GitLab UI.Løbere kan være specifikke for bestemte projekter eller tilgængelige for alle projekter.

denne dokumentation er fokuseret på at bruge løbere i GitLab.Hvis du har brug for at installere og konfigurere GitLab Runner, skal du sy GitLab Runner-dokumentationen.

typer af løbere

I GitLab UI er der tre typer løbere, baseret på hvem du vil have adgang:

• delte løbere er tilgængelige for alle grupper og projekter i en GitLab-forekomst.
• Gruppeløbere er tilgængelige for alle projekter og undergrupper i en gruppe.
• specifikke løbere er forbundet med specifikke projekter.Typisk bruges specifikke løbere til et projekt ad gangen.

delte løbere

delte løbere er tilgængelige for hvert projekt i en GitLab-forekomst.

brug delte løbere, når du har flere job med lignende krav. I stedet for at have flere løbere på tomgang til mange projekter, kan du have et par løbere, der håndterer flere projekter.

Hvis du bruger en selvstyret forekomst af GitLab:

• din administrator kan installere og registrere delte løbere ved at gå til dit projekts indstillinger> CI / CD, udvide afsnittet løbere og klikke på Vis installationsvejledning til runner.Disse instruktioner er også tilgængelige i dokumentationen.
• administratoren kan også konfigurere et maksimalt antal delte runner pipeline minutter forehver gruppe.

Hvis du bruger GitLab.com:

• du kan vælge fra en liste over delte løbere, som GitLab vedligeholder.
• de delte løbere forbruger rørledningerne minutterinkluderet med din konto.

hvordan delte løbere vælger job

delte løbere behandler job ved hjælp af en fair brugskø. Denne kø forhindrer projekter i at skabe hundreder af job og bruge alle tilgængelige delte runner-ressourcer.

fair usage-køalgoritmen tildeler job baseret på de projekter, der har det seneste antal job, der allerede kører på delte løbere.

eksempel 1

hvis disse job er i køen:

• Job 1 For projekt 1
• Job 2 For projekt 1
• Job 3 For projekt 1
• Job 4 for Projekt 2
• Job 5 for Projekt 2
• Job 6 For projekt 3

fair usage-algoritmen tildeler job i denne rækkefølge:

1. Job 1 vælges først, fordi det har det laveste jobnummer fra projekter uden løbende job (det vil sige alle projekter).
2. Job 4 er næste, fordi 4 Nu er det laveste jobnummer fra projekter uden løbende job (projekt 1 har et job, der kører).
3. Job 6 er næste, fordi 6 nu er det laveste jobnummer fra projekter uden løbende job (projekter 1 og 2 har job, der kører).
4. Job 2 er næste, fordi af projekter med det laveste antal job, der kører (hver har 1), er det det laveste jobnummer.
5. Job 5 er næste, fordi projekt 1 Nu har 2 job i gang, og Job 5 er det laveste resterende jobnummer mellem Projekt 2 og 3.
6. endelig er Job 3 … fordi det er det eneste job tilbage.

eksempel 2

hvis disse job er i køen:

• Job 1 For projekt 1
• Job 2 For projekt 1
• Job 3 For projekt 1
• Job 4 for Projekt 2
• Job 5 for Projekt 2
• Job 6 For projekt 3

fair usage-algoritmen tildeler job i denne rækkefølge:

1. Job 1 vælges først, fordi det har det laveste jobnummer fra projekter uden løbende job (det vil sige alle projekter).
2. Vi afslutter Job 1.
3. Job 2 er næste, fordi alle projekter, når de er færdige med Job 1, har 0 job, der kører igen, og 2 er det laveste tilgængelige jobnummer.
4. Job 4 er det næste, fordi når projekt 1 kører et Job, er 4 det laveste antal fra projekter, der kører ingen job (projekt 2 og 3).
5. Vi afslutter Job 4.
6. Job 5 er næste, fordi Projekt 2 ikke har nogen job, der kører igen.
7. Job 6 er næste, fordi projekt 3 er det eneste projekt, der er tilbage uden løbende job.
8. endelig vælger vi Job 3 … fordi det igen er det eneste job, der er tilbage.

aktiver delte løbere

On GitLab.com, delte løbere er aktiveret i alle projekter bydefault.

på selvstyrede forekomster af GitLab skal en administrator installereog registrere dem.

Du kan også aktivere delte løbere til individuelle projekter.

Sådan aktiveres delte løbere:

1. gå til projektets indstillinger> CI / CD og udvid afsnittet løbere.
2. vælg Aktiver delte løbere for dette projekt.

Deaktiver delte løbere

Du kan deaktivere delte løbere for individuelle projekter eller for grupper.Du skal have Ejertilladelser til projektet eller gruppen.

Sådan deaktiveres delte løbere til et projekt:

1. gå til projektets indstillinger> CI / CD og udvid afsnittet løbere.
2. i området delte løbere skal du vælge Aktiver delte løbere for dette projekt, så skiftet er nedtonet.

delte løbere deaktiveres automatisk for et projekt:

• hvis indstillingen delte løbere for den overordnede gruppe er deaktiveret, og
• hvis tilsidesættelse af denne indstilling ikke er tilladt på projektniveau.

Sådan deaktiveres delte løbere for en gruppe:

1. gå til gruppens indstillinger> CI / CD og udvid afsnittet løbere.
2. i området delte løbere skal du slå aktiver delte løbere til denne gruppe fra.
3. hvis du vil tillade, at delte løbere aktiveres for individuelle projekter eller undergrupper,skal du klikke på Tillad projekter og undergrupper for at tilsidesætte gruppeindstillingen.

Gruppeløbere

brug Gruppeløbere, når du vil have alle projekter i en gruppefor at få adgang til et sæt løbere.

Gruppeløbere behandler job ved hjælp af en FIFO-kø (first in, first out).

Opret en gruppeløber

Du kan oprette en gruppeløber til din selvstyrede GitLab-forekomst eller til GitLab.com.du skal have Ejertilladelser til gruppen.

for at oprette en gruppeløber:

1. installer GitLab Runner.
2. gå til den gruppe, du vil få løberen til at arbejde for.
3. gå til Indstillinger > CI/CD og udvid sektionen løbere.
4. Bemærk URL og token.
5. registrer løberen.

se og administrer gruppeløbere

Du kan få vist og administrere alle løbere for en gruppe, dens undergrupper og projekter.Du kan gøre dette for din selvstyrede GitLab-forekomst eller for GitLab.com.du skal have Ejertilladelser til gruppen.

1. gå til gruppen, hvor du vil se løberne.
2. gå til Indstillinger > CI/CD og udvid sektionen løbere.

3. følgende felter vises.

   attribut	Description
   Type	en eller flere af følgende tilstande: delt, gruppe, specifik, låst eller sat på pause
   Runner token	Token bruges til at identificere løberen, og som løberen bruger til at kommunikere med GitLab-forekomsten
   beskrivelse	beskrivelse givet til løberen, da den blev oprettet
   Version	GitLab Runner Version
   IP-adresse	IP-adresse på værten, som løberen er registreret
   projekter	antallet af projekter, som løberen er tildelt
   job	i alt job, der køres af løberen
   Tags	Tags tilknyttet løberen
   sidste kontakt	tidsstempel, der angiver, hvornår GitLab-forekomsten sidst kontaktede løberen

fra denne side kan du redigere, pause og fjerne løbere fra gruppen, dens undergrupper og projekter.

sæt en gruppeløber på Pause eller fjern

Du kan sætte en gruppeløber på pause eller fjerne en gruppeløber for din selvstyrede GitLab-forekomst eller for GitLab.com.du skal have ejertilladelser til gruppen.

1. gå til den gruppe, du vil fjerne, eller sæt løberen på pause for.
2. gå til Indstillinger > CI/CD og udvid sektionen løbere.
3. Klik på Pause eller Fjern runner.
   • hvis du sætter en gruppeløber på pause, der bruges af flere projekter, holder løberen pause for alle projekter.
   • fra gruppevisningen kan du ikke fjerne en løber, der er tildelt mere end et projekt.Du skal først fjerne det fra hvert projekt.
4. klik på OK i bekræftelsesdialogen.

specifikke løbere

brug specifikke løbere, når du vil bruge løbere til specifikke projekter. For eksempel, når du har:

• job med specifikke krav, som et implementeringsjob, der kræver legitimationsoplysninger.
• projekter med en masse CI-aktivitet, der kan drage fordel af at være adskilt fra andre løbere.

Du kan oprette en bestemt løber, der skal bruges af flere projekter. Specifikke løbereskal være aktiveret for hvert projekt eksplicit.

specifikke løbere behandler job ved hjælp af en FIFO-kø (first in, first out).

Opret en bestemt løber

Du kan oprette en bestemt løber til din selvstyrede GitLab-forekomst eller til GitLab.com.du skal have Ejertilladelser til projektet.

for at oprette en bestemt runner:

1. installer runner.
2. gå til projektets indstillinger > CI/CD og udvid sektionen løbere.
3. Bemærk URL og token.
4. registrer løberen.

aktiver en bestemt løber til et specifikt projekt

en bestemt løber er tilgængelig i det projekt, den blev oprettet til. En administrator kan gøre det muligt for en bestemt løber at ansøge om yderligere projekter.

• du skal have Ejertilladelser til projektet.
• den specifikke løber må ikke låses.

Sådan aktiveres eller deaktiveres en bestemt løber for et projekt:

1. gå til projektets indstillinger > CI/CD og udvid afsnittet løbere.
2. Klik på Aktiver for dette projekt eller deaktiver for dette projekt.

undgå, at en bestemt løber aktiveres for andre projekter

Du kan konfigurere en bestemt løber, så den er “låst” og ikke kan aktiveres for andre projekter.Denne indstilling kan aktiveres, når du først registrerer en løber, men kan også ændres senere.

Sådan låses eller låses en løber op:

1. gå til projektets indstillinger> CI / CD og udvid afsnittet løbere.
2. Find den løber, du vil låse eller låse op. Sørg for, at den er aktiveret.
3. Klik på blyantknappen.
4. kontroller indstillingen Lås til aktuelle projekter.
5. Klik på Gem ændringer.

Ryd manuelt løbercachen

Læs rydning af cachen.

indstil maksimal jobtimeout for en løber

for hver løber kan du angive en maksimal jobtimeout. Denne timeout, hvis den er mindre end den projektdefinerede timeout, har forrang.

denne funktion kan bruges til at forhindre, at din delte løber overvældes af et projekt, der har job med lang timeout (for eksempel en uge).

når de ikke er konfigureret, tilsidesætter løbere ikke projektets timeout.

på GitLab.med, du kan ikke tilsidesætte jobtimeout for delte løbere og skal bruge den projektdefinerede timeout.

for at indstille den maksimale timeout for job:

1. i et projekt skal du gå til Indstillinger>CI/CD> løbere.
2. vælg din specifikke løber for at redigere indstillingerne.
3. Indtast en værdi under maksimal timeout for job.
4. vælg Gem ændringer.

Sådan fungerer denne funktion:

eksempel 1 – Runner timeout større end project timeout

1. du indstiller den maksimale timeout for en runner til 24 timer
2. du indstiller CI/CD Timeout for et projekt til 2 timer
3. du starter et job
4. jobbet, hvis det kører længere, timeout efter 2 timer

eksempel 2 – Runner timeout ikke konfigureret

1. du fjerner den maksimale timeout – indstilling fra en runner
2. du indstiller CI/CD-timeout for et projekt til 2 timer
3. du starter et job
4. jobbet, hvis det kører længere, Timeout efter 2 timer

eksempel 3-runner timeout mindre end projekttimeout

1. du indstiller den maksimale jobtimeout for en løber til 30 minutter
2. du indstiller CI/CD-Timeout for et projekt til 2 timer
3. du starter et job
4. jobbet, hvis det kører længere, timeout efter 30 minutter

vær forsigtig med følsomme oplysninger

med nogle runner-eksekutorer,hvis du kan køre et job på den anden side af Runner, kan du få fuld adgang til filsystemet,og dermed enhver kode det kører samt token af løberen. Med delte løbere betyder det, at enhverder kører job på løberen, kan få adgang til andres kode, der kører påløberen.

desuden, fordi du kan få adgang til runner token, er det muligtat oprette en klon af en løber og indsende falske job, for eksempel.

ovenstående undgås let ved at begrænse brugen af delte runners på store offentlige GitLab-forekomster, kontrollere adgangen til din GitLab-forekomst og bruge mere sikre runner-eksekutorer.

forhindre løbere i at afsløre følsomme oplysninger

Du kan beskytte løbere, så de ikke afslører følsomme oplysninger.Når en løber er beskyttet, vælger løberen job,der kun er oprettet på beskyttede grene eller beskyttede tags, og ignorerer andre job.

for at beskytte eller fjerne beskyttelsen af en løber:

1. gå til projektets indstillinger> CI / CD og udvid afsnittet løbere.
2. Find den løber, du vil beskytte eller beskytte. Sørg for, at den er aktiveret.
3. Klik på blyantknappen.
4. Kontroller den beskyttede indstilling.
5. Klik på Gem ændringer.

Forks

når et projekt er forked, kopierer det indstillingerne for de job, der relateretil det. Dette betyder, at hvis du har delt løbere oprettet til et projekt, og nogen gafler det projekt, de delte løbere Tjener Job i dette projekt.

angrebsvektorer i løbere

nævnt kort tidligere, men følgende ting af løbere kan udnyttes.Vi er altid på udkig efter bidrag, der kan afbøde dissesikkerhedshensyn.

Nulstil runner-registreringstokenet for et projekt

Hvis du mener, at et registreringstoken for et projekt blev afsløret, skal duIndstil det igen. Et token kan bruges til at registrere en anden løber til projektet. Den nye runnerkan derefter bruges til at opnå værdierne for hemmelige variabler eller til at klone projektkode.

for at nulstille token:

1. gå til projektets indstillinger> CI / CD.
2. Udvid afsnittet Generelle indstillinger for rørledninger.
3. Find feltet Runner token-formular, og klik på knappen Vis værdi.
4. Slet værdien og gem formularen.
5. når siden er opdateret, skal du udvide sektionen Runners settingsog kontroller registreringstokenet-det skal ændres.

fra nu af er det gamle token ikke længere gyldigt og registrerer ikkeeventuelle nye løbere til projektet. Hvis du bruger værktøjer til at levere og registrere nye løbere, skal de tokens, der bruges i disse værktøjer, opdateres for at afspejle værdien af det nye token.

Bestem IP-adressen på en løber

det kan være nyttigt at kende IP-adressen på en løber, så du kan fejlfindeproblemer med den løber. GitLab gemmer og viser IP-adressen ved at visekilden til de HTTP-anmodninger, den fremsætter til GitLab, når man vælger job. TheIP-adressen holdes altid opdateret, så hvis runner IP ændrer detautomatisk opdateringer i GitLab.

IP-adressen for delte løbere og specifikke løbere kan findes iforskellige steder.

Bestem IP-adressen på en delt løber

for at se IP-adressen på en delt løber skal du have administratoradgang til GitLab-forekomsten. For at bestemme dette:

1. besøg Admin område> oversigt> løbere.
2. Kig efter løberen i tabellen, og du skal se en kolonne til IP-adresse.

Bestem IP-adressen for en bestemt løber

for at finde IP-adressen til en løber til et specifikt projekt skal du have Ejertilladelser til projektet.

1. gå til projektets indstillinger> CI / CD og udvid sektionen løbere.
2. på siden Detaljer skal du se en række for IP-adresse.

Brug tags til at begrænse antallet af job ved hjælp af runner

du skal oprette en runner for at kunne køre alle de forskellige typer job, som den kan støde på på de projekter, den deles over. Dette ville være problematisk for store mængder projekter, hvis det ikke var for tags.GitLab ci-tags er ikke det samme som Git-tags. GitLab ci-tags er forbundet med løbere.Git-tags er forbundet med forpligtelser.

Ved at tagge en løber for de typer job, den kan håndtere, kan du sørge for, at delte løbere kun kører de job, de er udstyret til at køre.

for eksempel har vi på GitLab løbere mærket medrails hvis de indeholderde relevante afhængigheder til at køre Rails test suiter.

når du registrerer en løber, er dens standardadfærd kun at vælge tagget jobs.To ændre dette, du skal have Ejertilladelser til projektet.

for at få en løber til at vælge ikke-taggede job:

1. gå til projektets indstillinger> CI / CD og udvid sektionen løbere.
2. Find den løber, du vil vælge ikke-taggede job, og sørg for, at den er aktiveret.
3. Klik på blyantknappen.
4. kontroller indstillingen Kør ikke-taggede job.
5. Klik på knappen Gem ændringer for at ændringerne kan træde i kraft.

nedenfor er nogle eksempler scenarier af forskellige variationer.

runner kører kun taggede job

følgende eksempler illustrerer den potentielle virkning af, at løberen er setto run only tagged jobs.

eksempel 1:

1. løberen er konfigureret til kun at køre taggede job og hardocker tagget.
2. et job, der har et hello tag udføres og sidder fast.

eksempel 2:

1. løberen er konfigureret til kun at køre taggede job og hardocker tagget.
2. et job, der har et docker tag udføres og køres.

eksempel 3:

1. løberen er konfigureret til kun at køre taggede job og hardocker tagget.
2. et job, der ikke har definerede tags, udføres og sidder fast.

runner har lov til at køre ikke-taggede job

de følgende eksempler illustrerer den potentielle virkning af, at løberen er setto run tagged og untagged job.

eksempel 1:

1. løberen er konfigureret til at køre ikke-taggede job og hardocker tagget.
2. et job, der ikke har definerede tags, udføres og køres.
3. et andet job, der har etdocker tag defineret udføres og køres.

eksempel 2:

1. løberen er konfigureret til at køre ikke-taggede job og har ingen tags defineret.
2. et job, der ikke har definerede tags, udføres og køres.
3. et andet job, der har en docker tag defineret sidder fast.

Konfigurer runneradfærd med variabler

Du kan bruge CI / CD-variabler til at konfigurere runner Git behaviorglobalt eller til individuelle job:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (lav kloning)
• GIT_CLONE_PATH (brugerdefinerede build-mapper)

Du kan også bruge variabler til at konfigurere, hvor mange gange en løberforsøg på bestemte faser af jobbet henrettelse.

Git-strategi

Du kan indstille GIT_STRATEGYbruges til at hente repository indhold, entherglobally eller per-job i variablessektion:

variables: GIT_STRATEGY: clone