• Types de coureurs
  • Coureurs partagés
    • Comment les coureurs partagés choisissent les tâches
    • Activer les coureurs partagés
    • Désactiver les coureurs partagés
  • Coureurs de groupe
    • Créer un coureur de groupe
    • Afficher et gérer les coureurs de groupe
    • Mettre en pause ou supprimer un coureur de groupe
  • Coureurs spécifiques
    • Créer un coureur spécifique
    • Activer un coureur spécifique pour un projet spécifique
    • Empêcher un coureur spécifique d’être activé pour d’autres projets
• Effacer manuellement le cache du coureur
• Définir le délai maximum de travail pour un coureur
• Soyez prudent avec les informations sensibles
  • Empêcher les coureurs de révéler des informations sensibles
  • Fourches
  • Vecteurs d’attaque dans les coureurs
  • Réinitialiser le jeton d’enregistrement du coureur pour un projet
• Déterminer l’adresse IP d’un coureur
  • Déterminer l’adresse IP d’un coureur partagé
• /li>
• Déterminer l’adresse IP d’un coureur spécifique

Dans GitLab CI/CD, les coureurs exécutent le code défini dans .gitlab-ci.yml.Un runner est un agent léger et hautement évolutif qui récupère un travail CI via l’API coordinator de GitLab CI / CD, exécute le travail et renvoie le résultat à l’instance GitLab.

Les runners sont créés par un administrateur et sont visibles dans l’interface utilisateur de GitLab.Les coureurs peuvent être spécifiques à certains projets ou disponibles pour tous les projets.

Cette documentation se concentre sur l’utilisation de runners dans GitLab.Si vous devez installer et configurer GitLab Runner, consultez la documentation de GitLab Runner.

Types de coureurs

Dans l’interface utilisateur de GitLab, il existe trois types de coureurs, en fonction de qui vous souhaitez avoir accès :

• Les coureurs partagés sont disponibles pour tous les groupes et projets dans une instance GitLab.
• Les coureurs de groupe sont disponibles pour tous les projets et sous-groupes d’un groupe.
• Des coureurs spécifiques sont associés à des projets spécifiques.En règle générale, des coureurs spécifiques sont utilisés pour un projet à la fois.

Coureurs partagés

Les coureurs partagés sont disponibles pour chaque projet dans une instance GitLab.

Utilisez des runners partagés lorsque vous avez plusieurs tâches avec des exigences similaires. Plutôt que d’avoir plusieurs coureurs au ralenti pour de nombreux projets, vous pouvez avoir quelques coureurs qui gèrent plusieurs projets.

Si vous utilisez une instance autogérée de GitLab :

• Votre administrateur peut installer et enregistrer des runners partagés en accédant aux paramètres de votre projet >CI/CD, en développant la section Runners et en cliquant sur Show runners instructions d’installation.Ces instructions sont également disponibles dans la documentation.
• L’administrateur peut également configurer un nombre maximum de minutes de pipeline runner partagé pour chaque groupe.

Si vous utilisez GitLab.com :

• Vous pouvez choisir parmi une liste de coureurs partagés gérés par GitLab.
• Les coureurs partagés consomment les pipelines minutesincluded avec votre compte.

Comment les coureurs partagés sélectionnent les tâches

Les coureurs partagés traitent les tâches à l’aide d’une file d’attente d’utilisation équitable. Cette file d’attente empêche les projets de créer des centaines de tâches et d’utiliser toutes les ressources de runner partagées disponibles.

L’algorithme de file d’attente d’utilisation équitable attribue des tâches en fonction des projets qui ont le plus grand nombre de tâches déjà exécutées sur des coureurs partagés.

Exemple 1

Si ces travaux sont dans la file d’attente :

• Job 1 pour le Projet 1
• Job 2 pour le Projet 1
• Job 3 pour le Projet 1
• Job 4 pour le Projet 2
• Job 5 pour le Projet 2
• Job 6 pour le Projet 3

L’algorithme d’utilisation équitable attribue les travaux dans cet ordre :

1. Job 1 est choisi en premier, car il a le nombre de tâches le plus bas parmi les projets sans travaux en cours (c’est-à-dire tous les projets).
2. Le travail 4 est le suivant, car 4 est maintenant le nombre de tâches le plus bas parmi les projets sans travaux en cours d’exécution (le projet 1 a un travail en cours d’exécution).
3. La tâche 6 est la suivante, car 6 est maintenant le nombre de tâches le plus bas parmi les projets sans travaux en cours d’exécution (les projets 1 et 2 ont des travaux en cours d’exécution).
4. Le job 2 est le suivant, car, parmi les projets avec le plus petit nombre de jobs en cours d’exécution (chacun a 1), c’est le nombre de jobs le plus bas.
5. La tâche 5 est la suivante, car le projet 1 a maintenant 2 tâches en cours d’exécution et la tâche 5 est le nombre de tâches restant le plus bas entre les projets 2 et 3.
6. C’est enfin le Job 3 because parce que c’est le seul job qui reste.

Exemple 2

Si ces travaux sont dans la file d’attente :

• Job 1 pour le Projet 1
• Job 2 pour le Projet 1
• Job 3 pour le Projet 1
• Job 4 pour le Projet 2
• Job 5 pour le Projet 2
• Job 6 pour le Projet 3

L’algorithme d’utilisation équitable attribue les travaux dans cet ordre :

Exemple 2

Si ces travaux sont dans la file d’attente :

• Job 1 pour le Projet 1
• Job 3 pour le Projet 1
• Job 4 pour le Projet 2
• Job 5 pour le Projet 2
• Job 6 pour le Projet 3

/p>

1. La tâche 1 est choisie en premier, car elle a le nombre de tâches le plus bas parmi les projets sans travaux en cours (c’est-à-dire tous les projets).
2. Nous terminons le travail 1.
3. La tâche 2 est la suivante, car, après avoir terminé la Tâche 1, tous les projets ont 0 tâche en cours d’exécution, et 2 est le numéro de tâche disponible le plus bas.
4. La tâche 4 est la suivante, car avec le projet 1 exécutant une tâche, 4 est le nombre le plus bas parmi les projets n’exécutant aucune tâche (projets 2 et 3).
5. Nous terminons le travail 4.
6. Le travail 5 est le suivant, car après avoir terminé le travail 4, le projet 2 n’a plus de travaux en cours d’exécution.
7. Le travail 6 est le suivant, car le projet 3 est le seul projet restant sans travaux en cours.
8. Enfin, nous choisissons le Job 3 because parce que, encore une fois, c’est le seul job qui reste.

Activer les coureurs partagés

Sur GitLab.com , les coureurs partagés sont activés dans tous les projets par défaut.

Sur les instances autogérées de GitLab, un administrateur doit les installer et les enregistrer.

Vous pouvez également activer les runners partagés pour des projets individuels.

Pour activer les runners partagés :

1. Accédez aux paramètres du projet >CI/CD et développez la section Runners.
2. Sélectionnez Activer les coureurs partagés pour ce projet.

Désactiver les coureurs partagés

Vous pouvez désactiver les coureurs partagés pour des projets individuels ou pour des groupes.Vous devez disposer des autorisations de propriétaire pour le projet ou le groupe.

Pour désactiver les runners partagés pour un projet :

1. Accédez aux paramètres du projet >CI/CD et développez la section Runners.
2. Dans la zone Coureurs partagés, sélectionnez Activer les coureurs partagés pour ce projet afin que la bascule soit grisée.

Les coureurs partagés sont automatiquement désactivés pour un projet :

• Si le paramètre coureurs partagés pour le groupe parent est désactivé, et
• Si le remplacement de ce paramètre n’est pas autorisé au niveau du projet.

Pour désactiver les coureurs partagés pour un groupe :

1. Accédez aux paramètres du groupe >CI/CD et développez la section Coureurs.
2. Dans la zone Coureurs partagés, désactivez l’option Activer les coureurs partagés pour ce groupe.
3. En option, pour autoriser les coureurs partagés à être activés pour des projets ou des sous-groupes individuels, cliquez sur Autoriser les projets et les sous-groupes pour remplacer le paramètre de groupe.

Coureurs de groupe

Utilisez les coureurs de groupe lorsque vous souhaitez que tous les projets d’un groupepour avoir accès à un ensemble de coureurs.

Les coureurs de groupe traitent les tâches à l’aide d’une file d’attente FIFO (first in, first out).

Créer un coureur de groupe

Vous pouvez créer un coureur de groupe pour votre instance GitLab autogérée ou pour GitLab.com. Vous devez avoir des autorisations de propriétaire pour le groupe.

Pour créer un coureur de groupe :

1. Installez GitLab Runner.
2. Accédez au groupe pour lequel vous souhaitez faire travailler le coureur.
3. Allez dans Settings >CI/CD et développez la section Runners.
4. Notez l’URL et le jeton.
5. Enregistrez le coureur.

Afficher et gérer les coureurs de groupe

Vous pouvez afficher et gérer tous les coureurs pour un groupe, ses sous-groupes et ses projets.Vous pouvez le faire pour votre instance GitLab autogérée ou pour GitLab.com. Vous devez avoir des autorisations de propriétaire pour le groupe.

1. Accédez au groupe où vous souhaitez voir les coureurs.
2. Allez dans Settings >CI/CD et développez la section Runners.

3. Les champs suivants sont affichés.

   Attribut	Description
   Type	Un ou plusieurs des états suivants: partagé, groupé, spécifique, verrouillé ou en pause
   Jeton Runner	Jeton utilisé pour identifier le runner, et que le runner utilise pour communiquer avec l’instance GitLab
   Description	Description donnée au runner lors de sa création
   Version	Version GitLab Runner
   Adresse IP	Adresse IP de l’hôte sur lequel le coureur est enregistré
   Projets	Le nombre de projets auxquels le coureur est affecté
   Emplois	Total des travaux exécutés par le coureur
   Tags	Tags associés au coureur
   Dernier contact	Horodatage indiquant quand l’instance GitLab a contacté le coureur pour la dernière fois

À partir de ce sur la page, vous pouvez modifier, mettre en pause et supprimer des coureurs du groupe, de ses sous-groupes et de ses projets.

Mettre en pause ou supprimer un coureur de groupe

Vous pouvez mettre en pause ou supprimer un coureur de groupe pour votre instance GitLab autogérée ou pour GitLab.com. Vous devez avoir des autorisations de propriétaire pour le groupe.

1. Accédez au groupe pour lequel vous souhaitez supprimer ou mettre en pause le coureur.
2. Allez dans Settings >CI/CD et développez la section Runners.
3. Cliquez sur Pause ou Supprimer le coureur.
   • Si vous mettez en pause un coureur de groupe utilisé par plusieurs projets, le coureur s’arrête pour tous les projets.
   • Dans la vue de groupe, vous ne pouvez pas supprimer un coureur affecté à plus d’un projet.Vous devez d’abord le supprimer de chaque projet.
4. Dans la boîte de dialogue de confirmation, cliquez sur OK.

Coureurs spécifiques

Utilisez des coureurs spécifiques lorsque vous souhaitez utiliser des coureurs pour des projets spécifiques. Par exemple, lorsque vous avez :

• Des tâches avec des exigences spécifiques, comme une tâche de déploiement qui nécessite des informations d’identification.
• Projets avec beaucoup d’activité CI qui peuvent bénéficier d’être séparés des autres coureurs.

Vous pouvez configurer un runner spécifique pour être utilisé par plusieurs projets. runnersdoit être activé explicitement pour chaque projet.

Des exécuteurs spécifiques traitent les tâches en utilisant une file d’attente FIFO (first in, first out).

Créer un runner spécifique

Vous pouvez créer un runner spécifique pour votre instance GitLab autogérée ou pour GitLab.com. Vous devez avoir des autorisations de propriétaire pour le projet.

Pour créer un runner spécifique :

1. Installez runner.
2. Accédez aux paramètres du projet >CI/CD et développez la section Runners.
3. Notez l’URL et le jeton.
4. Enregistrez le coureur.

Activer un runner spécifique pour un projet spécifique

Un runner spécifique est disponible dans le projet pour lequel il a été créé. Un administrateur peut activer un coureur spécifique à appliquer à des projets supplémentaires.

• Vous devez disposer des autorisations de propriétaire pour le projet.
• Le coureur spécifique ne doit pas être verrouillé.

Pour activer ou désactiver un runner spécifique pour un projet :

1. Accédez aux paramètres du projet >CI/CD et développez la section Runners.
2. Cliquez sur Activer pour ce projet ou Désactiver pour ce projet.

Empêcher l’activation d’un runner spécifique pour d’autres projets

Vous pouvez configurer un runner spécifique pour qu’il soit « verrouillé » et ne puisse pas être activé pour d’autres projets.Ce paramètre peut être activé lors de la première inscription d’un coureur, mais peut également être modifié ultérieurement.

Pour verrouiller ou déverrouiller un runner :

1. Accédez aux paramètres du projet >CI/CD et développez la section Runners.
2. Trouvez le coureur que vous souhaitez verrouiller ou déverrouiller. Assurez-vous qu’il est activé.
3. Cliquez sur le bouton crayon.
4. Cochez l’option Verrouiller les projets en cours.
5. Cliquez sur Enregistrer les modifications.

Effacer manuellement le cache du coureur

Lire effacer le cache.

Définir le délai maximum de travail pour un coureur

Pour chaque coureur, vous pouvez spécifier un délai maximum de travail. Ce délai d’attente, s’il est inférieur au délai d’attente défini par le projet, a priorité.

Cette fonctionnalité peut être utilisée pour empêcher votre runner partagé d’être submergé par un projet qui a des tâches avec un délai d’attente long (par exemple, une semaine).

Lorsqu’ils ne sont pas configurés, les runners ne remplacent pas le délai d’expiration du projet.

Sur GitLab.avec, vous ne pouvez pas remplacer le délai d’attente du travail pour les coureurs partagés et vous devez utiliser le délai d’attente défini par le projet.

Pour définir le délai maximum de travail :

1. Dans un projet, allez dans Settings >CI/CD >Runners.
2. Sélectionnez votre coureur spécifique pour modifier les paramètres.
3. Saisissez une valeur sous Délai d’expiration maximal de la tâche.
4. Sélectionnez Enregistrer les modifications.

Comment fonctionne cette fonctionnalité:

Exemple 1 – Délai d’attente du coureur supérieur au délai d’attente du projet

1. Vous définissez le délai d’attente maximal pour un coureur à 24 heures
2. Vous définissez le Délai d’attente CI/CD pour un projet à 2 heures
3. Vous démarrez un travail
4. Le travail, s’il est plus long, expire après 2 heures

Exemple 2 – Délai d’attente du coureur non configuré

1. Vous supprimez le délai configuration du délai d’attente de la tâche à partir d’un runner
2. Vous définissez le délai d’attente CI/CD pour un projet sur 2 heures
3. Vous démarrez une tâche
4. La tâche, si elle est plus longue, expire après 2 heures

Exemple 3 – Runner délai d’attente inférieur au délai d’attente du projet

1. Vous définissez le délai d’attente maximal pour un runner à 30 minutes
2. Vous définissez le délai d’attente CI/CD pour un projet à 2 heures
3. Vous démarrez un travail
4. Le travail, s’il est plus long, expire après 30 minutes

Soyez prudent avec les informations sensibles

Avec certains exécuteurs de runner, si vous pouvez exécuter un travail sur le runner, vous pouvez obtenez un accès complet au système de fichiers, et donc à tout code qu’il exécute ainsi qu’au jeton du coureur. Avec les coureurs partagés, cela signifie que quiconque exécute des travaux sur le coureur peut accéder au code de n’importe qui d’autre qui s’exécute sur le coureur.

De plus, comme vous pouvez accéder au jeton runner, il est possible de créer un clone d’un runner et de soumettre de faux travaux, par exemple.

Ce qui précède est facilement évité en limitant l’utilisation des runnings partagés sur de grandes instances GitLab publiques, en contrôlant l’accès à votre instance GitLab et en utilisant des exécuteurs runner plus sécurisés.

Empêche les coureurs de révéler des informations sensibles

Vous pouvez protéger les coureurs afin qu’ils ne révèlent pas d’informations sensibles.Lorsqu’un coureur est protégé, il sélectionne uniquement les tâches créées sur des branches protégées ou des balises protégées et ignore les autres tâches.

Pour protéger ou déprotéger un runner :

1. Accédez aux paramètres du projet >CI/CD et développez la section Runners.
2. Trouvez le coureur que vous souhaitez protéger ou déprotéger. Assurez-vous qu’il est activé.
3. Cliquez sur le bouton crayon.
4. Cochez l’option Protégée.
5. Cliquez sur Enregistrer les modifications.

Forks

Chaque fois qu’un projet est bifurqué, il copie les paramètres des travaux qui le concernent. Cela signifie que si vous avez configuré des runners partagés pour un projet etquelques forks de ce projet, les runners partagés servent les tâches de ce projet.

Vecteurs d’attaque chez les coureurs

Mentionnés brièvement plus tôt, mais les éléments suivants des coureurs peuvent être exploités.Nous sommes toujours à la recherche de contributions qui peuvent atténuer ces considérations de sécurité.

Réinitialisez le jeton d’enregistrement du coureur pour un projet

Si vous pensez qu’un jeton d’enregistrement pour un projet a été révélé, vous devriez le réinitialiser. Un jeton peut être utilisé pour enregistrer un autre coureur pour le projet. Ce nouveau runnermay peut ensuite être utilisé pour obtenir les valeurs des variables secrètes ou pour cloner le code du projet.

Pour réinitialiser le jeton :

1. Accédez aux paramètres du projet >CI/CD.
2. Développez la section Paramètres généraux des pipelines.
3. Recherchez le champ de formulaire de jeton de coureur et cliquez sur le bouton Révéler la valeur.
4. Supprimez la valeur et enregistrez le formulaire.
5. Une fois la page actualisée, développez la section Paramètres des coureurs et vérifiez le jeton d’enregistrement – il doit être modifié.

À partir de maintenant, l’ancien jeton n’est plus valide et n’enregistre plus aucun nouveau coureur dans le projet. Si vous utilisez des outils pour provisionner et enregistrer de nouveaux coureurs, les jetons utilisés dans ces outils doivent être mis à jour pour refléter la valeur du nouveau jeton.

Déterminer l’adresse IP d’un runner

Il peut être utile de connaître l’adresse IP d’un coureur afin de pouvoir dépanner les problèmes avec ce coureur. GitLab stocke et affiche l’adresse IP en visualisant la source des requêtes HTTP qu’il envoie à GitLab lors de l’interrogation des tâches. L’adresse IP est toujours mise à jour, donc si l’adresse IP du coureur change, elle se met automatiquement à jour dans GitLab.

L’adresse IP des coureurs partagés et des coureurs spécifiques peut être trouvée dans différents endroits.

Déterminer l’adresse IP d’un coureur partagé

Pour afficher l’adresse IP d’un coureur partagé, vous devez avoir un accès administrateur à l’instance GitLab. Pour déterminer ceci :

1. Visitez la zone d’administration >Aperçu >Coureurs.
2. Recherchez le coureur dans le tableau et vous devriez voir une colonne pour l’adresse IP.

Déterminez l’adresse IP d’un coureur spécifique

Pour pouvoir trouver l’adresse IP d’un coureur pour un projet spécifique, vous devez disposer des autorisations de propriétaire pour le projet.

1. Accédez aux paramètres du projet >CI/CD et développez la section Runners.
2. Sur la page de détails, vous devriez voir une ligne pour l’adresse IP.

Utilisez des balises pour limiter le nombre de travaux utilisant le coureur

Vous devez configurer un coureur pour pouvoir exécuter tous les différents types de travaux qu’il peut rencontrer sur les projets sur lesquels il est partagé. Cela poserait un problème pour de grandes quantités de projets, s’il n’y avait pas de balises.

Les balises GitLab CI ne sont pas les mêmes que les balises Git. Les balises GitLab CI sont associées aux coureurs.Les balises Git sont associées aux commits.

En étiquetant un coureur pour les types de tâches qu’il peut gérer, vous pouvez vous assurer que les coureurs partagés exécuteront uniquement les tâches pour lesquelles ils sont équipés.

Par exemple, chez GitLab, nous avons des coureurs étiquetés avec rails s’ils contiennent les dépendances appropriées pour exécuter des suites de tests Rails.

Lorsque vous enregistrez un coureur, son comportement par défaut est de ne marquer que les picktags jobs.To changez cela, vous devez disposer des autorisations de propriétaire pour le projet.

Pour qu’un coureur choisisse des tâches non marquées:

1. Accédez aux paramètres du projet >CI/CD et développez la section Runners.
2. Trouvez le coureur que vous souhaitez sélectionner les tâches non marquées et assurez-vous qu’il est activé.
3. Cliquez sur le bouton crayon.
4. Cochez l’option Exécuter des travaux non étiquetés.
5. Cliquez sur le bouton Enregistrer les modifications pour que les modifications prennent effet.

Voici quelques exemples de scénarios de différentes variations.

runner exécute uniquement des tâches balisées

Les exemples suivants illustrent l’impact potentiel du fait que le runner exécute uniquement des tâches balisées.

Exemple 1 :

1. Le runner est configuré pour exécuter uniquement des tâches balisées et possède la balise docker.
2. Un travail qui a une balise hello est exécuté et bloqué.

Exemple 2 :

1. Le runner est configuré pour exécuter uniquement des tâches balisées et possède la balise docker.
2. Un travail qui a une balise docker est exécuté et exécuté.

Exemple 3:

1. Le runner est configuré pour exécuter uniquement des tâches balisées et possède la balise docker.
2. Une tâche qui n’a pas de balises définies est exécutée et bloquée.

le coureur est autorisé à exécuter des tâches non étiquetées

Les exemples suivants illustrent l’impact potentiel du fait que le coureur est configuré pour exécuter des tâches étiquetées et non étiquetées.

Exemple 1 :

1. Le runner est configuré pour exécuter des tâches non marquées et possède la balise docker.
2. Une tâche qui n’a pas de balises définies est exécutée et exécutée.
3. Un deuxième travail qui a une balise docker définie est exécuté et exécuté.

Exemple 2 :

1. Le runner est configuré pour exécuter des tâches non étiquetées et n’a pas de balises définies.
2. Une tâche qui n’a pas de balises définies est exécutée et exécutée.
3. Un deuxième travail qui a une balise docker définie est bloqué.

Configurer le comportement du runner avec des variables

Vous pouvez utiliser les variables CI/CD pour configurer le comportement du runner Git de manière globale ou pour des tâches individuelles:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (clonage superficiel)
• GIT_CLONE_PATH (répertoires de construction personnalisés)

Vous pouvez également utiliser des variables pour configurer le nombre de fois qu’un runnerattempte certaines étapes de l’exécution du travail .

Stratégie Git

Vous pouvez définir le GIT_STRATEGY utilisé pour récupérer le contenu du référentiel, soit par tâche, soit par tâche dans la section variables :

variables: GIT_STRATEGY: clone

Il y a trois valeurs possibles : clonefetch, et none. Si elles ne sont pas spécifiées, les tâches utilisent le paramètre pipeline du projet.

clone est l’option la plus lente. Il clone le référentiel à partir de zéro pour chaque tâche, garantissant que la copie de travail locale est toujours vierge.Si un arbre de travail existant est trouvé, il est supprimé avant le clonage.

fetch est plus rapide car il réutilise la copie de travail locale (revenant à clone s’il n’existe pas). git clean est utilisé pour annuler les modifications apportées par lastjob, et git fetch est utilisé pour récupérer les commits effectués après l’exécution du dernier travail.

Cependant, fetch nécessite un accès à l’arbre de travail précédent. Cela fonctionne lors de l’utilisation de l’exécuteur shell ou docker car thesetry permet de préserver les arbres de travail et d’essayer de les réutiliser par défaut.

Cela a des limites lors de l’utilisation de l’exécuteur de la machine Docker.

Cela ne fonctionne pas pour l’exécuteur kubernetes, mais une proposition de fonctionnalité existe.L’exécuteur kubernetes clone toujours dans un répertoire temporaire.

Une stratégie Git de none réutilise également la copie de travail locale, mais ignore toutes les opérations GitLab normalement effectuées par GitLab. Les scripts de pré-clonage de GitLab Runner sont également ignorés, s’ils sont présents. Cette stratégie peut signifier que vous devez ajouter des commandes fetch et checkout à votre script .gitlab-ci.yml.

Il peut être utilisé pour des tâches qui fonctionnent exclusivement sur des artefacts, comme une tâche de déploiement.Les données du référentiel Git peuvent être présentes, mais elles sont probablement obsolètes. Vous ne devriez que sur les fichiers introduits dans la copie de travail locale à partir du cache ou des artefacts.

Stratégie de sous-module Git

Nécessite GitLab Runner v1.10+.

La variable GIT_SUBMODULE_STRATEGY est utilisée pour contrôler si / comment les Gitsubmodules sont inclus lors de la récupération du code avant une génération. Vous pouvez les définir de manière globale ou par tâche dans la section variables.

Il y a trois valeurs possibles : nonenormal, et recursive:

• none signifie que les sous-modules ne sont pas inclus lors de la récupération du code de projet. C’est la valeur par défaut, qui correspond au comportement pré-v1.10.

• normal signifie que seuls les sous-modules de niveau supérieur sont inclus. Il est équivalent à:

  git submodule syncgit submodule update --init

• recursive signifie que tous les sous-modules (y compris les sous-modules des sous-modules) sont inclus. Cette fonctionnalité nécessite Git v1.8.1 et versions ultérieures. Lorsque vous utilisez aGitLab Runner avec un exécuteur non basé sur Docker, assurez-vous que la version Git répond à cette exigence. C’est équivalent à:

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

Pour que cette fonctionnalité fonctionne correctement, les sous-modules doivent être configurés (dans .gitmodules) avec soit :

• l’URL HTTP(S) d’un référentiel accessible au public, soit
• un chemin relatif vers un autre dépôt sur le même serveur GitLab. Voir la documentation des sous-modules GIT.

Git checkout

La variable GIT_CHECKOUT peut être utilisée lorsque GIT_STRATEGY est définie sur clone ou fetch pour spécifier si un git checkout doit être exécuté. S’il n’est pas spécifié, la valeur par défaut est true. Vous pouvez les définir globalement ou par tâche dans la section variables.

Si défini sur false, le coureur:

• lorsque vous faites fetch – met à jour le référentiel et laisse la copie de travail sur la révision en cours,
• lorsque vous faites clone – clone le référentiel et laisse la copie de travail sur la branche par défaut.

Si GIT_CHECKOUT est défini sur true, les clone et fetch fonctionnent de la même manière.Le runner vérifie la copie de travail d’une révision liée au pipeline CI:

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

Git clean flags

La variable GIT_CLEAN_FLAGS est utilisée pour contrôler le comportement par défaut de git clean après avoir vérifié les sources. Vous pouvez le définir globalement ou par tâche dans la section variables.

GIT_CLEAN_FLAGS accepte toutes les options possibles de la commande git clean.

git clean est désactivé si GIT_CHECKOUT: "false" est spécifié.

Si GIT_CLEAN_FLAGS est:

• Non spécifié, git clean les drapeaux par défaut sont -ffdx.
• Étant donné la valeur nonegit clean n’est pas exécuté.

Par exemple :

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

Git récupère des drapeaux supplémentaires

La variable GIT_FETCH_EXTRA_FLAGS est utilisée pour contrôler le comportement de git fetch. Vous pouvez le définir globalement ou par tâche dans la section variables.

GIT_FETCH_EXTRA_FLAGS accepte toutes les options de la commande git fetch. Cependant, les drapeaux GIT_FETCH_EXTRA_FLAGS sont ajoutés après les drapeaux par défaut qui ne peuvent pas être modifiés.

Les indicateurs par défaut sont :

• GIT_DEPTH.
• La liste des références.
• Une télécommande appelée origin.

Si GIT_FETCH_EXTRA_FLAGS est :

• Non spécifié, git fetch les drapeaux par défaut sont --prune --quiet avec les drapeaux par défaut.
• Étant donné la valeur nonegit fetch est exécuté uniquement avec les indicateurs par défaut.

Par exemple, les indicateurs par défaut sont --prune --quiet, vous pouvez donc rendre git fetch plus verbeux en remplaçant cela par juste --prune:

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

La configuration ci-dessus entraîne l’appel de git fetch de cette façon:

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

Où $REFSPECS est une valeur fournie au coureur en interne par GitLab.

Clonage superficiel

Vous pouvez spécifier la profondeur de récupération et de clonage en utilisant GIT_DEPTHGIT_DEPTH effectue un clone superficiel du référentiel et peut accélérer considérablement cloning.It peut être utile pour les dépôts avec un grand nombre de commits ou d’anciens binaires volumineux. La valeur est passée à git fetch et git clone.

Dans GitLab 12.0 et versions ultérieures, les projets nouvellement créés ont automatiquement une valeur par défaut git depth de 50.

Si vous utilisez une profondeur de 1 et que vous avez une file d’attente de jobs ou de retryjobs, les jobs peuvent échouer.

La récupération et le clonage de Git sont basés sur une référence, telle qu’un nom de branche, donc runnerscan ne clone pas un commit SHA spécifique. Si plusieurs travaux sont dans la file d’attente, ou si vous réessayez un ancien travail, le commit à tester doit se trouver dans l’historique des IT qui est cloné. La définition d’une valeur trop petite pour GIT_DEPTH peut rendre impossible l’exécution de ces anciens commits et unresolved reference est affichée dans les journaux ob. Vous devriez alors reconsidérer la modification de GIT_DEPTH à une valeur plus élevée.

Les travaux qui reposent sur git describe peuvent ne pas fonctionner correctement lorsque GIT_DEPTH sont définis car seule une partie de l’historique Git est présente.

Pour récupérer ou cloner uniquement les 3 derniers commits:

variables: GIT_DEPTH: "3"

Vous pouvez le définir globalement ou par tâche dans la section variables.

Répertoires de construction personnalisés

Par défaut, GitLab Runner clone le dépôt dans un sous-chemin unique du répertoire $CI_BUILDS_DIR. Cependant, votre projet peut nécessiter le code dans un répertoire spécifique (projets Go, par exemple). Dans ce cas, vous pouvez spécifier la variable GIT_CLONE_PATH pour indiquer au coureur le répertoire dans lequel cloner le répertoire:

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

Le GIT_CLONE_PATH doit toujours être dans $CI_BUILDS_DIR. Le répertoire défini dans $CI_BUILDS_DIR dépend de l’exécuteur et de la configuration des coureurs.builds_dirsetting.

Ceci ne peut être utilisé que lorsque custom_build_dir est activé dans la configuration du coureur.Il s’agit de la configuration par défaut pour les exécuteurs docker et kubernetes.

Gestion de la concurrence

Un exécuteur qui utilise une concurrence supérieure à 1 peut entraîner des échecs. Plusieurs tâches peuvent travailler sur le même répertoire si builds_dir est partagé entre les tâches.

Le coureur n’essaie pas d’empêcher cette situation. C’est à l’administrateur et aux développeurs de se conformer aux exigences de la configuration du runner.

Pour éviter ce scénario, vous pouvez utiliser un chemin unique dans $CI_BUILDS_DIR, car runnerexpose deux variables supplémentaires qui fournissent un ID unique de simultanéité :

• $CI_CONCURRENT_ID : ID unique pour toutes les tâches exécutées dans le exécuteur testamentaire donné.
• $CI_CONCURRENT_PROJECT_ID : ID unique pour tous les travaux exécutés dans l’exécuteur et le projet donnés.

La configuration la plus stable qui devrait bien fonctionner dans n’importe quel scénario et sur n’importe quel exécuteur est d’utiliser $CI_CONCURRENT_IDdans le GIT_CLONE_PATH. Par exemple :

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

Le $CI_CONCURRENT_PROJECT_ID doit être utilisé en conjonction avec $CI_PROJECT_PATH comme $CI_PROJECT_PATH comme $CI_PROJECT_PATH fournit un chemin d’accès à un référentiel. Autrement dit, group/subgroup/project. Par exemple :

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

Chemins imbriqués

La valeur de GIT_CLONE_PATH est développée une fois et l’imbrication de variableswithin n’est pas prise en charge.

Par exemple, vous définissez les deux variables ci-dessous dans votre fichier .gitlab-ci.yml:

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

La valeur de GIT_CLONE_PATH est étendue une fois en $CI_BUILDS_DIR/go/src/namespace/project, et entraîne une défaillance car $CI_BUILDS_DIR n’est pas développé.

Tentatives d’étapes de travail

Vous pouvez définir le nombre de tentatives que le travail en cours essaie d’exécuter les étapes suivantes:

La valeur par défaut est une seule tentative.

Exemple :

variables: GET_SOURCES_ATTEMPTS: 3

Vous pouvez les définir globalement ou par tâche dans la section variables.

Appels système non disponibles sur GitLab.com coureurs partagés

GitLab.com les coureurs partagés courent sur CoreOS. Cela signifie que vous ne pouvez pas utiliser certains appels système, comme getlogin, à partir de la bibliothèque standard C.

Paramètres d’artefact et de cache

Les paramètres Artefact et cache contrôlent le taux de compression des artefacts et des caches.Utilisez ces paramètres pour spécifier la taille de l’archive produite par une tâche.

• Sur un réseau lent, les téléchargements peuvent être plus rapides pour les archives plus petites.
• Sur un réseau rapide où la bande passante et le stockage ne sont pas un problème, les téléchargements peuvent être plus rapides en utilisant le taux de compression le plus rapide, bien que l’archive produite soit plus grande.

Pour que les pages GitLab servent à des requêtes de plage HTTP, les artefacts doivent utiliser le paramètre ARTIFACT_COMPRESSION_LEVEL: fastest, car seules les archives zip non compressées prennent en charge cette fonctionnalité.

Un compteur peut également être activé pour fournir le taux de transfert pour les téléchargements et les téléchargements.

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"