• typer løpere
  • Delte løpere
    • Hvordan delte løpere velger jobber
    • Aktiver delte løpere
    • Deaktiver delte løpere
  • Lag en gruppe løpere
  • Vis Og administrer gruppeløpere
  • Pause Eller fjern en gruppe runner
• Spesifikke løpere
  • opprett en bestemt løper
  • aktiver en bestemt løper for et Bestemt Prosjekt
  • Forhindre at en bestemt løper blir aktivert for andre prosjekter

I GitLab CI / CD kjører løpere koden definert i .gitlab-ci.yml.En runner er en lett, svært skalerbar agent som plukker opp EN CI jobb throughthe koordinator API Av GitLab CI / CD, kjører jobben, og sender resultatet tilbake Til GitLab eksempel.

Løpere er opprettet av en administrator og er synlige i GitLab UI.Løpere kan være spesifikke for bestemte prosjekter eller tilgjengelige for alle prosjekter.

denne dokumentasjonen er fokusert på bruk av løpere i GitLab.Hvis Du trenger å installere Og konfigurere GitLab Runner, sethe GitLab Runner dokumentasjon.

typer løpere

I GitLab UI er det tre typer løpere, basert på hvem du vil ha tilgang til:

• Delte løpere er tilgjengelige for alle grupper og prosjekter i En GitLab-forekomst.
• Gruppeløpere er tilgjengelige for alle prosjekter og undergrupper i en gruppe.
• Spesifikke løpere er knyttet til spesifikke prosjekter.Vanligvis brukes bestemte løpere til ett prosjekt om gangen.

Delte løpere

Delte løpere er tilgjengelige for hvert prosjekt i En GitLab-forekomst.

Bruk delte løpere når du har flere jobber med lignende krav. I stedet for å ha flere løpere tomgang for mange prosjekter, kan du ha noen løpere som håndterer flere prosjekter.

hvis du bruker En selvstyrt forekomst Av GitLab:

• administratoren din kan installere og registrere delte løpere ved å gå til prosjektets Innstillinger> CI / CD, utvide Runners-delen og klikke På Vis runner installasjonsinstruksjoner.Disse instruksjonene er også tilgjengelige i dokumentasjonen.
• administratoren kan også konfigurere maksimalt antall delte runner pipeline minutter for hver gruppe.

hvis du bruker GitLab.com:

• Du kan velge fra en liste over delte løpere Som GitLab opprettholder.
• de delte løperne bruker pipelines minutesinkludert med kontoen din.

Hvordan delte løpere velger jobber

Delte løpere behandler jobber ved å bruke en kø for rettferdig bruk. Denne køen forhindrer prosjekter i å skape hundrevis av jobber og bruke alle tilgjengelige runner-ressurser.

algoritmen for rettferdig bruk tildeler jobber basert på prosjektene som har det laveste antallet jobber som allerede kjører på delte løpere.

Eksempel 1

Hvis disse jobbene er i køen:

• Jobb 1 For Prosjekt 1
• Jobb 2 for Prosjekt 1
• Jobb 3 for Prosjekt 1
• Jobb 4 for Prosjekt 2
• Jobb 5 for Prosjekt 2
• Jobb 6 for Prosjekt 3

algoritmen for rimelig bruk tildeler jobber i denne rekkefølgen:

1. jobb 1 velges først, fordi den har det laveste Jobbnummeret fra prosjekter uten løpende jobber (det vil si alle prosjekter).
2. Jobb 4 er neste, fordi 4 er nå det laveste jobbnummeret fra prosjekter uten løpende jobber(Prosjekt 1 har en jobb som kjører).
3. Jobb 6 er neste, fordi 6 er nå det laveste jobbnummeret fra prosjekter uten løpende jobber (Prosjekter 1 og 2 har jobber som kjører).
4. Jobb 2 er neste, fordi av prosjekter med lavest antall jobber som kjører (hver har 1), er det det laveste jobbnummeret.
5. Jobb 5 er neste, Fordi Prosjekt 1 nå har 2 jobber som kjører og Jobb 5 er det laveste gjenværende jobbnummeret mellom Prosjekt 2 og 3.
6. Endelig Er Jobb 3… fordi det Er den eneste jobben igjen.

Eksempel 2

Hvis disse jobbene er i køen:

• Jobb 1 For Prosjekt 1
• Jobb 2 for Prosjekt 1
• Jobb 3 for Prosjekt 1
• Jobb 4 for Prosjekt 2
• Jobb 5 for Prosjekt 2
• Jobb 6 For Prosjekt 3

algoritmen for rimelig bruk tildeler jobber i denne rekkefølgen:

1. jobb 1 velges først, fordi den har det laveste Jobbnummeret fra prosjekter uten løpende jobber (det vil si alle prosjekter).
2. Vi fullfører Jobb 1.
3. Jobb 2 er neste, fordi etter å ha fullført Jobb 1, har alle prosjekter 0 jobber som kjører igjen, og 2 er det laveste tilgjengelige jobbnummeret.
4. Jobb 4 er neste, Fordi Med Prosjekt 1 som kjører En Jobb, er 4 det laveste tallet fra prosjekter som ikke kjører noen jobber (Prosjekter 2 og 3).
5. vi fullfører Jobb 4.
6. Jobb 5 er neste, Fordi Etter å ha fullført Jobb 4, Har Project 2 ingen jobber som kjører igjen.
7. Jobb 6 er neste, Fordi Prosjekt 3 er det eneste prosjektet igjen uten løpende jobber.
8. Til Slutt velger Vi Jobb 3 … fordi det igjen er den eneste jobben igjen.

Aktiver delte løpere

På GitLab.com, delte løpere er aktivert i alle prosjekter ved standard.

på selvstyrte forekomster Av GitLab må en administrator installereog registrere dem.

du kan også aktivere delte løpere for individuelle prosjekter.

for å aktivere delte løpere:

1. Gå til prosjektets Innstillinger > CI / CD og utvid Løpere-delen.
2. Velg Aktiver delte løpere for dette prosjektet.

Deaktiver delte løpere

du kan deaktivere delte løpere for enkeltprosjekter eller for grupper.Du må ha Eiertillatelser for prosjektet eller gruppen.

for å deaktivere delte løpere for et prosjekt:

1. Gå til prosjektets Innstillinger > CI / CD og utvid Løpere-delen.
2. i Delte løpere-området velger Du Aktiver delte løpere for dette prosjektet, slik at veksleknappen er nedtonet.

Delte løpere deaktiveres automatisk for et prosjekt:

• hvis innstillingen delte løpere for den overordnede gruppen er deaktivert, og
• hvis det ikke er tillatt å overstyre denne innstillingen på prosjektnivå.

for å deaktivere delte løpere for en gruppe:

1. Gå til gruppens Innstillinger > CI / CD og utvid Løpere-delen.
2. i Delte løpere-området slår du av aktiver delte løpere for denne gruppen.hvis du Vil tillate at delte løpere aktiveres for individuelle prosjekter eller undergrupper,klikker Du På Tillat at prosjekter og undergrupper overstyrer gruppeinnstillingen.

Gruppeløpere

Bruk Gruppeløpere når du vil at alle prosjekter i en gruppeå ha tilgang til et sett med løpere.

Gruppe løpere behandle jobber ved hjelp av en først inn, FØRST ut (FIFO) kø.

Opprett en gruppeløper

du kan opprette en gruppeløper for Din selvstyrte GitLab-forekomst eller For GitLab. com. Du må ha Eiertillatelser for gruppen.

For å opprette en gruppe løper:

1. Installer GitLab Runner.
2. Gå til gruppen du vil få løperen til å jobbe for.
3. Gå Til Innstillinger > CI / CD og utvid Løpere-delen.
4. Legg MERKE TIL URL og token.
5. Registrer løperen.

Vis og administrer gruppeløpere

Du kan vise og administrere alle løpere for en gruppe, undergrupper og prosjekter.Du kan gjøre dette for din selvstyrte GitLab-forekomst eller For GitLab.com. Du må ha Eiertillatelser for gruppen.

1. Gå til gruppen der du vil vise løperne.
2. Gå Til Innstillinger > CI / CD og utvid Løpere-delen.

3. følgende felt vises.

   td>

   Attributt
   Type	en eller flere av følgende tilstander: delt, gruppe, spesifikk, låst eller pauset
   Runner token	Token som brukes til å identifisere løperen, og som løperen bruker til å kommunisere Med GitLab-forekomsten
   Beskrivelse	Beskrivelse gitt til løperen da den ble opprettet
   	Versjon	GitLab Runner versjon
   ip-adresse	ip-adressen til verten som løperen er registrert på
   prosjekter	antall prosjekter som løperen er tildelt
   jobber	totalt antall jobber som kjøres av løperen
   Tagger
   Siste kontakt	Tidsstempel som angir når GitLab-forekomsten sist kontaktet løperen

fra denne siden kan du redigere, pause og fjerne løpere fra Gruppen, undergruppene og prosjektene.

Pause eller fjern en gruppeløper

du kan pause eller fjerne en gruppeløper for Din selvstyrte GitLab-forekomst eller For GitLab. com. Du må ha Eiertillatelser for gruppen.

1. Gå til gruppen du vil fjerne eller pause løperen for.
2. Gå Til Innstillinger > CI / CD og utvid Løpere-delen.
3. Klikk På Pause eller Fjern runner.
   • hvis du setter en gruppeløper på pause som brukes av flere prosjekter, stopper løperen for alle prosjekter.
   • fra gruppevisningen kan du ikke fjerne en løper som er tilordnet til mer enn ett prosjekt.Du må fjerne det fra hvert prosjekt først.
4. i bekreftelsesdialogboksen klikker DU OK.

Spesifikke løpere

Bruk Spesifikke løpere når du vil bruke løpere til bestemte prosjekter. For eksempel når du har:

• Jobber med spesifikke krav, for eksempel en distribuere jobb som krever legitimasjon.
• Prosjekter med MYE CI-aktivitet som kan ha nytte av å være atskilt fra andre løpere.

du kan sette opp en bestemt løper som skal brukes av flere prosjekter. Spesifikke løpere må være aktivert for hvert prosjekt eksplisitt.

Bestemte løpere behandler jobber ved å bruke en fifo-kø (first in, first out).

Opprett en bestemt løper

du kan opprette en bestemt løper for Din selvstyrte GitLab-forekomst eller For GitLab.com. Du må ha Eiertillatelser for prosjektet.

For å opprette en spesifikk løper:

1. Installer løper.
2. Gå til prosjektets Innstillinger > CI / CD og utvid Løpere-delen.
3. Legg MERKE TIL URL og token.
4. Registrer løperen.

Aktiver en bestemt løper for et bestemt prosjekt

en bestemt løper er tilgjengelig i prosjektet den ble opprettet for. En administrator kan aktivere en bestemt løper for å søke på flere prosjekter.

• du må ha Eiertillatelser for prosjektet.
• den spesifikke løperen må ikke låses.

for å aktivere eller deaktivere en spesifikk løper for et prosjekt:

1. Gå til prosjektets Innstillinger> CI / CD og utvid Delen Løpere.
2. Klikk Aktiver for dette prosjektet eller Deaktiver for dette prosjektet.

Forhindre at en bestemt løper aktiveres for andre prosjekter

du kan konfigurere en bestemt løper slik at den er «låst» og ikke kan aktiveres for andre prosjekter.Denne innstillingen kan aktiveres når du først registrerer en løper, men kan også endres senere.

for å låse eller låse opp en løper:

1. Gå til prosjektets Innstillinger > CI / CD og utvid Løpere-delen.
2. Finn løperen du vil låse eller låse opp. Kontroller at den er aktivert.
3. Klikk på blyant-knappen.
4. Sjekk Alternativet Lås til nåværende prosjekter.
5. Klikk På Lagre endringer.

tøm hurtigbufferen manuelt

Les når du tømmer hurtigbufferen.

Angi maksimal tidsavbrudd for en løper

for hver løper kan du angi en maksimal tidsavbrudd for jobben. Denne tidsavbruddet, hvis det er mindre enn prosjektets definerte tidsavbrudd, har forrang.

denne funksjonen kan brukes til å forhindre at den delte løperen blir overveldet av et prosjekt som har jobber med lang tidsavbrudd (for eksempel en uke).

når den ikke er konfigurert, overstyrer ikke løpere tidsavbruddet for prosjektet.

På GitLab.com, du kan ikke overstyre tidsavbruddet jobb for delte løpere og må bruke tidsavbruddet prosjekt definert.

for å angi maksimal tidsavbrudd for jobb:

1. i et prosjekt går du til Innstillinger >CI/CD> Løpere.
2. Velg din spesifikke løper for å redigere innstillingene.
3. Angi en verdi under Maksimal tidsavbrudd for jobb.
4. Velg Lagre endringer.

hvordan denne funksjonen fungerer:

Eksempel 1 – Runner timeout større enn prosjekt timeout

1. du angir maksimal timeout for en løper til 24 timer
2. DU setter CI/CD Timeout for et prosjekt til 2 timer
3. du starter en jobb
4. jobben, hvis den kjører lenger, ganger ut etter 2 timer

Eksempel 2 – Runner timeout ikke konfigurert

i
1. du setter ci/cd timeout for et prosjekt til 2 timer
2. du starter en jobb
3. jobben, HVIS DEN KJØRER Lenger, Ganger ut etter 2 timer

eksempel 3 – runner tidsavbrudd for en løper til 30 minutter

Vær forsiktig med sensitiv informasjon

med noen runner eksekutorer,hvis du kan kjøre en jobb på runner, kan du få full tilgang til filsystemet,og dermed noen kode det kjører samt token av løperen. Med delte løpere betyr dette at alle som kjører jobber på løperen, kan få tilgang til andres kode som kjører på therunner.

i tillegg, fordi du kan få tilgang til runner token, er det muligå lage en klone av en løper og sende inn falske jobber, for eksempel.ovennevnte unngås lett ved å begrense bruken av delte runnerson store offentlige GitLab-forekomster, kontrollere tilgangen til GitLab-forekomsten din og bruke sikrere runner-eksekutorer.

Forhindre løpere fra å avsløre sensitiv informasjon

du kan beskytte løpere slik at de ikke avslører sensitiv informasjon.Når en løper er beskyttet, velger løperen bare jobber som er opprettet på beskyttede grener eller beskyttede tagger,og ignorerer andre jobber.

for å beskytte eller oppheve beskyttelsen av en løper:

1. Gå til prosjektets Innstillinger > CI / CD og utvid Delen Løpere.
2. Finn løperen du vil beskytte eller oppheve beskyttelsen av. Kontroller at den er aktivert.
3. Klikk på blyant-knappen.
4. Sjekk Det Beskyttede alternativet.
5. Klikk På Lagre endringer.

Forks

når et prosjekt er forked, kopierer det innstillingene til jobbene som relateto det. Dette betyr at hvis du har delt løpere satt opp for et prosjekt og noen gafler som prosjektet, de delte løpere tjene jobber for dette prosjektet.

Angrepsvektorer i løpere

Nevnt kort tidligere, men følgende ting av løpere kan utnyttes.Vi er alltid på utkikk etter bidrag som kan redusere dissesikkerhetshensyn.

Tilbakestill runner registration token for et prosjekt

hvis du tror at et registration token for et prosjekt ble avslørt, bør du tilbakestille det. Et token kan brukes til å registrere en annen løper for prosjektet. Den nye runnermay da brukes til å oppnå verdiene av hemmelige variabler eller å klone prosjektkode.

for å tilbakestille token:

1. Gå til prosjektets Innstillinger > CI / CD.
2. Utvid Delen Generelle innstillinger for rørledninger.
3. Finn Feltet Runner token og klikk På Vis verdi-knappen.
4. Slett verdien og lagre skjemaet.
5. etter at siden er oppdatert, utvider Du Delen Runners settingsog sjekk registreringstoken – den skal endres.

fra nå av er det gamle token ikke lenger gyldig og registrerer ikkenoen nye løpere til prosjektet. Hvis du bruker verktøy for å klargjøre ogregistrere nye løpere, bør tokens som brukes i disse verktøyene oppdateres for å gjenspeile verdien av det nye token.

Bestem IP-adressen til en løper

DET kan være nyttig å vite IP-adressen til en løper, slik at du kan feilsøke problemer med den løperen. GitLab lagrer OG viser IP-adressen ved å vise KILDEN TIL HTTP-forespørsler det gjør Til GitLab når polling for jobber. Ip-adressen holdes alltid oppdatert, så hvis runner IP endrer detautomatisk oppdateringer i GitLab.

IP-adressen for delt løpere og spesifikke løpere kan bli funnet likegyldige steder.

Bestem IP-adressen til en delt løper

for å vise IP-adressen til en delt løper må du ha admintilgang Til GitLab-forekomsten. For å bestemme dette:

1. Besøk Admin-Området> Oversikt> Løpere.
2. Se etter løperen i tabellen, og du bør se en kolonne FOR IP-Adresse.

Bestem IP-adressen til en bestemt løper

for å finne IP-adressen til en løper for et bestemt prosjekt,må Du ha Eiertillatelser for prosjektet.

1. Gå til prosjektets Innstillinger > CI / CD og utvid Løpere-delen.
2. På detaljsiden bør DU se en rad FOR IP-Adresse.

Bruk tagger for å begrense antall jobber som bruker runner

du må sette opp en løper for å kunne kjøre alle de forskjellige typer jobber som det kan støte på på prosjektene det deles over. Dette ville være problematisk for store mengder prosjekter, hvis det ikke var for koder.

GitLab CI-koder er ikke Det Samme Som Git-koder. GitLab CI-koder er forbundet med løpere.Git-koder er knyttet til forpliktelser.

ved å merke en løper for de typer jobber den kan håndtere, kan du gjøre sureshared løpere vil bare kjøre jobbene de er utstyrt for å kjøre.

For Eksempel På GitLab har vi løpere merket med rails hvis de inneholder passende avhengigheter for å kjøre Rails test suiter.

når du registrerer en løper, er standard virkemåte å bare picktagged jobs.To hvis du endrer dette, må Du ha Eiertillatelser for prosjektet.

for å få en løper til å velge ukodede jobber:

1. Gå til prosjektets Innstillinger > CI / CD og utvid Løpere-delen.
2. Finn løperen du vil velge ukodede jobber, og sørg for at den er aktivert.
3. Klikk på blyant-knappen.
4. Sjekk Alternativet Kjør ukodede jobber.
5. Klikk På Lagre endringer-knappen for at endringene skal tre i kraft.

Nedenfor er noen eksempler på scenarier av forskjellige variasjoner.

runner runs only tagged jobs

følgende eksempler illustrerer den potensielle effekten av løperen som setto run only tagged jobs.

Eksempel 1:

1. løperen er konfigurert til å kjøre bare merkede jobber og hardocker taggen.
2. en jobb som har en hello – kode utføres og sitter fast.

Eksempel 2:

1. løperen er konfigurert til å kjøre bare merkede jobber og hardocker taggen.
2. en jobb som har en docker – kode kjøres og kjøres.

Eksempel 3:

1. løperen er konfigurert til å kjøre bare merkede jobber og hardocker taggen.
2. en jobb som ikke har noen koder definert, utføres og sitter fast.

runner har lov til å kjøre ukodede jobber

følgende eksempler illustrerer den potensielle effekten av at løperen blir setto run-merket og ukodede jobber.

Eksempel 1:

1. løperen er konfigurert til å kjøre ukodede jobber og hardocker – taggen.
2. en jobb som ikke har noen koder definert, utføres og kjøres.
3. en annen jobb som har endocker tag definert kjøres og kjøres.Eksempel 2:
   1. løperen er konfigurert til å kjøre ukodede jobber og har ingen tagger definert.
   2. en jobb som ikke har noen koder definert, utføres og kjøres.
   3. en annen jobb som har en docker tag definert er fast.

   Konfigurer runner-atferd med variabler

   du kan bruke ci / CD-variabler til å konfigurere runner Git-atferdglobalt eller for individuelle jobber:

   • GIT_STRATEGY

   GIT_SUBMODULE_STRATEGY

GIT_CHECKOUTGIT_CLEAN_FLAGS

4. GIT_FETCH_EXTRA_FLAGS

GIT_DEPTH(grunne kloning) GIT_CLONE_PATH(tilpassede byggekataloger)

du kan også bruke variabler for å konfigurere hvor mange ganger en runner forsøker bestemte stadier av jobbutførelse.

Git strategi

Versjonshistorikk
• Introdusert I GitLab 8.9 som en eksperimentell funksjon.
• GIT_STRATEGY=none krever GitLab Runner v1. 7+.

Du kan angi GIT_STRATEGY brukes til å hente innholdet i depotet, entenglobalt eller per-jobb i variables – delen:

variables: GIT_STRATEGY: clone

det er tre mulige verdier: clonefetch og none. Hvis ikke angitt,bruker jobber innstillingen for prosjektets pipeline.

clone er det tregeste alternativet. Det kloner depotet fra bunnen av for everyjob, slik at den lokale arbeidskopien alltid er uberørt.Hvis en eksisterende worktree er funnet, er det fjernet før kloning.

fetch er raskere når den gjenbruker den lokale arbeidskopien (faller tilbake til clone hvis den ikke finnes). git cleanbrukes til å angre endringer som er gjort av lastjob, og git fetch brukes til å hente inn innlegg som er gjort etter at den siste jobben ble kjørt.

men fetch krever tilgang til forrige worktree. Dette workswell når du bruker shell eller docker byrder fordi thesetry å bevare worktrees og prøve å gjenbruke dem som standard.

dette har begrensninger når Du bruker Docker Machine eksekutor.

det virker ikke for kubernetes eksekutor,men det finnes et funksjonsforslag.kubernetes eksekutor kloner alltid i en midlertidig katalog.

En git-strategi for none bruker også den lokale arbeidskopien, men hopper over Alle Gitoperasjoner som Normalt gjøres Av GitLab. GitLab Runner pre-clone skript er også hoppet over, hvis det finnes. Denne strategien kan bety at du må legge tilfetch ogcheckout – kommandoene til.gitlab-ci.yml – skriptet.

Den kan brukes til jobber som opererer utelukkende på artefakter, som en distribusjonsjobb.Git repository data kan være til stede, men det er sannsynligvis utdatert. Du bør barestole på filer brakt inn i den lokale arbeidskopien fra cache eller artefakter.

Git submodule strategi

Krever GitLab Runner v1.10+.

GIT_SUBMODULE_STRATEGY variabelen brukes til å kontrollere om / hvordan Gitsubmodules er inkludert når du henter koden før en build. Du kan angi demglobalt eller per-jobb ivariables – delen.

Det er tre mulige verdier: nonenormal og recursive:

• none betyr at submoduler er ikke inkludert når du henter Projectcode. Dette er standard, som samsvarer med virkemåten pre-v1.10.

• normal betyr at bare de øverste nivå submoduler er inkludert. Det tilsvarer:

  git submodule syncgit submodule update --init

• recursive betyr at alle submoduler (inkludert submoduler av submoduler)er inkludert. Denne funksjonen trenger Git v1.8.1 og nyere. Når du bruker aGitLab Runner med en eksekutor som ikke er basert På Docker, må Du sørge For At Git-versjonen oppfyller dette kravet. Det tilsvarer:

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

for at denne funksjonen skal fungere riktig, må undermodulene konfigureres(i.gitmodules) med ENTEN:

• HTTP(S) URL til et offentlig tilgjengelig depot, eller
• en relativ bane til et annet depot på samme gitlab-server. Se thegit submodules dokumentasjon.

Git checkout

GIT_CHECKOUT variabelen kan brukes når GIT_STRATEGY er satt til entenclone eller fetch for å angi om en git checkout skal kjøres. Hvis notspecified, er det som standard sant. Du kan angi dem globalt eller per jobb ivariables – delen.

hvis satt til false, løperen:

• når du gjørfetch – oppdaterer depotet og forlater arbeidskopien på gjeldende revisjon,
• når du gjørclone – kloner depotet og forlater arbeidskopien på standardgrenen.

Hvis GIT_CHECKOUT er satt til true, fungerer beggeclone ogfetch på samme måte.Løperen sjekker ut arbeidskopien av en revisjon relatedto CI rørledningen:

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

git rene flagg

GIT_CLEAN_FLAGS variabelen brukes til å kontrollere standard oppførsel avgit clean etter å ha sjekket ut kildene. Du kan angi det globalt eller per jobb ivariables – delen.

GIT_CLEAN_FLAGS godtar alle mulige alternativer forgit cleankommandoen.

git clean er deaktivert hvis GIT_CHECKOUT: "false" er spesifisert.

Hvis GIT_CLEAN_FLAGS er:

• ikke spesifisert,git clean flagg standard til-ffdx.
• Gitt verdiennonegit clean utføres ikke.

For eksempel:

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

Git hente ekstra flagg

variabelenGIT_FETCH_EXTRA_FLAGS brukes til å kontrollere oppførselen til git fetch. Du kan angi det globalt eller per jobb ivariables – delen.

GIT_FETCH_EXTRA_FLAGS godtar alle valg avgit fetch kommandoen. MenGIT_FETCH_EXTRA_FLAGS flagg legges til etter standardflaggene som ikke kan endres.

standardflaggene er:

• GIT_DEPTH.
• listen over refspecs.
• en fjernkontroll kalt origin.

hvisGIT_FETCH_EXTRA_FLAGS er:

• ikke spesifisert,git fetch flagg standard til--prune --quiet sammen med standardflaggene.
• Gitt verdiennonegit fetch utføres bare med standardflaggene.

standardflaggene er for eksempel --prune --quiet, slik at du kan gjøre git fetch mer detaljert ved å overstyre dette med bare --prune:

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

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

Hvor$REFSPECSer en verdi gitt til løperen internt Av GitLab.

Grunne kloning

du kan angi dybden for henting og kloning ved hjelp av GIT_DEPTHGIT_DEPTH gjør en grunne klone av depotet og kan øke hastigheten betydelig cloning.It kan være nyttig for repositories med et stort antall inger eller gamle, store binærfiler. Verdien overføres til git fetch og git clone.

I GitLab 12.0 og senere har nyopprettede prosjekter automatisk adefault git depth verdien av 50.

hvis du bruker en dybde på 1 og har en kø av jobber eller retryjobs, kan jobber mislykkes.

Git henting og kloning er basert på en ref, for eksempel en gren navn, så runnerscan ‘ t klone en bestemt commit SHA. Hvis flere jobber er i køen, eller du prøver på nytt en gammel jobb, må forpliktelsen som skal testes, være innenfor den git-historien som er klonet. Innstilling for liten verdi forGIT_DEPTH kan gjøre det umulig å kjøre disse gamle innleggene ogunresolved reference vises injob logger. Du bør da revurdere å endre GIT_DEPTH til en høyere verdi.

Jobber som er avhengige av git describe fungerer kanskje ikke riktig nårGIT_DEPTH isset siden bare en del Av Git-historien er til stede.

for å hente eller klone bare de siste 3 forpliktelsene:

variables: GIT_DEPTH: "3"

du kan angi det globalt eller per jobb ivariables-delen.

Tilpassede bygge kataloger

Som standard kloner GitLab Runner depotet i en unik subpath av$CI_BUILDS_DIR katalogen. Prosjektet kan imidlertid kreve koden i aspecific-katalogen (Gå prosjekter, For eksempel). I så fall kan du spesifiser GIT_CLONE_PATH variabel for å fortelle løperen katalogen for å klone derepository i:

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

GIT_CLONE_PATHmå alltid være innenfor$CI_BUILDS_DIR. Katalogen satt i$CI_BUILDS_DIRer avhengig av eksekutor og konfigurasjon av løpere.builds_dirsetting.

dette kan bare brukes når custom_build_dir er aktivert i therunners konfigurasjon.Dette er standardkonfigurasjonen fordocker ogkubernetes – eksekutorer.

Håndtering av samtidighet

en eksekutor som bruker en samtidighet større enn 1 kan føre til feil. Flere jobber kan fungere på samme katalog hvis builds_dirdeles mellom jobber.

løperen prøver ikke å forhindre denne situasjonen. Det er opp til administratorand utviklere å overholde kravene til runner konfigurasjon.

for å unngå dette scenariet, kan du bruke en unik bane i $CI_BUILDS_DIR, fordi runnerexposes to ekstra variabler som gir en unik ID av samtidighet:

• $CI_CONCURRENT_ID: Unik ID for alle jobber som kjører innenfor gitt eksekutor.
• $CI_CONCURRENT_PROJECT_ID: Unik ID for alle jobber som kjører innenfor gitt eksekutor og prosjekt.

den mest stabile konfigurasjonen som skal fungere godt i alle scenarier og på alle executoris å bruke $CI_CONCURRENT_ID i GIT_CLONE_PATH. For eksempel:

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

$CI_CONCURRENT_PROJECT_IDskal brukes sammen med$CI_PROJECT_PATHsom$CI_PROJECT_PATHdiv > gir en bane til et depot. Det vil sigroup/subgroup/project. For eksempel:

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

Nestede baner

verdien av GIT_CLONE_PATH utvides en gang og hekkende variableswithin støttes ikke.

for eksempel definerer du begge variablene nedenfor i.gitlab-ci.yml fil:

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

verdien avGIT_CLONE_PATHutvides en gang til$CI_BUILDS_DIR/go/src/namespace/project, og resulterer i feilfordi$CI_BUILDS_DIRdiv > er ikke utvidet.

Jobb stadier forsøk

Du kan angi antall forsøk som den løpende jobben prøver å utførefølgende trinn:

standardinnstillingen Er ett enkelt forsøk.

Eksempel:

variables: GET_SOURCES_ATTEMPTS: 3

Du kan angi dem globalt eller per jobb ivariables-delen.

systemanrop er ikke tilgjengelig på GitLab.com delt løpere

GitLab.com delt løpere kjøre På CoreOS. Dette betyr at du ikke kan bruke noen systemanrop, som getlogin, fra C – standardbiblioteket.

Artifakt og cache innstillinger

Innstillinger For Artefakt og hurtigbuffer kontrollerer komprimeringsforholdet mellom artefakter og hurtigbuffer.Bruk disse innstillingene til å angi størrelsen på arkivet som produseres av en jobb.

• på et tregt nettverk kan opplastinger være raskere for mindre arkiver.
• på et raskt nettverk hvor båndbredde og lagring ikke er et problem, kan opplastinger være raskere ved å bruke det raskeste komprimeringsforholdet, til tross for at arkivet som produseres er større.

For GitLab-Sider for å serverehttp-Rekkeviddeforespørsler, bør artefakter brukeARTIFACT_COMPRESSION_LEVEL: fastest – innstillingen, som bare ukomprimert zip-arkivstøtte denne funksjonen.

en meter kan også aktiveres for å gi overføringshastigheten for opplastinger og nedlastinger.

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"