• Tipi di corridori
  • Condivisa corridori
    • Come condiviso corridori pick posti di lavoro
    • Abilita condiviso corridori
    • Disattiva condiviso corridori
  • Gruppo podisti
    • Creare un gruppo di runner
    • Visualizzare e gestire gruppo di corridori
    • Sospendere o rimuovere un gruppo di runner
  • Specifiche corridori
    • Creare una specifica runner
    • Attivare una specifica runner per un progetto specifico
    • Evitare che un determinato corridore viene attivato per altri progetti
• cancellare Manualmente il corridore cache
• Impostare il numero massimo di lavoro di timeout per un corridore
• fare attenzione con informazioni sensibili
  • Evitare di corridori da rivelare informazioni sensibili
  • Forche
  • i vettori di Attacco nei corridori
  • Ripristina il corridore token di registrazione per un progetto
• Determinare l’indirizzo IP di un corridore
  • Determinare l’indirizzo IP di un comune runner
  • Determinare l’indirizzo IP di un determinato runner
• Utilizzare i tag per limitare il numero di posti di lavoro utilizzando il corridore
  • corridore corre solo tagged posti di lavoro
  • runner è consentita l’esecuzione di posti di lavoro senza tag
• Configurare runner comportamento con le variabili
  • Git strategia
  • Git submodule strategia
  • Git checkout
  • Git pulito flag
  • Git fetch extra flag
  • Superficiale clonazione
  • Custom build directory
    • Gestione di concorrenza
    • Annidati percorsi
  • stage tentativi
• chiamate di Sistema non disponibili GitLab.com condiviso corridori
• Artefatto e le impostazioni della cache

In GitLab CI/CD, corridori eseguire il codice definito in .gitlab-ci.yml.Un runner è un agente leggero e altamente scalabile che preleva un lavoro CI attraverso l’API coordinatrice di GitLab CI / CD, esegue il lavoro e invia il risultato all’istanza GitLab.

I runners sono creati da un amministratore e sono visibili nell’interfaccia utente di GitLab.I corridori possono essere specifici per determinati progetti o disponibili per tutti i progetti.

Questa documentazione è focalizzata sull’utilizzo di runners in GitLab.Se è necessario installare e configurare GitLab Runner, consultare la documentazione di GitLab Runner.

Tipi di corridori

Nell’interfaccia utente di GitLab ci sono tre tipi di corridori, in base a chi si desidera avere accesso:

• I corridori condivisi sono disponibili per tutti i gruppi e progetti in un’istanza di GitLab.
• I corridori di gruppo sono disponibili per tutti i progetti e sottogruppi di un gruppo.
• Corridori specifici sono associati a progetti specifici.In genere, i corridori specifici vengono utilizzati per un progetto alla volta.

Corridori condivisi

I corridori condivisi sono disponibili per ogni progetto in un’istanza GitLab.

Usa runners condivisi quando hai più lavori con requisiti simili. Piuttosto thanhaving corridori multipli al minimo per molti progetti, Lei può avere alcuni corridori che handlemultiple progetti.

Se si utilizza un’istanza autogestita di GitLab:

• L’amministratore può installare e registrare runners condivisi accedendo alle Impostazioni del progetto> CI/CD, espandendo la sezione Runners e facendo clic su Mostra istruzioni per l’installazione di runner.Queste istruzioni sono disponibili anche nella documentazione.
• L’amministratore può anche configurare un numero massimo di minuti di pipeline runner condivisi per ogni gruppo.

Se si utilizza GitLab.com:

• È possibile selezionare da un elenco di corridori condivisi che GitLab mantiene.
• I corridori condivisi consumano le pipeline minutesincluded con il tuo account.

Come i runners condivisi selezionano i job

I runners condivisi elaborano i job utilizzando una coda di fair usage. Questa coda impedisce ai progetti di creare centinaia di lavori e utilizzare tutte le risorse runner condivise disponibili.

L’algoritmo fair usage queue assegna i lavori in base ai progetti che hanno il minor numero di lavori già in esecuzione su runners condivisi.

Esempio 1

Se questi posti di lavoro sono in coda:

• Lavoro 1 per Progetto 1
• Lavoro 2 per Progetto 1
• Lavoro 3 Progetto 1
• Lavoro 4 per Progetto 2
• Lavoro 5 per Progetto 2
• Lavoro 6 Progetto 3

La fiera di utilizzo algoritmo assegna posti di lavoro in questo ordine:

1. Lavoro 1 è scelto per primo, perché ha il più basso numero di lavoro da progetti privi di esecuzione dei lavori (tutti i progetti).
2. Il lavoro 4 è il prossimo, perché 4 è ora il numero di lavoro più basso da progetti senza lavori in esecuzione (il progetto 1 ha un lavoro in esecuzione).
3. Il lavoro 6 è il prossimo, perché 6 è ora il numero di lavoro più basso dai progetti senza lavori in esecuzione (i progetti 1 e 2 hanno lavori in esecuzione).
4. Il lavoro 2 è il prossimo, perché, dei progetti con il numero più basso di lavori in esecuzione (ognuno ha 1), è il numero di lavoro più basso.
5. Il lavoro 5 è il prossimo, perché il progetto 1 ora ha 2 lavori in esecuzione e il lavoro 5 è il numero di lavoro rimanente più basso tra i progetti 2 e 3.
6. Finalmente è Job 3 because perché è l’unico lavoro rimasto.

Esempio 2

Se questi posti di lavoro sono in coda:

• Lavoro 1 per Progetto 1
• Lavoro 2 per Progetto 1
• Lavoro 3 Progetto 1
• Lavoro 4 per Progetto 2
• Lavoro 5 per Progetto 2
• Lavoro 6 Progetto 3

La fiera di utilizzo algoritmo assegna posti di lavoro in questo ordine:

1. Lavoro 1 è scelto per primo, perché ha il più basso numero di lavoro da progetti privi di esecuzione dei lavori (tutti i progetti).
2. Finiamo il lavoro 1.
3. Il lavoro 2 è il prossimo, perché, terminato il lavoro 1, tutti i progetti hanno 0 lavori in esecuzione di nuovo e 2 è il numero di lavoro più basso disponibile.
4. Il lavoro 4 è il prossimo, perché con il Progetto 1 che esegue un lavoro, 4 è il numero più basso da progetti che non eseguono lavori (Progetti 2 e 3).
5. Finiamo Lavoro 4.
6. Il lavoro 5 è il prossimo, perché dopo aver terminato il lavoro 4, il progetto 2 non ha più lavori in esecuzione.
7. Il lavoro 6 è il prossimo, perché il Progetto 3 è l’unico progetto rimasto senza lavori in esecuzione.
8. Infine scegliamo Job 3 because perché, ancora una volta, è l’unico lavoro rimasto.

Abilita runners condivisi

On GitLab.com, corridori condivisi sono abilitati in tutti i progetti bydefault.

Sulle istanze autogestite di GitLab, un amministratore deve installarle e registrarle.

È inoltre possibile abilitare runners condivisi per singoli progetti.

Per abilitare i runners condivisi:

1. Vai alle Impostazioni del progetto> CI/CD ed espandi la sezione Runners.
2. Selezionare Abilita corridori condivisi per questo progetto.

Disabilita runners condivisi

È possibile disabilitare runners condivisi per singoli progetti o per gruppi.È necessario disporre delle autorizzazioni proprietario per il progetto o il gruppo.

Per disabilitare i runners condivisi per un progetto:

1. Vai alle Impostazioni del progetto> CI / CD ed espandi la sezione Runners.
2. Nell’area Corridori condivisi, selezionare Abilita corridori condivisi per questo progetto in modo che l’interruttore sia disattivato.

I runners condivisi vengono automaticamente disabilitati per un progetto:

• Se l’impostazione runners condivisi per il gruppo padre è disabilitata e
• Se l’override di questa impostazione non è consentita a livello di progetto.

Per disabilitare i runners condivisi per un gruppo:

1. Vai alle Impostazioni del gruppo> CI / CD ed espandi la sezione Runners.
2. Nell’area Corridori condivisi, disattiva l’opzione Abilita corridori condivisi per questo gruppo.
3. Facoltativamente,per consentire ai runners condivisi di essere abilitati per singoli progetti o sottogruppi, fare clic su Consenti progetti e sottogruppi di ignorare l’impostazione del gruppo.

Corridori di gruppo

Utilizzare corridori di gruppo quando si desidera che tutti i progetti in un gruppo abbiano accesso a una serie di corridori.

I corridori di gruppo elaborano i lavori utilizzando una coda First in, First out (FIFO).

Crea un gruppo runner

Puoi creare un gruppo runner per la tua istanza GitLab autogestita o per GitLab.com.Devi avere le autorizzazioni del proprietario per il gruppo.

Per creare un gruppo runner:

1. Installare GitLab Runner.
2. Vai al gruppo per cui vuoi far funzionare il corridore.
3. Andare su Impostazioni > CI / CD ed espandere la sezione Corridori.
4. Nota l’URL e il token.
5. Registrare il corridore.

Visualizzare e gestire i corridori di gruppo

È possibile visualizzare e gestire tutti i corridori per un gruppo, i suoi sottogruppi e progetti.È possibile farlo per l’istanza GitLab autogestita o per GitLab. com. È necessario disporre delle autorizzazioni del proprietario per il gruppo.

1. Vai al gruppo in cui vuoi vedere i corridori.
2. Andare su Impostazioni > CI / CD ed espandere la sezione Corridori.

3. Vengono visualizzati i seguenti campi.

   Attributo	Descrizione
   Tipo	Uno o più dei seguenti stati: di gruppo condivisa, specifiche, bloccato o sospeso
   Runner token	Token utilizzato per identificare il corridore, e che il corridore utilizza per comunicare con il GitLab istanza
   Descrizione	Descrizione data per il corridore, quando è stato creato
   Versione	GitLab Runner versione
   indirizzo IP	Indirizzo IP dell’host su cui il corridore è registrato
   Progetti	Il conte di progetti di cui il corridore è assegnato
   Lavori	Totale dei lavori eseguiti dai runner
   Tag	Tag associati con il runner
   contatto	Timestamp che indica quando il GitLab ultima istanza contattato il runner

Da questa pagina, è possibile modificare, mettere in pausa, e rimuovere i corridori del gruppo, i suoi sottogruppi, e progetti.

Metti in pausa o rimuovi un group runner

Puoi mettere in pausa o rimuovere un group runner per la tua istanza GitLab autogestita o per GitLab.com.Devi avere le autorizzazioni del proprietario per il gruppo.

1. Andare al gruppo che si desidera rimuovere o mettere in pausa il corridore per.
2. Andare su Impostazioni > CI / CD ed espandere la sezione Corridori.
3. Fare clic su Pausa o Rimuovere runner.
   • Se si mette in pausa un corridore di gruppo che viene utilizzato da più progetti, il corridore si ferma per tutti i progetti.
   • Dalla vista gruppo, non è possibile rimuovere un runner assegnato a più di un progetto.È necessario rimuoverlo da ogni progetto prima.
4. Nella finestra di dialogo di conferma, fare clic su OK.

Corridori specifici

Utilizzare corridori specifici quando si desidera utilizzare corridori per progetti specifici. Ad esempio, quando si hanno:

• lavori con requisiti specifici, come un lavoro di distribuzione che richiede credenziali.
• Progetti con un sacco di attività CI che possono beneficiare di essere separati da altri corridori.

È possibile impostare un corridore specifico per essere utilizzato da più progetti. Runners specificideve essere abilitato esplicitamente per ogni progetto.

I corridori specifici elaborano i lavori utilizzando una coda First in, First out (FIFO).

Crea un runner specifico

Puoi creare un runner specifico per la tua istanza GitLab autogestita o per GitLab.com.Devi avere le autorizzazioni del proprietario per il progetto.

Per creare un runner specifico:

1. Installa runner.
2. Vai alle Impostazioni del progetto> CI / CD ed espandi la sezione Runners.
3. Nota l’URL e il token.
4. Registrare il corridore.

Abilita un corridore specifico per un progetto specifico

Un corridore specifico è disponibile nel progetto per cui è stato creato. Un amministratore può abilitare un corridore specifico da applicare a progetti aggiuntivi.

• È necessario disporre delle autorizzazioni del proprietario per il progetto.
• Il corridore specifico non deve essere bloccato.

Per abilitare o disabilitare un runner specifico per un progetto:

1. Vai alle Impostazioni del progetto> CI / CD ed espandi la sezione Runners.
2. Fare clic su Abilita per questo progetto o Disabilita per questo progetto.

Impedire che un corridore specifico venga abilitato per altri progetti

È possibile configurare un corridore specifico in modo che sia “bloccato” e non possa essere abilitato per altri progetti.Questa impostazione può essere attivata quando si registra per la prima volta un corridore, ma può anche essere modificata in seguito.

Per bloccare o sbloccare un corridore:

1. Vai alle Impostazioni del progetto > CI/CD ed espandi la sezione Corridori.
2. Trova il corridore che vuoi bloccare o sbloccare. Assicurati che sia abilitato.
3. Fare clic sul pulsante matita.
4. Selezionare l’opzione Blocca progetti correnti.
5. Fare clic su Salva modifiche.

Svuota manualmente la cache runner

Leggi svuotare la cache.

Imposta il timeout massimo del lavoro per un corridore

Per ogni corridore, è possibile specificare un timeout massimo del lavoro. Questo timeout, se inferiore al timeout definito dal progetto, ha la precedenza.

Questa funzione può essere utilizzata per evitare che il runner condiviso venga sopraffatto da un progetto con lavori con un timeout lungo (ad esempio, una settimana).

Quando non configurato, i runners non sovrascrivono il timeout del progetto.

Su GitLab.com, non è possibile ignorare il timeout del lavoro per i runners condivisi e utilizzare il timeout definito dal progetto.

Per impostare il timeout massimo del lavoro:

1. In un progetto, andare su Impostazioni >CI/CD > Corridori.
2. Selezionare il corridore specifico per modificare le impostazioni.
3. Immettere un valore in timeout massimo lavoro.
4. Selezionare Salva modifiche.

Come funziona questa funzione:

Esempio 1 – Runner timeout più grande progetto di timeout

1. impostare il lavoro massimo di timeout per un corridore di 24 ore
2. impostare il CI/CD Timeout per un progetto di 2 ore
3. Si avvia un processo
4. Il lavoro, in caso di esecuzione di più, dopo 2 ore

Esempio 2 – Runner timeout configurato

1. rimuovere il massimo timeout processo di configurazione da un runner
2. impostare il CI/CD Timeout per un progetto di 2 ore
3. Si avvia un processo
4. Il lavoro, in caso di esecuzione di più, dopo 2 ore

Esempio 3 – Runner timeout più piccolo di progetto timeout

1. impostare il lavoro massimo di timeout per un corridore di 30 minuti
2. impostare il CI/CD Timeout per un progetto di 2 ore
3. Si avvia un processo
4. Il lavoro, in caso di esecuzione di più, dopo 30 minuti

attenzione con informazioni sensibili

Con qualche corridore esecutori,se è possibile eseguire un lavoro sul corridore, è possibile ottenere l’accesso completo al file system,e quindi il codice viene eseguito come pure il token del corridore. Con runners condivisi, questo significa che chiunque esegua lavori sul runner, può accedere al codice di chiunque altro che gira su therunner.

Inoltre, poiché è possibile accedere al token runner, è possibileper creare un clone di un runner e inviare lavori falsi, ad esempio.

Quanto sopra è facilmente evitato limitando l’uso di runner condivisi su grandi istanze GitLab pubbliche, controllando l’accesso alla tua istanza GitLab e utilizzando esecutori runner più sicuri.

Impedire ai corridori di rivelare informazioni sensibili

Puoi proteggere i corridori in modo che non rivelino informazioni sensibili.Quando un runner è protetto, sceglie solo i lavori creati su rami protetti o tag protetti e ignora gli altri lavori.

Per proteggere o rimuovere la protezione di un corridore:

1. Vai alle Impostazioni del progetto > CI/CD ed espandi la sezione Corridori.
2. Trova il corridore che vuoi proteggere o rimuovere la protezione. Assicurati che sia abilitato.
3. Fare clic sul pulsante matita.
4. Selezionare l’opzione Protetta.
5. Fare clic su Salva modifiche.

Forchette

Ogni volta che un progetto è biforcuto, copia le impostazioni dei lavori che lo riguardano. Ciò significa che se sono stati configurati runners condivisi per un progetto e qualcuno forca quel progetto, i runners condivisi servono i lavori di questo progetto.

Vettori di attacco in runners

Menzionato brevemente in precedenza, ma le seguenti cose dei runners possono essere sfruttate.Siamo sempre alla ricerca di contributi che possano mitigare queste considerazioni di sicurezza.

Ripristina il token di registrazione runner per un progetto

Se pensi che sia stato rivelato un token di registrazione per un progetto, dovresti ripristinarlo. Un token può essere utilizzato per registrare un altro corridore per il progetto. Quel nuovo runnermay allora si può usare per ottenere i valori di variabili segrete o clonare il codice di progetto.

Per resettare il token:

1. Vai alle Impostazioni del progetto > CI/CD.
2. Espandere la sezione Impostazioni generali pipeline.
3. Trova il campo modulo token Runner e fai clic sul pulsante Rivela valore.
4. Elimina il valore e salva il modulo.
5. Dopo aver aggiornato la pagina, espandere la sezione Impostazioni corridori e controllare il token di registrazione-dovrebbe essere cambiato.

D’ora in poi il vecchio token non è più valido e non registra nuovi corridori al progetto. Se si utilizzano strumenti per eseguire il provisioning e registrare nuovi runners, i token utilizzati in tali strumenti dovrebbero essere aggiornati per riflettere il valore del nuovo token.

Determina l’indirizzo IP di un runner

Può essere utile conoscere l’indirizzo IP di un corridore in modo da poter risolvere i problemi con quel corridore. GitLab memorizza e visualizza l’indirizzo IP visualizzandol’origine delle richieste HTTP che fa a GitLab durante il polling dei lavori. L’indirizzo IP è sempre aggiornato, quindi se l’IP del corridore cambia automaticamente si aggiorna in GitLab.

L’indirizzo IP per corridori condivisi e corridori specifici può essere trovato in posti diversi.

Determinare l’indirizzo IP di un runner condiviso

Per visualizzare l’indirizzo IP di un runner condiviso è necessario disporre dell’accesso amministratore all’istanza GitLab. Per determinare questo:

1. Visita Admin Area> Panoramica> Corridori.
2. Cerca il corridore nella tabella e dovresti vedere una colonna per l’indirizzo IP.

Determinare l’indirizzo IP di un corridore specifico

Per trovare l’indirizzo IP di un corridore per un progetto specifico,è necessario disporre delle autorizzazioni del proprietario per il progetto.

1. Vai alle Impostazioni del progetto> CI / CD ed espandi la sezione Runners.
2. Nella pagina dei dettagli dovresti vedere una riga per l’indirizzo IP.

Utilizzare i tag per limitare il numero di lavori utilizzando il corridore

È necessario impostare un corridore per essere in grado di eseguire tutti i diversi tipi di jobsthat può incontrare sui progetti su cui è condiviso. Questo sarebbe problematico per grandi quantità di progetti, se non fosse per i tag.

I tag GitLab CI non sono gli stessi dei tag Git. I tag GitLab CI sono associati a runners.I tag Git sono associati ai commit.

Taggando un corridore per i tipi di lavori che può gestire, puoi fare in modo che i corridori condivisi eseguano solo i lavori che sono attrezzati per eseguire.

Ad esempio, in GitLab abbiamo runners taggati conrails se contengono le dipendenze appropriate per eseguire le suite di test Rails.

Quando si registra un corridore, il suo comportamento predefinito è solo picktagged jobs.To cambiare questo, è necessario disporre di autorizzazioni proprietario per il progetto.

Per fare in modo che un corridore scelga lavori senza tag:

1. Vai alle Impostazioni del progetto> CI / CD ed espandi la sezione Runners.
2. Trova il corridore che vuoi scegliere i lavori senza tag e assicurati che sia abilitato.
3. Fare clic sul pulsante matita.
4. Selezionare l’opzione Esegui lavori senza tag.
5. Fare clic sul pulsante Salva modifiche affinché le modifiche abbiano effetto.

Di seguito sono riportati alcuni scenari di esempio di diverse varianti.

runner esegue solo lavori taggati

I seguenti esempi illustrano il potenziale impatto del runner che viene impostato per eseguire solo lavori taggati.

Esempio 1:

1. Il runner è configurato per eseguire solo lavori con tag e ha il tagdocker.
2. Un lavoro che ha un tag hello viene eseguito e bloccato.

Esempio 2:

1. Il runner è configurato per eseguire solo lavori con tag e ha il tagdocker.
2. Un lavoro che ha un tag docker viene eseguito ed eseguito.

Esempio 3:

1. Il runner è configurato per eseguire solo lavori con tag e ha il tag docker.
2. Un lavoro che non ha tag definiti viene eseguito e bloccato.

runner può eseguire lavori senza tag

I seguenti esempi illustrano il potenziale impatto del runner che viene impostato per eseguire lavori con tag e senza tag.

Esempio 1:

1. Il runner è configurato per eseguire lavori senza tag e ha il tagdocker.
2. Un lavoro che non ha tag definiti viene eseguito ed eseguito.
3. Un secondo lavoro che ha un docker tag definito viene eseguito ed eseguito.

Esempio 2:

1. Il runner è configurato per eseguire lavori senza tag e non ha tag definiti.
2. Un lavoro che non ha tag definiti viene eseguito ed eseguito.
3. Un secondo lavoro che ha un tag docker definito è bloccato.

Configura il comportamento del runner con le variabili

Puoi usare le variabili CI / CD per configurare il comportamento del runner Git globalmente o per i singoli lavori:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (di poco la clonazione)
• GIT_CLONE_PATH (custom build directory)

È inoltre possibile utilizzare le variabili per configurare quante volte un runnerattempts alcune fasi di esecuzione del lavoro.

Git strategy

È possibile impostare il GIT_STRATEGY usato per recuperare il contenuto del repository, eitherglobally o per lavoro nel variables sezione:

variables: GIT_STRATEGY: clone

Ci sono tre possibili valori: clonefetch e none. Se non specificato,i lavori utilizzano l’impostazione pipeline del progetto.

clone è l’opzione più lenta. Clona il repository da zero per everyjob, assicurando che la copia di lavoro locale sia sempre incontaminata.Se viene trovato un albero di lavoro esistente, viene rimosso prima della clonazione.

fetchè più veloce in quanto riutilizza la copia di lavoro locale (tornando a clone se non esiste). git clean viene utilizzato per annullare le modifiche apportate dal lastjob egit fetch viene utilizzato per recuperare i commit effettuati dopo l’esecuzione dell’ultimo lavoro.

Tuttavia,fetch richiede l’accesso all’albero di lavoro precedente. Questo funziona bene quando si utilizza l’esecutoreshell odocker perché si cerca di preservare gli alberi di lavoro e provare a riutilizzarli per impostazione predefinita.

Questo ha limitazioni quando si utilizza l’esecutore della macchina Docker.

Non funziona per l’esecutore kubernetes, ma esiste una proposta di funzionalità.L’esecutorekubernetes clona sempre in una directory temporanea.

Una strategia Git di none riutilizza anche la copia di lavoro locale, ma salta tutte le Gitoperazioni normalmente eseguite da GitLab. Anche gli script pre-clone di GitLab Runner vengono saltati, se presenti. Questa strategia potrebbe significare che è necessario aggiungere comandifetch echeckout al tuo script.gitlab-ci.yml.

Può essere utilizzato per lavori che operano esclusivamente su artefatti, come un lavoro di distribuzione.I dati del repository Git potrebbero essere presenti, ma è probabile che non siano aggiornati. Dovresti fare affidamento solo sui file portati nella copia di lavoro locale dalla cache o dagli artefatti.

Git submodule strategy

Richiede GitLab Runner v1.10+.

La variabileGIT_SUBMODULE_STRATEGY viene utilizzata per controllare se / come vengono inclusi i Gitsubmodules quando si recupera il codice prima di una build. È possibile impostarli globalmente o per lavoro nella sezionevariables.

Ci sono tre possibili valori: nonenormal e recursive:

• none significa che sotto-moduli non sono inclusi quando recupero il projectcode. Questo è il valore predefinito, che corrisponde al comportamento pre-v1.10.

• normal significa che sono inclusi solo i sottomoduli di livello superiore. È equivalente a:

  git submodule syncgit submodule update --init

• recursive significa che tutti i sottomoduli (inclusi sottomoduli di sottomoduli)sono inclusi. Questa funzione richiede Git v1.8.1 e versioni successive. Quando si utilizza aGitLab Runner con un executor non basato su Docker, assicurarsi che la versione Git soddisfi tale requisito. È equivalente a:

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

Per questa funzione funziona correttamente, il sotto-moduli deve essere configurato(nel .gitmodules con:

• HTTP(S) URL di un sito pubblicamente accessibili repository, o
• un percorso relativo ad un altro repository sullo stesso GitLab server. Vedere la documentazione dei sottomoduli GIT.

Git checkout

Introdotto in GitLab Runner 9.3.

GIT_CHECKOUT variabile può essere utilizzata quando il GIT_STRATEGY è impostato suclone o fetch per specificare se un git checkout deve essere eseguito. Se notspecified, il valore predefinito è true. È possibile impostarli globalmente o per lavoro nella sezionevariables.

Se impostato su false , il corridore:

• quando si eseguefetch – aggiorna il repository e lascia la copia di lavoro sulla revisione corrente,
• quando si esegueclone – clona il repository e lascia la copia di lavoro sul ramo predefinito.

SeGIT_CHECKOUTè impostato sutrue, entrambicloneefetch funzionano allo stesso modo.Il corridore controlla la copia di lavoro di una revisione relatedto la pipeline CI:

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

Git pulito flag

Introdotto nel GitLab Runner 11.10

GIT_CLEAN_FLAGS variabile viene utilizzata per controllare il comportamento di defaultgit clean dopo aver controllato le fonti. È possibile impostarlo globalmente o per lavoro nella sezionevariables.

GIT_CLEAN_FLAGSaccetta tutte le opzioni possibili del comando git clean.

git clean è disabilitato se GIT_CHECKOUT: "false" è specificato.

Se GIT_CLEAN_FLAGS è:

• Non specificato,git clean contrassegna di default-ffdx.
• Dato il valore nonegit clean non viene eseguito.

Per esempio:

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

Git fetch bandiere extra

Introdotto in GitLab Runner 13.1.

La variabileGIT_FETCH_EXTRA_FLAGSviene utilizzata per controllare il comportamento digit fetch. È possibile impostarlo globalmente o per lavoro nella sezionevariables.

GIT_FETCH_EXTRA_FLAGS accetta tutte le opzioni del comando git fetch. Tuttavia, i flagGIT_FETCH_EXTRA_FLAGS vengono aggiunti dopo i flag predefiniti che non possono essere modificati.

I flag predefiniti sono:

• GIT_DEPTH.
• L’elenco dei refspec.
• Un telecomando chiamato origin.

SeGIT_FETCH_EXTRA_FLAGS è:

• Non specificato,git fetchflag di default a--prune --quiet insieme ai flag di default.
• Dato il valore nonegit fetch viene eseguito solo con i flag predefiniti.

Per esempio, il flag di default sono: --prune --quiet, in modo che si può fare git fetch più dettagliato con l’override di questo con solo --prune:

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

La configurazione di sopra di risultati nel git fetch essere chiamato in questo modo:

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

Dove $REFSPECS è un valore fornito al runner internamente da GitLab.

Clonazione superficiale

Introdotta in GitLab 8.9 come funzionalità sperimentale.

È possibile specificare la profondità di recupero e clonazione utilizzando GIT_DEPTHGIT_DEPTH esegue un clone superficiale del repository e può accelerare in modo significativo cloning.It può essere utile per repository con un numero elevato di commit o binari vecchi e grandi. Il valore è passato a git fetchegit clone.

In GitLab 12.0 e versioni successive, i progetti appena creati hanno automaticamente un valore predefinitogit depthdi50.

Se si utilizza una profondità di 1 e si dispone di una coda di lavori o retryjobs, i lavori potrebbero non riuscire.

Il recupero e la clonazione di Git si basano su un ref, come un nome di ramo, quindi i runners non possono clonare uno specifico commit SHA. Se più lavori sono in coda, o stai riprovando un vecchio lavoro, il commit da testare deve essere all’interno della cronologia di theGit che è clonata. L’impostazione di un valore troppo piccolo per GIT_DEPTH può rendere impossibile l’esecuzione di questi vecchi commit e unresolved reference viene visualizzato injob log. Dovresti quindi riconsiderare la modifica di GIT_DEPTH a un valore più alto.

I lavori che si basano sugit describe potrebbero non funzionare correttamente quandoGIT_DEPTH è impostato poiché è presente solo una parte della cronologia Git.

Per recuperare o clonare solo gli ultimi 3 commit:

variables: GIT_DEPTH: "3"

È possibile impostarlo globalmente o per-job nella sezione variables.

Directory di compilazione personalizzate

Introdotte in GitLab Runner 11.10.

Per impostazione predefinita, GitLab Runner clona il repository in un sottopassaggio univoco della directory$CI_BUILDS_DIR. Tuttavia, il tuo progetto potrebbe richiedere il codice in una directory specifica (Go projects, ad esempio). In tal caso, è possibile specificare la variabileGIT_CLONE_PATH per indicare al runner la directory in cui clonare il repository:

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

Il GIT_CLONE_PATHdeve essere sempre all’interno di $CI_BUILDS_DIR. La directory impostata in $CI_BUILDS_DIR dipende dall’esecutore e dalla configurazione dei runners.builds_dirsetting.

Questo può essere usato solo quando custom_build_dir è abilitato nella configurazione di therunner.Questa è la configurazione predefinita per gli esecutoridocker ekubernetes.

Gestione della concorrenza

Un esecutore che utilizza una concorrenza maggiore di1 potrebbe portare a errori. Più lavori potrebbero funzionare sulla stessa directory se builds_dir è condiviso tra i lavori.

Il corridore non cerca di prevenire questa situazione. Spetta agli sviluppatori administratorand per soddisfare i requisiti di configurazione corridore.

Per evitare questo scenario, è possibile utilizzare un unico percorso all’interno di $CI_BUILDS_DIR, perché runnerexposes due variabili aggiuntive che forniscono un unico ID scrive:

• $CI_CONCURRENT_ID: ID Univoco per tutti i processi in esecuzione all’interno di un determinato esecutore.
• $CI_CONCURRENT_PROJECT_ID: ID univoco per tutti i lavori in esecuzione all’interno dell’esecutore e del progetto specificato.

La configurazione più stabile che dovrebbe funzionare bene in qualsiasi scenario e su qualsiasi esecutoreè usare $CI_CONCURRENT_IDnel GIT_CLONE_PATH. Per esempio:

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

$CI_CONCURRENT_PROJECT_ID deve essere utilizzato in combinazione con $CI_PROJECT_PATHil $CI_PROJECT_PATH fornisce un percorso di un repository. Cioè, group/subgroup/project. Ad esempio:

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

Percorsi nidificati

Il valore diGIT_CLONE_PATH viene espanso una volta e le variabili di nidificazione all’interno non sono supportate.

Ad esempio, si definiscono entrambe le variabili di seguito nel file.gitlab-ci.yml :

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

Il valore diGIT_CLONE_PATHviene espanso una volta in$CI_BUILDS_DIR/go/src/namespace/project, e si traduce in failurebecause$CI_BUILDS_DIR non è espanso.

Fasi di lavoro tentativi

Introdotto in GitLab, richiede GitLab Runner v1.9+.

È possibile impostare il numero di tentativi che il lavoro in esecuzione tenta di eseguirele seguenti fasi:

Variabile	Descrizione
ARTIFACT_DOWNLOAD_ATTEMPTS	Il numero di tentativi di scaricare artefatti esecuzione di un lavoro
EXECUTOR_JOB_SECTION_ATTEMPTS	In GitLab 12.10 e, successivamente, il numero di tentativi di eseguire una sezione in un posto di lavoro dopo un No Such Container errore (finestra Mobile esecutore solo).
GET_SOURCES_ATTEMPTS	Numero di tentativi di recupero fonti di esecuzione di un lavoro
RESTORE_CACHE_ATTEMPTS	Numero di tentativi per ripristinare la cache esecuzione di un lavoro

L’impostazione di default è un singolo tentativo.

Esempio:

variables: GET_SOURCES_ATTEMPTS: 3

È possibile impostarli globalmente o per-job nella sezione variables.

Chiamate di sistema non disponibili su GitLab.com corridori condivisi

GitLab.com i corridori condivisi corrono su CoreOS. Ciò significa che non è possibile utilizzare alcune chiamate di sistema, come getlogin, dalla libreria standard C.

Impostazioni di artefatto e cache

Introdotte in GitLab Runner 13.9.

Le impostazioni di artefatto e cache controllano il rapporto di compressione di artefatti e cache.Utilizzare queste impostazioni per specificare la dimensione dell’archivio prodotto da un lavoro.

• Su una rete lenta, i caricamenti potrebbero essere più veloci per gli archivi più piccoli.
• Su una rete veloce in cui la larghezza di banda e l’archiviazione non sono un problema, i caricamenti potrebbero essere più veloci utilizzando il rapporto di compressione più veloce, nonostante l’archivio prodotto sia più grande.

Affinché le pagine GitLab servano le richieste dell’intervallo HTTP, gli artefattidovrebbe utilizzare l’impostazioneARTIFACT_COMPRESSION_LEVEL: fastest, poiché solo gli archivi zip non compressi supportano questa funzione.

Un misuratore può anche essere abilitato per fornire la velocità di trasferimento per upload e download.

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"

Variabile	Descrizione
TRANSFER_METER_FREQUENCY	consente di Specificare la frequenza di stampare il misuratore di velocità di trasferimento. Può essere impostato su una durata (ad esempio, 1s o 1m30s). Una durata di 0 disabilita lo strumento (predefinito). Quando viene impostato un valore, la pipeline mostra un misuratore di avanzamento per i caricamenti e i download di artefatti e cache.
ARTIFACT_COMPRESSION_LEVEL	Per regolare il rapporto di compressione, impostato su fastestfastdefaultslow o slowest. Questa impostazione funziona solo con l’archiviatore Fastzip, quindi anche il flag della funzionalità GitLab Runner FF_USE_FASTZIP deve essere abilitato.
CACHE_COMPRESSION_LEVEL	To adjust compression ratio, set to fastestfastdefaultslow, or slowest. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag FF_USE_FASTZIP must also be enabled.