Как включить кеширование артефакта maven для gitlab ci runner?

Ответ 1

Gitlab CI позволяет вам определять определенные пути, которые содержат данные, которые должны быть кэшированы между сборками, на основе каждого задания или сборки (подробнее см. Здесь). В сочетании с рекомендацией khmarbaise это можно использовать для кэширования зависимостей между несколькими сборками.

Пример, который кэширует все зависимости работы в вашей сборке:

cache:
  paths:
    - .m2/

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

maven_job:
  script:
    - mvn clean install

Ответ 2

Согласно разговору о системе отслеживания проблем GitLab, мне удалось изменить путь к локальному репозиторию Maven и поместить его в каталог ./.m2/repository/, который мы затем сохраним между запусками, добавив этот глобальный блок в конфигурацию CI:

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

К сожалению, согласно fooobar.com/questions/4461186/... путь локального репозитория maven может быть задан только при каждом запуске с -Dmaven.repo.local или путем редактирования вашего settings.xml, что является утомительной задачей в скрипте конфигурации gitlab-ci. Один из вариантов - установить переменную с параметрами Maven по умолчанию и передавать ее при каждом запуске.

Также очень важно, чтобы локальный репозиторий Maven был дочерним по отношению к текущему каталогу. По какой-то причине поместить его в /cache или /builds у меня не получилось, хотя кто-то из GitLab утверждал, что должно.

Пример рабочего gitlab-ci.yml конфигурации gitlab-ci.yml для 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"

Ответ 3

Вы можете добавить папку кэша в конфигурацию бегуна gitlab-ci и передать ее в 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

Ответ 4

Принятый ответ не сделал это для меня.

Как упоминалось zlobster, у ребят из GitLab есть этот удивительный репозиторий, где вы можете найти подходящий пример файла .gitlab-ci.yml, используемого для проектов Maven.

По сути, вам нужны следующие строки:

cache:
  paths:
    - .m2/repository

Имейте в виду, что если вы решите добавить локальный кеш для определенной работы, глобальный, добавленный выше, будет заменен. Подробнее об этом здесь.

Ответ 5

Если вы используете kubernetes как исполнитель для gitlab-runner, вы также можете использовать кеш maven. Я решил иметь постоянный кеш на NFS с k8s PV (но другой тип тома поддерживается gitlab-runner). Следующая конфигурация не использует функцию gitlab кеша из-за сохраняемости, предлагаемой NFS.

1) создать PersistentVolume в вашем кластере, например здесь с NFS (адаптироваться к вашему уровню сохранения и вашим параметрам):

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) Ссылка на PV, чтобы получить заявку в качестве объема в контейнере бегуна:

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

Примечание (03/09/18): параметр командной строки для этих параметров еще не существует. Существует открытая проблема.

3) Укажите тот же путь для кеша gitlab-runner:

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

или

--cache-dir "/path/to/mount/point1" в интерактивном режиме

4) используйте каталог "/path/to/mount/point1" в -Dmaven.repo.local

Ответ 6

Я смог использовать том хоста для .m2 к своему .m2 репозитория .m2. Это также имело преимущество совместного доступа к моему файлу settings.xml (что может захотеть не каждый). Я обнаружил, что это быстрее, чем использование упомянутых решений для cache.

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

Ответ 7

Есть другой подход. Не используйте кеш gitlab и используйте настраиваемое (для проекта) изображение докера.

Некоторые подробности:

Прежде всего, вам нужно создать образ док-станции maven, в котором представлены все (или большинство) необходимые для ваших проектных зависимостей. Опубликуйте его в своем реестре (он есть у gitlab) и используйте его для любой работы, выполняемой maven.

Для создания такого изображения я обычно создаю дополнительную работу в CI, запускаемую вручную. Вы должны запустить его на начальном этапе и когда зависимости проекта сильно изменены.

Рабочий образец можно найти здесь:

https://gitlab.com/alexej.vlasov/syncer/blob/master/.gitlab-ci.yml - этот проект использует подготовленное изображение, а также имеет работу по подготовке этого изображения.

https://gitlab.com/alexej.vlasov/maven/blob/master/Dockerfile - dockerfile для запуска maven и загрузки зависимостей один раз.

Плюсы:

• не нужно каждый раз загружать зависимости - они находятся внутри изображение докера (и слои докера кэшируются на бегунах)
• не нужно загружать артефакты после завершения работы
• кеш не загружается в задания не использую maven