Hoe kan ik maven artifact caching voor GitLab CI runner inschakelen?

We gebruiken GitLab CI met gedeelde hardlopers voor onze continue integratie. Voor elke build downloadt de hardloper tonnen maven-artefacten.

Is er een manier om GitLab CI te configureren om die artefacten in de cache te plaatsen, zodat we het bouwproces kunnen versnellen door te voorkomen dat hetzelfde artefact steeds opnieuw wordt gedownload?

Antwoord 1, autoriteit 100%

Met Gitlab CI kun je bepaalde paden definiëren, die gegevens bevatten die tussen builds moeten worden opgeslagen, per taak of per build (zie hiervoor meer details). In combinatie met de aanbeveling van khmarbaise kan dit worden gebruikt om afhankelijkheden tussen meerdere builds te cachen.

Een voorbeeld dat alle taakafhankelijkheden in uw build in de cache opslaat:

cache:
  paths:
    - .m2/repository
variables:
  MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository"
maven_job:
  script:
    - mvn clean install

Antwoord 2, autoriteit 16%

Volgens het gesprek op GitLab’s probleemtracker, het is me gelukt om het Maven lokale repository-pad te wijzigen en het in de ./.m2/repository/-directory te plaatsen, wat betekent dat we zullen blijven bestaan ​​tussen runs door dit globale blok toe te voegen aan de CI-configuratie:

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

Helaas kan volgens dit StackOverflow-antwoordhet maven lokale repository-pad alleen worden ingesteld bij elke run met -Dmaven.repo.localof door uw settings.xmlte bewerken, wat een vervelende taak is om te doen in een gitlab-ci configuratiescript. Een optie zou zijn om een ​​variabele in te stellen met de standaard Maven-opties en deze aan elke run door te geven.

Het is ook van cruciaal belang dat de lokale Maven-repository een kind is van de huidige map. Om de een of andere reden werkte het in /cacheof /buildsniet voor mij, hoewel iemand van GitLab beweerde dat het zou moeten.

Voorbeeld van een werkend gitlab-ci.ymlconfiguratiebestand voor 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"

Antwoord 3, autoriteit 10%

Het geaccepteerde antwoord deed het niet voor mij.

Zoals zlobsteral zei, hebben de jongens van GitLab deze geweldige repositorywaar je een goed voorbeeld kunt vinden van het .gitlab-ci.yml-bestand dat wordt gebruikt voor Maven-projecten.

Kortom, wat je nodig hebt zijn deze regels:

cache:
  paths:
    - .m2/repository

Houd er rekening mee dat als u besluit een lokale cache toe te voegen voor een bepaalde taak, de hierboven toegevoegde globale cache wordt vervangen. Meer hierover hier.

Antwoord 4, autoriteit 5%

Je kunt de cachemap toevoegen aan de gitlab-ci runner-configuratie en deze doorgeven aan 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

Antwoord 5, autoriteit 4%

Als je kubernetes als uitvoerder voor gitlab-runner gebruikt, kun je ook de maven-cache gebruiken. Ik heb ervoor gekozen om een ​​permanente cache op NFS te hebben met k8s PV (maar andere volumetypes worden ondersteund door gitlab-runner). De volgende configuratie maakt geen gebruik van de cachegitlab-functie vanwege de aangeboden persistentie door NFS.

1) maak een PersistentVolume op uw cluster, bijvoorbeeld hier met NFS (aanpassen aan uw persistentielaag en uw opties):

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) Verwijs naar de PV om een ​​claim als een volume in de runner pod te krijgen:

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

Opmerking (03/09/18) : Een opdrachtregeloptie voor deze parameters bestaat nog niet. Er is een open probleem.

3) Specificeer hetzelfde pad voor de gitlab-runner cache :

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

of

--cache-dir "/path/to/mount/point1"in interactieve modus

4) gebruik de map “/path/to/mount/point1” in de optie -Dmaven.repo.local

Antwoord 6, autoriteit 3%

Ik kon een hostvolume gebruiken om mijn .m2repository-directory te delen. Dit had ook het voordeel dat ik mijn bestand settings.xmlkon delen (wat niet iedereen wil). Ik vond dit sneller dan het gebruik van de genoemde cache-oplossingen.

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

Antwoord 7, autoriteit 2%

Er is een andere benadering. Gebruik geen gitlab-cache en gebruik een aangepaste (per project) docker-image.

Enkele details:

Allereerst moet u een maven docker-image maken waarin alle (of de meeste) vereisten voor uw projectafhankelijkheden worden weergegeven. Publiceer het naar uw register (gitlab heeft er een) en gebruik het voor elke taak die maven uitvoert.

Om zo’n afbeelding te maken, maak ik meestal een extra taak in CI die handmatig wordt geactiveerd. U moet het in de beginfase activeren en wanneer projectafhankelijkheden sterk worden gewijzigd.

Een werkvoorbeeld is hier te vinden:

https://gitlab.com/alexej. vlasov/syncer/blob/master/.gitlab-ci.yml
– dit project gebruikt de voorbereide afbeelding en het heeft ook een taak om deze afbeelding voor te bereiden.

https://gitlab.com/alexej.vlasov/maven/blob /master/Dockerbestand
– dockerfile om maven uit te voeren en eenmaal afhankelijkheden te downloaden.

De pluspunten:

• hoeft niet elke keer afhankelijkheden te downloaden – ze bevinden zich in een
  docker-afbeelding (en docker-lagen worden in de cache op de lopers opgeslagen)
• hoef geen artefacten te uploaden wanneer de taak is voltooid
• cache wordt niet gedownload in jobs, gebruik maven niet

Antwoord 8

U hoeft MAVEN_OPTS niet te declareren in de variabelensectie wanneer u de variabele CI_PROJECT_DIR gebruikt (het volledige pad waar de repository wordt gekloond en waar de taak wordt uitgevoerd)

cache:
    key: maven-cache
    paths:
    - $CI_PROJECT_DIR/.m2/