GitLab CI/CD

GitLab propose une fonctionnalité d’intégration et déploiement continu appelé GitLab CI/CD. Les informations concernant l’intégration continue (pipelines, jobs, environnements, etc) sont affichées dans l’onglet [CI/CD] du menu vertical GitLab.

L’instance Gitlab de l’IN2P3 met à la disposition de ses utilisateurs un ensemble de runners Gitlab, en architecture x64 et ARM, pour exécuter leurs jobs de CI/CD. Cependant, ces runners d’instance (aussi appelés runners publics) sont partagés pour plusieurs milliers d’utilisateurs et leurs ressources sont très limitées. Ces runners n’ont pas de privilège. Il leur sera notamment impossible d’utiliser la fonction Docker-in-Docker. Veuillez vous référer aux notes des administrateurs pour plus d’information.

De plus, la confidentialité des données et du code traités par ces runners n’est pas garantie car les ressources sont mutualisées. Enfin, les ressources de chaque job sont également limitées, pour éviter les abus et permettre un accès équitable aux ressources.

Important

Chaque job dispose de 4 vCPU et de 2GB de RAM. Le temps d’exécution d’un job ne peut pas dépasser 1 heure: si cette limite est dépassée, le job échoue.

Construire une infrastructure CI/CD

Les runners publics sont mis à disposition gracieusement à tous les utilisateurs du service, dans un but didactique et afin de permettre à tous de débuter facilement sur Gitlab CI. Toutefois, tout usage destiné à de la production ou du développement d’envergure, nécessitant des configurations spécifiques ou une capacité supérieure à ce qui est ainsi fournit, devrait impliquer la mise en place d’un runner Gitlab dédié.

Vous pouvez facilement déployer et utiliser votre propre infrastructure CI pour vos projets. Plus d’informations sur la documentation de GitLab runner.

Note

Lorsque vous utilisez votre propre infrastructure CI/CD (c’est-à-dire vos propres runners), il est généralement recommandé de désactiver les runners d’instance au niveau des projets et groupes concernés, afin d’éviter que vos jobs ne soient exécutés par les mauvais runners. Veuillez vous référer le paragraphe Sélectionner les runners.

Si vous ne disposez pas de ressources sur lesquelles vous appuyer pour déployer une telle infrastructure, et que votre projet fait partie d’une collaboration supportée par l’IN2P3, vous pouvez faire une demande de ressources afin d’obtenir les machines nécessaires auprès du CC-IN2P3.

Pour toute demande de ressource ou aide merci de contacter notre support utilisateurs.

Sélectionner les runners

Vous pouvez sélectionner les runners qui exécuteront vos jobs CI/CD dans vos projets Gitlab grâce au menu CI/CD des paramètres. De plus, une sélection plus fine est possible grâce au tags keyword dans votre fichier de configuration Gitlab CI.

Les jobs n’utilisant pas le tag keyword sera considéré comme « non tagué » et pourra être exécuté par n’importe quel runner autorisé à exécuter les jobs non tagués.

Les runners d’instance du Gitlab IN2P3 utilisent les tags suivants :

Tags des runners d’instance

Type	Execute les jobs non taggés ?	Limites par job	Architecture	Tags associés
public	oui	4 vCPUs, 2GB RAM	x64	ccin2p3 ; x64
public-arm	non	4 vCPUs, 2GB RAM	ARM	ccin2p3 ; ARM

Ci-après, un exemple de job qui peut être pris par un runner d’instance ARM :

---
job1:
  tags:
    - ccin2p3
    - arm
  script:
    - echo 'slacking off at work!'

Attention

L’utilisation du tag ccin2p3 seul provoquera un résultat imprédictible : n’importe quel runner public pourra exécuter ces jobs.