• typer av löpare
  • delade löpare
    • hur delade löpare väljer jobb
    • aktivera delade löpare
    • inaktivera delade löpare
  • Grupplöpare
    • skapa en grupplöpare
    • Visa och hantera grupplöpare
    • pausa eller ta bort en grupplöpare
  • specifika löpare
    • skapa en specifik löpare
    • aktivera en specifik löpare för ett specifikt projekt
    • förhindra att en specifik löpare aktiveras för andra projekt
• rensa löparens cache manuellt
• Ställ in maximal tidsgräns för jobb för en löpare
• var försiktig med känslig information
  • förhindra att löpare avslöjar känslig information
  • gafflar
  • attackvektorer i löpare
  • Återställ löparens registreringstoken för ett projekt
• Bestäm IP-adressen för en löpare
  • Bestäm IP-adressen för en delad löpare
  • /li>
  • bestäm IP-adressen för en specifik löpare
• Använd taggar för att begränsa antalet jobb med löparen
  • löpare kör bara taggade jobb
  • runner är tillåtet att köra otaggade jobb
• konfigurera löpare beteende med variabler
  • Git strategi
  • git submodule strategi
  • git kassan
  • git rena flaggor
  • Git hämta extra flaggor
  • Grunt kloning
  • anpassade bygga kataloger
    • hantering samtidighet
    • kapslade sökvägar
  • jobbsteg försök
• systemanrop inte tillgängligt på GitLab.com delade löpare
• Artifact och cache-inställningar

i GitLab CI/CD kör löpare koden definierad i.gitlab-ci.yml.En löpare är en lätt, mycket skalbar agent som plockar upp ett CI-jobb genomkoordinator API för GitLab CI/CD, kör jobbet och skickar resultatet tillbaka till GitLab-instansen.

löpare skapas av en administratör och är synliga i GitLab-användargränssnittet.Löpare kan vara specifika för vissa projekt eller tillgängliga för alla projekt.

denna dokumentation är inriktad på att använda löpare i GitLab.Om du behöver installera och konfigurera GitLab Runner, seethe GitLab Runner dokumentation.

typer av löpare

i GitLab-gränssnittet finns tre typer av löpare, baserat på vem du vill ha åtkomst:

• delade löpare är tillgängliga för alla grupper och projekt i en GitLab-instans.
• grupplöpare är tillgängliga för alla projekt och undergrupper i en grupp.
• specifika löpare är associerade med specifika projekt.Vanligtvis används specifika löpare för ett projekt i taget.

delade löpare

delade löpare är tillgängliga för alla projekt i en GitLab-instans.

använd delade löpare när du har flera jobb med liknande krav. I stället för att ha flera löpare på tomgång för många projekt kan du ha några löpare som hanterar flera projekt.

Om du använder en självhanterad instans av GitLab:

• administratören kan installera och registrera delade löpare genom att gå till projektets Inställningar> CI / CD, expandera avsnittet löpare och klicka på Visa installationsanvisningar för löpare.Dessa instruktioner finns också i dokumentationen.
• administratören kan också konfigurera ett maximalt antal delade löpare pipeline minuter för varje grupp.

Om du använder GitLab.com:

• Du kan välja från en lista över delade löpare som GitLab upprätthåller.
• de delade löparna förbrukar pipelines minutesincluded med ditt konto.

hur delade löpare väljer jobb

delade löpare bearbetar jobb genom att använda en kö för rättvis användning. Denna kö förhindrarprojekt från att skapa hundratals jobb och använda alla tillgängliga delade löparresurser.

algoritmen för rättvis användningskö tilldelar jobb baserat på de projekt som har det minsta antalet jobb som redan körs på delade löpare.

exempel 1

om dessa jobb är i kön:

• jobb 1 för Projekt 1
• Jobb 2 för Projekt 1
• jobb 3 för Projekt 1
• jobb 4 för projekt 2
• jobb 5 för projekt 2
• jobb 6 för Projekt 3

algoritmen för rättvis användning tilldelar jobb i följande ordning:

1. Job 1 väljs först, eftersom det har det lägsta jobbnumret från projekt utan löpande jobb (det vill säga alla projekt).
2. jobb 4 är nästa, eftersom 4 Nu är det lägsta jobbnumret från projekt utan löpande jobb (projekt 1 har ett jobb som körs).
3. jobb 6 är nästa, eftersom 6 Nu är det lägsta jobbnumret från projekt utan löpande jobb (projekt 1 och 2 har jobb som körs).
4. Jobb 2 är nästa, eftersom av projekt med det lägsta antalet jobb som körs (var och en har 1) är det det lägsta jobbnumret.
5. jobb 5 är nästa, eftersom Projekt 1 nu har 2 jobb som körs och Jobb 5 är det lägsta återstående jobbnumret mellan projekt 2 och 3.
6. äntligen är Jobb 3 … eftersom det är det enda jobbet kvar.

exempel 2

om dessa jobb är i kön:

• jobb 1 för Projekt 1
• Jobb 2 för Projekt 1
• jobb 3 för Projekt 1
• jobb 4 för projekt 2
• jobb 5 för projekt 2
• jobb 6 för Projekt 3

algoritmen för rättvis användning tilldelar jobb i följande ordning:

1. Job 1 väljs först, eftersom det har det lägsta jobbnumret från projekt utan löpande jobb (det vill säga alla projekt).
2. Vi avslutar jobb 1.
3. Jobb 2 är nästa, för att ha avslutat jobb 1 har alla projekt 0 jobb som körs igen och 2 är det lägsta tillgängliga jobbnumret.
4. jobb 4 är nästa, för med projekt 1 som kör ett jobb är 4 det lägsta antalet från projekt som inte kör några jobb (projekt 2 och 3).
5. Vi avslutar jobb 4.
6. jobb 5 är nästa, för att ha avslutat jobb 4, Projekt 2 har inga jobb som körs igen.
7. jobb 6 är nästa, eftersom Projekt 3 är det enda projektet kvar utan löpande jobb.
8. slutligen väljer vi Jobb 3 … eftersom det igen är det enda jobbet kvar.

aktivera delade löpare

på GitLab.com, delade löpare är aktiverade i alla projekt bydefault.

på självhanterade instanser av GitLab måste en administratör installeraoch registrera dem.

Du kan också aktivera delade löpare för enskilda projekt.

för att aktivera delade löpare:

1. gå till projektets Inställningar > CI/CD och expandera avsnittet löpare.
2. välj Aktivera delade löpare för det här projektet.

inaktivera delade löpare

Du kan inaktivera delade löpare för enskilda projekt eller för grupper.Du måste ha Ägarbehörigheter för projektet eller gruppen.

för att inaktivera delade löpare för ett projekt:

1. gå till projektets Inställningar > CI/CD och expandera avsnittet löpare.
2. i området delade löpare väljer du aktivera delade löpare för det här projektet så att växeln är gråtonad.

delade löpare inaktiveras automatiskt för ett projekt:

• Om inställningen delade löpare för den överordnade gruppen är inaktiverad och
• om åsidosättande av denna inställning inte är tillåten på projektnivå.

för att inaktivera delade löpare för en grupp:

1. gå till gruppens inställningar > CI/CD och expandera avsnittet löpare.
2. i området delade löpare stänger du av växeln aktivera delade löpare för den här gruppen.om du vill tillåta att delade löpare aktiveras för enskilda projekt eller undergrupper klickar du på Tillåt projekt och undergrupper för att åsidosätta gruppinställningen.

Grupplöpare

använd grupplöpare när du vill att alla projekt i en grupp ska ha tillgång till en uppsättning löpare.

Grupplöpare bearbetar jobb genom att använda en först in, först ut (FIFO) kö.

skapa en grupplöpare

Du kan skapa en grupplöpare för din självhanterade GitLab-instans eller för GitLab.com.Du måste ha Ägarbehörigheter för gruppen.

för att skapa en grupplöpare:

1. installera GitLab Runner.
2. gå till den grupp du vill få löparen att arbeta för.
3. gå till Inställningar > CI/CD och expandera avsnittet löpare.
4. notera webbadressen och token.
5. registrera löparen.

Visa och hantera grupplöpare

Du kan visa och hantera alla löpare för en grupp, dess undergrupper och projekt.Du kan göra detta för din självhanterade GitLab-instans eller för GitLab.com.Du måste ha Ägarbehörigheter för gruppen.

1. gå till gruppen där du vill se löparna.
2. gå till Inställningar > CI/CD och expandera avsnittet löpare.

3. följande fält visas.

   attribut	beskrivning
   Typ	ett eller flera av följande tillstånd: delad, grupp, specifik, låst eller pausad
   Runner token	Token som används för att identifiera löparen och som löparen använder för att kommunicera med GitLab-instansen
   beskrivning	beskrivning som ges till löparen när den skapades
   Version	GitLab Runner version
   IP-adress	IP-adress för den värd som löparen är registrerad på
   projekt	antalet projekt som löparen tilldelas
   jobb	totalt antal jobb som körs av löparen
   taggar	taggar associerade med löparen
   Senaste kontakt	tidsstämpel som indikerar när GitLab-instansen senast kontaktade löparen

från den här sidan kan du redigera, pausa och ta bort löpare från gruppen, dess undergrupper och projekt.

pausa eller ta bort en grupplöpare

Du kan pausa eller ta bort en grupplöpare för din självhanterade GitLab-instans eller för GitLab.com.Du måste ha Ägarbehörigheter för gruppen.

1. gå till den grupp du vill ta bort eller pausa löparen för.
2. gå till Inställningar > CI/CD och expandera avsnittet löpare.
3. Klicka på Pausa eller ta bort löpare.
   • Om du pausar en grupplöpare som används av flera projekt pausar löparen för alla projekt.
   • från gruppvyn kan du inte ta bort en löpare som har tilldelats mer än ett projekt.Du måste ta bort det från varje projekt först.
4. Klicka på OK i bekräftelsedialogrutan.

specifika löpare

använd specifika löpare när du vill använda löpare för specifika projekt. Till exempel, när du har:

• jobb med specifika krav, som en distribuera jobb som kräver referenser.
• projekt med mycket CI-aktivitet som kan dra nytta av att vara skild från andra löpare.

Du kan ställa in en specifik löpare som ska användas av flera projekt. Specifika runnersmåste aktiveras för varje projekt uttryckligen.

specifika löpare bearbetar jobb genom att använda en först in, först ut (FIFO) kö.

skapa en specifik löpare

Du kan skapa en specifik löpare för din självhanterade GitLab-instans eller för GitLab.com.Du måste ha Ägarbehörigheter för projektet.

för att skapa en specifik löpare:

1. installera löpare.
2. gå till projektets Inställningar > CI/CD och expandera avsnittet löpare.
3. notera webbadressen och token.
4. registrera löparen.

aktivera en specifik löpare för ett specifikt projekt

en specifik löpare är tillgänglig i projektet Den skapades för. En administratör kan aktivera en specifik löpare för att ansöka om ytterligare projekt.

• Du måste ha Ägarbehörigheter för projektet.
• den specifika löparen får inte låsas.

för att aktivera eller inaktivera en specifik löpare för ett projekt:

1. gå till projektets Inställningar > CI/CD och expandera avsnittet löpare.
2. Klicka på Aktivera för det här projektet eller inaktivera för det här projektet.

förhindra att en viss löpare aktiveras för andra projekt

Du kan konfigurera en specifik löpare så att den är ”låst” och inte kan aktiveras för andra projekt.Den här inställningen kan aktiveras när du först registrerar en löpare, men kan också ändras senare.

för att låsa eller låsa upp en löpare:

1. gå till projektets Inställningar > CI/CD och expandera avsnittet löpare.
2. hitta löparen du vill låsa eller låsa upp. Se till att den är aktiverad.
3. Klicka på knappen penna.
4. markera alternativet Lås till aktuella projekt.
5. Klicka på Spara ändringar.

rensa runner-cachen manuellt

läs rensa cacheminnet.

Ställ in maximal timeout för en löpare

för varje löpare kan du ange en maximal timeout för jobbet. Denna timeout, om mindre än den projektdefinierade timeout, har företräde.

den här funktionen kan användas för att förhindra att din delade löpare blir överväldigad av ett projekt som har jobb med lång timeout (till exempel en vecka).

När den inte är konfigurerad åsidosätter inte löpare projektets timeout.

på GitLab.com, Du kan inte åsidosätta timeout för jobb för delade löpare och måste använda den projektdefinierade timeout.

för att ställa in maximal timeout för jobbet:

1. i ett projekt, gå till Inställningar >CI/CD > löpare.
2. Välj din specifika löpare för att redigera inställningarna.
3. ange ett värde under maximal tidsgräns för jobb.
4. välj Spara ändringar.

hur den här funktionen fungerar:

exempel 1 – timeout för löpare större än timeout för projekt

1. Du ställer in maximal timeout för jobb för en löpare till 24 timmar
2. Du ställer in CI/CD – Timeout för ett projekt till 2 timmar
3. du startar ett jobb
4. jobbet, om det körs längre, timeout efter 2 timmar

exempel 2 – timeout för löpare inte konfigurerad

1. du tar bort det maximala inställning av timeout för jobb från en löpare
2. Du ställer in timeout för CI/CD för ett projekt till 2 timmar
3. du startar ett jobb
4. jobbet, om det körs längre, timeout efter 2 timmar

exempel 3-löpare timeout mindre än projekt timeout

1. Du ställer in maximal jobb timeout för en löpare till 30 minuter
2. Du ställer in CI/CD Timeout för ett projekt till 2 timmar
3. du startar ett jobb
4. jobbet, om du kör längre, tider ut efter 30 minuter

var försiktig med känslig information

med några löpare exekutörer,om du kan köra ett jobb på löparen, kan du få full tillgång till filsystemet,och därmed någon kod det körs liksom token av löparen. Med delade löpare betyder det att alla som kör jobb på löparen kan komma åt någon annans kod som körs på therunner.

dessutom, eftersom du kan få tillgång till runner token, är det möjligtatt skapa en klon av en löpare och skicka in falska jobb, till exempel.

ovanstående undviks lätt genom att begränsa användningen av delade runnerson stora offentliga GitLab-instanser, kontrollera åtkomst till din GitLab-instans och använda säkrare runner-exekutörer.

förhindra löpare från att avslöja känslig information

Du kan skydda löpare så att de inte avslöjar känslig information.När en löpare är skyddad väljer löparen jobb som skapats påskyddade grenar eller skyddade taggar och ignorerar andra jobb.

för att skydda eller avskydda en löpare:

1. gå till projektets Inställningar > CI/CD och expandera avsnittet löpare.
2. hitta löparen du vill skydda eller avskydda. Se till att den är aktiverad.
3. Klicka på knappen penna.
4. kontrollera det skyddade alternativet.
5. Klicka på Spara ändringar.

gafflar

När ett projekt kluven, kopierar inställningarna för de jobb som relateto det. Detta innebär att om du har delat löpare som inrättats för ett projekt och någon gafflar som projekt, delade löpare tjänar jobb i detta projekt.

attackvektorer i löpare

nämns kort tidigare, men följande saker av löpare kan utnyttjas.Vi letar alltid efter bidrag som kan mildra dessa säkerhetsaspekter.

Återställ runner – registreringstoken för ett projekt

om du tror att en registreringstoken för ett projekt avslöjades, bör duåterställ det. En token kan användas för att registrera en annan löpare för projektet. Den nya runnerkan sedan användas för att erhålla värdena för hemliga variabler eller för att klona projektkod.

för att återställa token:

1. gå till projektets Inställningar > CI/CD.
2. expandera avsnittet Allmänna pipelinesinställningar.
3. hitta fältet Runner token form och klicka på knappen Reveal value.
4. ta bort värdet och spara formuläret.
5. när sidan har uppdaterats, expandera avsnittet löpare Inställningaroch kontrollera registreringstoken-den ska ändras.

Från och med nu är den gamla token inte längre giltig och registrerar inte några nya löpare till projektet. Om du använder några verktyg för att tillhandahålla och registrera nya löpare, bör tokens som används i dessa verktyg uppdateras för att återspegla värdet av den nya token.

Bestäm IP-adressen för en löpare

det kan vara användbart att känna till IP-adressen för en löpare så att du kan felsöka frågor med den löparen. GitLab lagrar och visar IP-adressen genom att visakällan till HTTP-förfrågningarna som den gör till GitLab när du pollar för jobb. IP-adressen hålls alltid uppdaterad så om löparens IP ändras uppdateras den automatiskt i GitLab.

IP-adressen för delade löpare och specifika löpare kan hittas iolika platser.

Bestäm IP-adressen för en delad löpare

för att visa IP-adressen för en delad löpare måste du ha administratörsbehörighet till GitLab-instansen. För att bestämma detta:

1. besök adminområdet > översikt > löpare.
2. leta efter löparen i tabellen och du bör se en kolumn för IP-adress.

Bestäm IP-adressen för en specifik löpare

För att hitta IP-adressen för en löpare för ett specifikt projekt måste du ha Ägarbehörigheter för projektet.

1. gå till projektets Inställningar > CI/CD och expandera avsnittet löpare.
2. på informationssidan ska du se en rad för IP-adress.

använd taggar för att begränsa antalet jobb med löparen

Du måste ställa in en löpare för att kunna köra alla olika typer av jobb som den kan stöta på i de projekt den delas över. Detta skulle vara problematiskt för stora mängder projekt, om det inte var för taggar.

GitLab CI-taggar är inte samma som Git-taggar. GitLab CI-taggar är associerade med löpare.Git-taggar är associerade med åtaganden.

genom att märka en löpare för de typer av jobb den kan hantera kan du göra sureshared löpare kommer bara att köra de jobb de är utrustade för att köra.

till exempel på GitLab har vi löpare taggade med rails om de innehåller lämpliga beroenden för att köra Rails testsviter.

När du registrerar en löpare är dess standardbeteende att endast picktagged jobs.To ändra detta, du måste ha Ägarbehörigheter för projektet.

att göra en löpare plocka untagged jobb:

1. gå till projektets Inställningar > CI/CD och expandera avsnittet löpare.
2. hitta löparen du vill välja otaggade jobb och se till att den är aktiverad.
3. Klicka på knappen penna.
4. markera alternativet Kör otaggade jobb.
5. Klicka på knappen Spara ändringar för att ändringarna ska träda i kraft.

Nedan följer några exempel på scenarier med olika variationer.

runner Kör bara taggade jobb

följande exempel illustrerar den potentiella effekten av att löparen bara är taggade jobb.

exempel 1:

1. löparen är konfigurerad för att endast köra taggade jobb och har taggen docker.
2. ett jobb som har enhello taggen körs och fastnar.

exempel 2:

1. löparen är konfigurerad för att endast köra taggade jobb och har taggen docker.
2. ett jobb som har endocker taggen körs och körs.

exempel 3:

1. löparen är konfigurerad för att endast köra taggade jobb och har taggen docker.
2. ett jobb som inte har några definierade taggar körs och fastnar.

runner får köra otaggade jobb

följande exempel illustrerar den potentiella effekten av att löparen är setto run-taggade och otaggade jobb.

exempel 1:

1. löparen är konfigurerad för att köra otaggade jobb och har taggen docker.
2. ett jobb som inte har några definierade taggar körs och körs.
3. ett andra jobb som har en docker taggen definierad körs och körs.

exempel 2:

1. löparen är konfigurerad för att köra otaggade jobb och har inga taggar definierade.
2. ett jobb som inte har några definierade taggar körs och körs.
3. ett andra jobb som har en docker tagg definierad har fastnat.

konfigurera löparbeteende med variabler

Du kan använda CI/CD-variabler för att konfigurera löpare Git behaviorglobally eller för enskilda jobb:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (Grunt kloning)
• GIT_CLONE_PATH (anpassade byggkataloger)

Du kan också använda variabler för att konfigurera hur många gånger en körareförsöker vissa stadier av jobbkörning.

Git-strategi

Du kan ställa in GIT_STRATEGY som används för att hämta förvarets innehåll, antingenglobalt eller per jobb i avsnittet variables:

variables: GIT_STRATEGY: clone

det finns tre möjliga värden: clonefetch och none. Om de lämnas ospecificerade använder jobb projektets pipeline-inställning.

clone är det långsammaste alternativet. Det klonar förvaret från början för varje jobb, vilket säkerställer att den lokala arbetskopian alltid är orörd.Om ett befintligt arbetsträd hittas tas det bort innan kloning.

fetch är snabbare eftersom den återanvänder den lokala arbetskopian (faller tillbaka till cloneom den inte existerar). git clean används för att ångra alla ändringar som gjorts av lastjob, och git fetch används för att hämta åtaganden som gjorts efter det senaste jobbet sprang.

men fetch kräver åtkomst till föregående arbetsträd. Detta fungerar bra när du använder exekutören shell eller docker eftersom dessa försök att bevara arbetsträd och försöka återanvända dem som standard.

detta har begränsningar när du använder Docker Machine executor.

det fungerar inte förkubernetes exekutör,men det finns ett funktionsförslag.kubernetes exekutören klonar alltid i en tillfällig katalog.

en Git-strategi för none återanvänder också den lokala arbetskopian, men hoppar över alla Gitoperationer som normalt görs av GitLab. GitLab Runner pre-clone-skript hoppas också över, om de finns. Denna strategi kan innebära att du måste lägga till fetch och checkout kommandontill ditt .gitlab-ci.yml skript.

det kan användas för jobb som uteslutande fungerar på artefakter, som ett distributionsjobb.Git-lagringsdata kan vara närvarande, men det är troligt inaktuellt. Du borde baralita på filer som tagits in i den lokala arbetskopian från cache eller artefakter.

git submodule strategi

kräver GitLab Runner v1.10+.

GIT_SUBMODULE_STRATEGY variabel används för att styra om / hur Gitsubmoduler ingår när du hämtar koden före en build. Du kan ställa in demglobalt eller per jobb i avsnittet variables.

det finns tre möjliga värden: nonenormal och recursive:

• none betyder att submoduler ingår inte när du hämtar Projectcode. Detta är standardvärdet som matchar beteendet före v1.10.

• normal betyder att endast submoduler på toppnivå ingår. Det är likvärdigt med:

  git submodule syncgit submodule update --init

• recursive betyder att alla submoduler (inklusive submoduler av submoduler)ingår. Den här funktionen behöver Git v1.8. 1 och senare. När du använder aGitLab Runner med en exekutör som inte är baserad på Docker, se till att Git-versionenuppfyller det kravet. Det motsvarar:

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

för att den här funktionen ska fungera korrekt måste undermodulerna konfigureras(i .gitmodules) med antingen:

• HTTP(S) URL för ett offentligt tillgängligt arkiv, eller
• en relativ sökväg till ett annat arkiv på samma GitLab-server. Se dokumentationen för git-undermoduler.

git kassan

variabeln GIT_CHECKOUT kan användas när GIT_STRATEGY är inställd på antingenclone eller fetch för att ange om en git checkout ska köras. Om intespecificerat är det som standard sant. Du kan ställa in dem globalt eller per jobb i avsnittetvariables.

Om satt tillfalse, löparen:

• när du gör fetch – uppdaterar förvaret och lämnar arbetskopian påden aktuella revisionen,
• när du gör clone – klonar förvaret och lämnar arbetskopian pådefault-grenen.

om GIT_CHECKOUT är inställt på true, fungerar både clone och fetch på samma sätt.Löparen kontrollerar arbetskopian av en revision relaterad till CI-rörledningen:

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"