Comment utiliser Gitlab CI pour créer un projet Java Maven?

J’expérimente sans succès, je dirige un Gitlab hébergé sous Linux et j’essaie de comprendre les fonctionnalités du CI.

Selon la documentation Gitlab, il vous suffit de créer un fichier .gitlab-ci.yml , l’implémentation Gitlab de Travis-CI. Maintenant, de par son apparence, vous pouvez accomplir beaucoup de choses avec le .gitlab-ci.yml , mais une grande partie de la documentation fait référence à Ruby et à d’autres langages. Rien n’est dit sur la façon de construire des projets Java Maven.

Comment puis-je créer une application simple en Java? Puis-je utiliser le runner partagé, ou devrais-je utiliser un runner spécifique, dans ce cas, quelle ou quelle implémentation de runner devrais-je choisir: ssh, docker ou shell? Alors, que dois-je mettre dans le fichier .gitlab-ci.yml au moins pour construire le projet avec Maven?

Enregistrez un runner Docker et utilisez l’une des images officielles de Maven Docker , par exemple, maven:3-jdk7 dans votre fichier .gitlab-ci.yml :

 image: maven:3-jdk-7 build: script: "mvn install -B" 

Notez l’ indicateur -B , recommandé pour une utilisation non interactive.

Pour autant que je sache, le fait que le coureur soit partagé ou spécifique importe peu.

La documentation décrit la syntaxe YAML utilisée pour contrôler les builds:

Alors pourquoi ne pas essayer de commencer avec les éléments suivants:

 job1: script: "mvn package" 

Vraisemblablement, cela ne fonctionnera que si Maven est déjà installé, vous aurez donc besoin d’un runner qui le supporte.

Je n’ai pas utilisé GitLab mais la documentation suggère que vous pouvez personnaliser davantage l’image pour utiliser l’ image officielle de Maven Docker pour effectuer les builds. Cela semble très intéressant, mais je suis d’accord pour dire que la documentation manque un exemple Java.

Je voudrais append quelques informations ici les gars. D’abord, effacer une certaine confusion concernant le coureur partagé et spécifique.

Shared Runner: comme son nom l’indique, les coureurs partagés sont les instances de stream de processus de génération qui peuvent être utilisées pour exécuter des travaux pour chaque projet de votre instance gitlab installée, avec l’option Utilisateurs autorisés partagés activée. Pour faire cela naturellement, vous auriez besoin de droits administratifs. Conformément à la documentation actuelle de gitlab, seule l’utilisation avec des droits d’administrateur permet de définir le runner partagé.

coureur spécifique Ce type de coureur exécute les travaux d’un seul projet.

En outre, ce sont quelques points importants à garder à l’esprit lors du choix du coureur pour vos projets.

  1. Les coureurs partagés sont utiles pour les tâches ayant des exigences similaires, entre plusieurs projets . Plutôt que d’avoir plusieurs coureurs au ralenti pour de nombreux projets, vous pouvez avoir un seul ou un petit nombre de coureurs qui gèrent plusieurs projets. Cela facilite la maintenance et la mise à jour des coureurs pour un ensemble commun de projets.
  2. Les coureurs spécifiques sont utiles pour les travaux ayant des exigences particulières ou pour des projets avec une demande spécifique . Si un travail a certaines exigences, vous pouvez configurer le coureur spécifique en tenant compte de cela, sans avoir à le faire pour tous les coureurs. Par exemple, si vous souhaitez déployer un projet spécifique, vous pouvez configurer un programme spécifique pour qu’il dispose des informations d’identification appropriées.

Maintenant, pour sélectionner le bon exécuteur pour le projet, il est très important que nous ayons une vue d’oiseau sur tous les exécuteurs disponibles pour gitlab runner. Gitlab nous a facilité la tâche en fournissant une documentation détaillée expliquant ici quelles sont les différentes options que vous aurez avec différents exécuteurs.

Si vous souhaitez en savoir plus sur les coureurs et les différents exécuteurs, je vous suggère de commencer par cet article, Gitlab Runner

J’utilise cette commande mais en général la documentation sur les builds java / maven semble assez rare

 maven-package: script: "mvn install -B" 

J’ai passé pas mal de temps à essayer de configurer nos projets Java sur Gitlab CI. Je l’ai fait fonctionner avec un certain succès. Comme mentionné par rolve, la solution la plus simple consiste à utiliser une image du repository officiel: https://hub.docker.com/_/maven

Cependant, nous avons un proxy d’entreprise qui provoquait des demandes de délai d’attente lors de la génération des dépendances du projet. J’ai essayé plusieurs solutions et j’ai finalement trouvé ce post: https://gitlab.com/gitlab-org/gitlab-ce/issues/15167 .

Le post lui-même concerne la configuration de maven pour mettre en cache les dépendances téléchargées dans un référentiel local accessible depuis plusieurs versions. L’idée est que vous pouvez écrire un fichier de configuration maven local dans .gitlab-ci.yml pour configurer votre répertoire de cache et votre proxy.

 before_script: -echo ' /cache/.m2   true '$PROXY_PROTOCOL' '$PROXY_HOST' '$PROXY_PORT'   ' > $HOME/.m2/settings.xml build_debug1: stage: build script: "echo $PROXY_HOST" build_debug2: stage: build script: "cat $HOME/.m2/settings.xml" build_maven: stage: build script: "mvn $MAVEN_CLI_OPTS package" artifacts: paths: - target/*.jar deploy_debug1: stage: package script: "ls target/" 

Notez que les travaux de débogage de génération ne permettent que de voir si les parameters du proxy ont été correctement injectés. Vous pouvez définir les variables d’environnement proxy comme des secrets à l’aide de Gitlab en allant dans Projet -> Paramètres -> Pipelines CI / CD -> Variables secrètes.

Le dernier travail deploy_debug consiste à voir ce qui a été généré dans votre répertoire cible.