Мы используем gitlab ci с совместно используемыми проигрывателями для непрерывной интеграции. Для каждой сборки бегун загружает множество артефактов maven.
Есть ли способ настроить gitlab ci для кеширования этих артефактов, чтобы мы могли ускорить процесс построения, предотвращая повторную загрузку одного и того же артефакта снова и снова?
Gitlab CI позволяет вам определять определенные пути, которые содержат данные, которые должны быть кэшированы между сборками, на основе каждого задания или сборки (подробнее см. Здесь). В сочетании с рекомендацией khmarbaise это можно использовать для кэширования зависимостей между несколькими сборками.
Пример, который кэширует все зависимости работы в вашей сборке:
cache:
paths:
- .m2/
variables:
MAVEN_OPTS: "-Dmaven.repo.local=.m2"
maven_job:
script:
- mvn clean install
Согласно разговору о системе отслеживания проблем 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"
Вы можете добавить папку кэша в конфигурацию бегуна 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
Принятый ответ не сделал это для меня.
Как упоминалось zlobster, у ребят из GitLab есть этот удивительный репозиторий, где вы можете найти подходящий пример файла .gitlab-ci.yml, используемого для проектов Maven.
По сути, вам нужны следующие строки:
cache:
paths:
- .m2/repository
Имейте в виду, что если вы решите добавить локальный кеш для определенной работы, глобальный, добавленный выше, будет заменен. Подробнее об этом здесь.
Если вы используете 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
Я смог использовать том хоста для .m2 к своему .m2 репозитория .m2. Это также имело преимущество совместного доступа к моему файлу settings.xml (что может захотеть не каждый). Я обнаружил, что это быстрее, чем использование упомянутых решений для cache.
[[runners]]
[runners.docker]
volumes = ["/home/<user>/.m2:/root/.m2"]
Есть другой подход. Не используйте кеш 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 и загрузки зависимостей один раз.
Плюсы: