web-dev-qa-db-fra.com

Comment activer la mise en cache d'artefacts maven pour gitlab ci runner?

Nous utilisons gitlab ci avec des coureurs partagés pour effectuer notre intégration continue. Pour chaque construction, le coureur télécharge des tonnes d'artefacts Maven.

Existe-t-il un moyen de configurer gitlab ci pour mettre en cache ces artefacts afin d'accélérer le processus de construction en empêchant le téléchargement répétitif du même artefact?

mavengitlab-cigitlab-ci-runnergitlab-8
43
helt

Gitlab CI vous permet de définir certains chemins, contenant des données devant être mises en cache entre les générations, par travail ou construction (voir ici pour plus de détails). En combinaison avec la recommandation de khmarbaise, ceci peut être utilisé pour mettre en cache des dépendances entre plusieurs versions.

Un exemple qui met en cache toutes les dépendances de travail dans votre construction:

cache:
  paths:
    - .m2/

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2"

maven_job:
  script:
    - mvn clean install
53
andban

Selon la conversation sur suivi des problèmes de GitLab , j'ai réussi à modifier le chemin du référentiel local Maven et à le mettre dans ./.m2/repository/ répertoire, qui persistera entre les exécutions en ajoutant ce bloc global à la configuration de CI:

cache:
  paths:
    - ./.m2/repository
  # keep cache across branch
  key: "$CI_BUILD_REF_NAME"

Malheureusement, selon cette réponse StackOverflow , le chemin d'accès au référentiel local maven ne peut être défini qu'à chaque exécution avec -Dmaven.repo.local _ ou en éditant votre settings.xml, tâche fastidieuse dans un script de configuration gitlab-ci. Une option serait de définir une variable avec les options Maven par défaut et de la transmettre à chaque exécution.

De plus, il est essentiel que le référentiel Maven local soit un enfant du répertoire actuel. Pour une raison quelconque, le mettre dans /cache ou /builds n'a pas fonctionné pour moi, même si quelqu'un de GitLab a affirmé que cela devrait être le cas.

Exemple de travail gitlab-ci.yml fichier de configuration pour Maven + Java:

image: maven:3-jdk-8

variables:
  MAVEN_OPTS: "-Djava.awt.headless=true -Dmaven.repo.local=./.m2/repository"
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version"

cache:
  paths:
    - ./.m2/repository
  # keep cache across branch
  key: "$CI_BUILD_REF_NAME"

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - "mvn clean compile $MAVEN_CLI_OPTS"
  artifacts:
    paths:
      - target/

unittest-job:
  stage: test
  dependencies:
    - build-job
  script:
    - "mvn package $MAVEN_CLI_OPTS"
  artifacts:
    paths:
      - target/

integrationtest-job:
  stage: test
  dependencies:
    - build-job
  script:
    - "mvn verify $MAVEN_CLI_OPTS"
  artifacts:
    paths:
      - target/

deploy-job:
  stage: deploy
  artifacts:
    paths:
      - "target/*.jar"
10
Ondrej Skopek

La réponse acceptée ne l'a pas fait pour moi.

Comme zlobster a été mentionné, les gars de GitLab ont ce fabuleux référentiel où vous pouvez trouver un bon exemple du .gitlab-ci.yml fichier utilisé pour les projets Maven.

En gros, vous avez besoin de ces lignes:

cache:
  paths:
    - .m2/repository

N'oubliez pas que si vous décidez d'ajouter un cache local pour un travail donné, le cache global ajouté ci-dessus sera remplacé. Plus sur ceci ici .

5
Ionuț Ciuta

Vous pouvez ajouter un dossier de cache à la configuration du coureur gitlab-ci et le transmettre à maven.

/ etc/gitlab-runner/config.toml

[[runners]]
...
  [runners.docker]
  ...
   volumes = ["/cache", "/.m2"]
  ...

. gitlab-ci.yml

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=/.m2"

build:
  script:
    - mvn package
5
Alexey

Si vous utilisez kubernetes en tant qu'exécuteur pour gitlab-runner, vous pouvez également utiliser le cache maven. J'ai choisi d'avoir un cache persistant sur NFS avec k8s PV (mais les autres types de volumes sont pris en charge par gitlab-runner ). La configuration suivante n'utilise pas la fonctionnalité cache gitlab en raison de la persistance offerte par NFS.

1) Créez un volume persistant sur votre cluster, par exemple ici avec NFS (adaptez-vous à votre couche de persistance et à vos options):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: gitlabrunner-nfs-volume
spec:
  capacity:
    storage: 10Gi
  mountOptions:
    - nolock
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    path: /gitlabrunner
    server: 1.2.3.4

2) Référencez le PV pour obtenir une réclamation sous forme de volume dans le conteneur de coureur:

[[runners.kubernetes.volumes.pvc]]
  name = "pvc-1"
  mount_path = "/path/to/mount/point1"

Remarque (03/09/18): Une option de ligne de commande pour ces paramètres n'existe pas encore. Il y a un open issue .

3) Spécifiez le même chemin pour le cache gitlab-runner:

[[runners]]
  executor = "kubernetes"
  # ...
  cache_dir = "/path/to/mount/point1"

ou

--cache-dir "/path/to/mount/point1" en mode interactif

4) utilisez le répertoire "/ path/to/mount/point1" dans le répertoire -Dmaven.repo.local option

1
Nicolas Pepinster

J'ai pu utiliser un volume hôte pour partager mes .m2 répertoire de référentiel. Cela avait aussi l'avantage de partager sur mon settings.xml fichier (que tout le monde ne voudra peut-être pas). J'ai trouvé que c'était plus rapide que d'utiliser les solutions cache mentionnées.

[[runners]]
  [runners.docker]
    volumes = ["/home/<user>/.m2:/root/.m2"]
0
pez

Il y a une autre approche. N'utilisez pas le cache gitlab et utilisez une image de menu fixe personnalisée (par projet).

Quelques détails:

Tout d'abord, vous devez créer une image docker maven où toutes (ou la plupart) des éléments requis pour les dépendances de votre projet sont présentés. Publiez-le dans votre registre (gitlab en a un) et utilisez-le pour tout travail exécutant maven.

Pour créer une telle image, je crée généralement un travail supplémentaire dans CI déclenché manuellement. Vous devez le déclencher au stade initial et lorsque les dépendances du projet sont fortement modifiées.

Échantillon de travail peut être trouvé ici:

https://gitlab.com/alexej.vlasov/syncer/blob/master/.gitlab-ci.yml - Ce projet utilise l'image préparée et il a également pour tâche de préparer cette image.

https://gitlab.com/alexej.vlasov/maven/blob/master/Dockerfile - dockerfile pour exécuter les dépendances maven et download une fois.

Les pros:

  • pas besoin de télécharger des dépendances à chaque fois - elles sont dans une image de menu fixe (et les couches de menu fixe sont mises en cache sur les coureurs)
  • pas besoin de télécharger des artefacts à la fin du travail
  • les caches ne sont pas téléchargés dans les jobs n'utilisent pas maven
0
Alexey Vlasov