как предотвратить загрузку sbt GitLab ci каждый раз?

у нас есть play2/scala приложение, которое мы строим с помощью GitLab ci.

наши .gitlab-ci.yml (по крайней мере, важная часть) выглядит следующим образом:

image: hseeberger/scala-sbt

variables:
  SBT_GLOBAL_BASE_DIR: "$CI_PROJECT_DIR/cache/.sbt"
  IVY2_CACHE_DIR: "$CI_PROJECT_DIR/cache/.ivy2"
  SBT_BOOT_DIR:  "$CI_PROJECT_DIR/cache/.sbt/boot"
  M2_HOME_DIR: "$CI_PROJECT_DIR/cache/.m2"

before_script:
  # Log the sbt version
  - sbt sbt-version

build:
  stage: build
  script:
    - ./build.sh

С build.sh:

sbt -Dsbt.global.base=$SBT_GLOBAL_BASE_DIR 
  -Dsbt.ivy.home=$IVY2_CACHE_DIR 
  -Dsbt.boot.directory=$SBT_BOOT_DIR 
  compile

к сожалению, наш конвейер всегда работает около 30-40 минут со всеми шагами (сборка, проверка, развертывание). Большую часть времени он проводит, загружая sbt снова и снова, что действительно раздражает.

я не мог знаю достаточно о gitlab ci runners но из моего понимания, используя hseeberger / scala-sbt как изображения, sbt должен быть глобально доступен, и не должно быть необходимости загружать его.

тогда же этой решение от gitlab не будет необходимо.

во всяком случае, я был бы рад, если sbt не будет загружаться полностью 6 раз во время каждого развертывания, когда сервер запускает любой .

может кто-нибудь объяснить меня, как использовать право image или image в праве так или иначе, как я могу кэшировать sbt вещи?

обновление

за последние дни я много воевал с docker и gitlab ci. Я обнаружил, что эти проблемы почти такие же, как описано в не загружайте интернет. Кажется, что это сложная задача, чтобы иметь все зависимости и лучше всего сделать, установив их. Это, к сожалению, невозможно как таковое на общий бегун GitLab ci.

я пошел дальше и обнаружил sbt-docker что позволяет создавать контейнеры docker из . С базовый подход я попытался включить все локально доступные зависимости для проекта в контейнер как глобальные Плагины sbt. Но и это не помогло.

моим последним открытием был этот ответ относительно maven решение и пытался переведи это на наш :

.gitlab-ci.в формате YML

image: hseeberger/scala-sbt

variables:
  MAVEN_OPTS: -Dmaven.repo.local=/cache/maven.repository

stages:
  - build
  - test
  - staging
  - deploy

build:
  stage: build
  script:
    - sbt compile -Dsbt.ivy.home=/cache/.ivy2 -Dsbt.global.base=/cache/.sbt/0.13 -Dsbt.boot.directory=/cache/.sbt/boot -Dsbt.repository.config=/cache/.sbt/repositories

я могу получить доступ к gitlab ci снова журналы. Они выглядят в основном следующим образом:

[info] Loading project definition from /builds/kwiqjobs/backend/project
[info] Updating {file:/builds/kwiqjobs/backend/project/}backend-build...
[info] Resolving com.typesafe.play#sbt-plugin;2.5.4 ...

[info] Resolving com.typesafe.play#sbt-plugin;2.5.4 ...

[info] Resolving com.typesafe.play#sbt-routes-compiler_2.10;2.5.4 ...

[info] Resolving com.typesafe.play#sbt-routes-compiler_2.10;2.5.4 ...

[info] Resolving org.scala-lang#scala-library;2.10.6 ...

[info] Resolving com.typesafe.play#twirl-api_2.10;1.1.1 ...

[info] Resolving com.typesafe.play#twirl-api_2.10;1.1.1 ...

... a **lot** more

[info]  [SUCCESSFUL ] com.typesafe.sbt#sbt-twirl;1.1.1!sbt-twirl.jar (1033ms)
[info] downloading https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-native-packager/scala_2.10/sbt_0.13/1.0.3/jars/sbt-native-packager.jar ...
[info]  [SUCCESSFUL ] com.typesafe.sbt#sbt-native-packager;1.0.3!sbt-native-packager.jar (954ms)
[info] downloading https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-web/scala_2.10/sbt_0.13/1.3.0/jars/sbt-web.jar ...
[info]  [SUCCESSFUL ] com.typesafe.sbt#sbt-web;1.3.0!sbt-web.jar (1010ms)
[info] downloading https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-js-engine/scala_2.10/sbt_0.13/1.1.3/jars/sbt-js-engine.jar ...
[info]  [SUCCESSFUL ] com.typesafe.sbt#sbt-js-engine;1.1.3!sbt-js-engine.jar (1147ms)
[info] downloading https://repo1.maven.org/maven2/com/typesafe/play/twirl-api_2.10/1.1.1/twirl-api_2.10-1.1.1.jar ...
[info]  [SUCCESSFUL ] com.typesafe.play#twirl-api_2.10;1.1.1!twirl-api_2.10.jar (89ms)
[info] downloading https://repo1.maven.org/maven2/commons-io/commons-io/2.4/commons-io-2.4.jar ...
[info]  [SUCCESSFUL ] commons-io#commons-io;2.4!commons-io.jar (48ms)

a **lot** more
[info] Done updating.
[info] Compiling 228 Scala sources and 4 Java sources to /builds/kwiqjobs/backend/target/scala-2.11/classes...
[info] 'compiler-interface' not yet compiled for Scala 2.11.8. Compiling...
[info]   Compilation completed in 17.735 s
[success] Total time: 149 s, completed Jan 20, 2017 2:22:52 PM
Build succeeded

и я хотел бы избавиться от всех скачать.

6
gitlab-ci maven sbt sbt-plugin scala

2 ответов

если вы не хотите использовать пользовательские изображения, лучшим решением является использование GitLab CI кэширование механизм.

Это немного трудно, чтобы получить это право, но этот блог описывает, как это сделать для SBT.

пример .gitlab-ci.yml

цитата из сообщения в блоге, незначительные ошибки исправлены мной:

# some parts originally from https://github.com/randm-ch/units-of-information/blob/master/.gitlab-ci.yml

image: "hseeberger/scala-sbt"

variables:
  SBT_VERSION: "0.13.9"
  SBT_OPTS: "-Dsbt.global.base=sbt-cache/.sbtboot -Dsbt.boot.directory=sbt-cache/.boot -Dsbt.ivy.home=sbt-cache/.ivy"

cache:
  key: "$CI_BUILD_REF_NAME" # contains either the branch or the tag, so it's caching per branch
  untracked: true
  paths:
    - "sbt-cache/.ivy.cache"
    - "sbt-cache/.boot"
    - "sbt-cache/.sbtboot"
    - "sbt-cache/target"

stages:
  - test

test:
  script:
    - sbt test

второй пример, в том числе apt-get кэширование

это то, что я использовал для моего проекта, используется для более общего использования случаев и Docker изображений:

image: java:8

stages:
  - test

variables:
  SBT_VERSION: "0.13.9"
  SBT_OPTS: "-Dsbt.global.base=sbt-cache/.sbtboot -Dsbt.boot.directory=sbt-cache/.boot -Dsbt.ivy.home=sbt-cache/.ivy"
  SBT_CACHE_DIR: "sbt-cache/.ivy/cache"

cache:
  key: "$CI_BUILD_REF_NAME" # contains either the branch or the tag, so it's caching per branch
  untracked: true
  paths:
    - "apt-cache/"
    - "sbt-cache/.ivy/cache"
    - "sbt-cache/.boot"
    - "sbt-cache/.sbtboot"
    - "sbt-cache/target"

before_script:
  - export APT_CACHE_DIR=`pwd`/apt-cache
  - mkdir -pv $APT_CACHE_DIR
  - ls $APT_CACHE_DIR || echo "no apt-cache dir found"
  - apt-get -o dir::cache::archives=$APT_CACHE_DIR update -y
  - apt-get -o dir::cache::archives=$APT_CACHE_DIR install apt-transport-https -y
  # Install SBT
  - mkdir -pv $SBT_CACHE_DIR
  - ls $SBT_CACHE_DIR || echo "no ivy2 cache fir found"
  - echo "deb http://dl.bintray.com/sbt/debian /" | tee -a /etc/apt/sources.list.d/sbt.list
  - apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 642AC823
  - apt-get -o dir::cache::archives=$APT_CACHE_DIR update -y
  - apt-get -o dir::cache::archives=$APT_CACHE_DIR install sbt -y
  - sbt -v sbtVersion

test:
  stage: test
  script:
     - sbt -v sbtVersion
4

есть 4 вещи, которые вы можете сделать:

  1. собственное изображение docker
  2. кэш
  3. артефакты
  4. используйте собственное решение кэширования

лучшим решением будет сочетание их всех.

  1. вы можете создать свой собственный образ докера со всеми зависимостями, которые вам нужны, это самое быстрое решение, так как ему не придется загружать все, но он представит еще одну часть головоломки, о которой вам нужно позаботиться. Вы можете использовать the встроенный репозиторий gitlab для хранения его и GitLab построить его, а затем использовать.
  2. можно использовать кэш в GitLab CI заданий, так что не придется загружать все время. Кэш по умолчанию для sbt кажется~/.ivy2 так добавить
cache:
  paths:
    - ~/.ivy2/

в качестве первых строк в вашем файле gitlab для использования кэшей для каждого этапа.

  1. определите целевой каталог как артефакт чтобы передать его между сборками, и поэтому вам не нужно строить его на каждом этапе.
artifacts:
  paths:
    - target/
  1. вы можете хранить файлы, необходимые для кэширования в вашем собственном s3/minio / nfs, если параметры, поставляемые gitlab, недостаточно. Это будет очень нестандартное решение, поэтому вам придется найти свой собственный путь вокруг него.
2