web-dev-qa-db-fra.com

Comment utiliser Gitlab CI pour construire un projet Java Maven?

J'expérimente sans succès, j'utilise un Gitlab hébergé sur Linux et j'essaie de comprendre les fonctionnalités de 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 Java projets Maven.

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

58
MRK187

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

image: maven:3-jdk-7

build:
  script: "mvn install -B"

Noter la -Bflag , recommandé pour une utilisation non interactive.

Autant que je sache, peu importe que le coureur soit partagé ou spécifique.

55
rolve

Je voudrais ajouter un peu d'information ici les gars. Commençons par dissiper toute confusion concernant les coureurs partagés et spécifiques.

Partage partagé: Comme son nom l'indique, les partants partagés sont les instances de flux de processus de construction qui peuvent être utilisées pour exécuter les travaux de chaque projet de votre instance gitlab installée. ayant Autorisé l'option Coureurs partagés activée. Bien entendu, pour ce faire, vous aurez besoin de droits administratifs. Selon la documentation actuelle de gitlab, seule l’utilisation avec des droits d’administration permet de définir un coureur partagé.

runner spécifique Ce type de runner exécute les travaux d'un seul projet.

De plus, voici quelques points importants à garder à l’esprit lorsque vous choisissez Runner pour vos projets.

  1. Les projets partagés sont utiles pour les travaux ayant des exigences similaires, entre plusieurs projets. Plutôt que d'avoir plusieurs coureurs inactifs 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. Des coureurs spécifiques sont utiles pour les travaux ayant exigences spéciales ou projets avec une demande spécifique. Si un travail a certaines exigences, vous pouvez configurer le coureur spécifique en gardant cela à l'esprit, sans avoir à le faire pour tous les coureurs. Par exemple, si vous souhaitez déployer un certain projet, vous pouvez configurer un coureur 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 globale de tous les exécuteurs disponibles pour gitlab runner. Gitlab nous a facilité la tâche en fournissant de la documentation Nice sur ici en expliquant quelles sont les différentes options que vous obtiendrez 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

5
Milan Savaliya

J'ai passé pas mal de temps à essayer de mettre en place nos Java sur Gitlab CI. Je l'ai utilisé avec un certain succès. Comme mentionné par rolve, la solution la plus simple consiste à utiliser une image du dépôt officiel: https://hub.docker.com/_/maven

Cependant, nous avons un proxy d'entreprise qui faisait en sorte que mes versions obtiennent des demandes de délai d'expiration lors de l'extraction des dépendances du projet. J'ai essayé de nombreuses solutions et suis finalement tombé sur ce post: https://gitlab.com/gitlab-org/gitlab-ce/issues/15167 .

Le message 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 auquel on peut accéder via les générations. L'idée est que vous pouvez écrire un fichier de configuration maven local en . Gitlab-ci.yml pour configurer votre répertoire de cache et votre proxy.

before_script:
  -echo '<settings
          xmlns="http://maven.Apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.Apache.org/SETTINGS/1.0.0
          https://maven.Apache.org/xsd/settings-1.0.0.xsd">
          <localRepository>/cache/.m2</localRepository>
          <proxies>
              <proxy>
                  <active>true</active>
                  <protocol>'$PROXY_PROTOCOL'</protocol>
                  <Host>'$PROXY_Host'</Host>
                  <port>'$PROXY_PORT'</port>
              </proxy>
          </proxies>
      </settings>' > $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 servent uniquement à savoir si les paramètres de 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 deploy_debug Le travail consiste à voir ce qui a été généré dans votre répertoire cible.

4
UltimaWeapon

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

Alors, pourquoi ne pas commencer par ce qui suit ?:

job1:
  script: "mvn package"

Cela ne fonctionnera vraisemblablement que si Maven est déjà installé, vous aurez donc besoin d'un coureur qui le supporte.

Je n'ai pas utilisé GitLab mais documentation suggère que vous puissiez le personnaliser davantage pour utiliser image officielle de Maven Docker afin de réaliser les versions. Cela semble très intéressant, mais je conviens que la documentation manque à un exemple Java.

4
Mark O'Connor

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"
2
emeraldjava