web-dev-qa-db-ja.com

gitlab ciが毎回sbtをダウンロードしないようにする方法は？

Gitlabciで構築しているplay2/scalaアプリケーションがあります。

.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はグローバルに利用可能になり、必要はないはずです。ダウンロードします。

次に、 this gitlabからのソリューションは必要ありません。

とにかく、サーバーがsbtコマンドを実行するたびに、各展開中にsbtが完全に6回ダウンロードされないことを嬉しく思います。

誰かが正しいimageまたはimageを正しい方法で使用する方法、またはsbtのものをキャッシュする方法を説明できますか？

更新

過去数日間、私はdockerとgitlab ciとたくさん戦いました。この問題は、 インターネットをダウンロードしないでください で説明されているものとほとんど同じであることがわかりました。これはすべての依存関係を持つのは難しい作業のようであり、それらをマウントすることによって行うのが最善です。残念ながら、共有gitlabciランナーではそれ自体は不可能です。

続けて、 sbt-docker を発見しました。これにより、build.sbtファイルからDockerコンテナーを構築できます。 パッケージの基本的なアプローチ を使用して、プロジェクトでローカルに使用可能なすべての依存関係を グローバルsbtプラグイン としてコンテナーに含めようとしました。しかし、これも役に立ちませんでした。

私の最後の発見は maven solution に関するこの答えであり、それを私たちのsbtプロジェクトに変換しようとしました。

.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

そして、私はすべてのダウンロードを取り除きたいと思います。

scalamavensbtgitlab-cisbt-plugin
12
stubbi

カスタムメイドの画像を使用したくない場合、最善の解決策は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キャッシングも含む2番目の例

これは私がプロジェクトに使用したものであり、より一般的なユースケースと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
9
pederpansen

あなたができる4つのことがあります：

  1. 独自のDockerイメージ
  2. キャッシュ
  3. アーティファクト
  4. 独自のキャッシュソリューションを使用する

最善の解決策は、それらすべてを組み合わせることです。

  1. 必要なすべての依存関係を使用して独自のDockerイメージを構築できます。すべてをダウンロードする必要がないため、最速のソリューションですが、処理する必要のあるパズルの別のピースが導入されます。 組み込みのgitlabリポジトリ を使用して保存し、gitlabにビルドさせてから 使用 にすることができます。
  2. Gitlab CIジョブで cache を使用できるため、常にすべてをダウンロードする必要はありません。 sbtのデフォルトのキャッシュは〜/ .ivy2のようですので、追加します
cache:
  paths:
    - ~/.ivy2/

Gitlabファイルの最初の行として、各ステージのキャッシュを使用します。

  1. ターゲットディレクトリを artifact として定義して、ビルド間で渡すため、各ステージでビルドする必要はありません。
artifacts:
  paths:
    - target/
  1. Gitlabが提供するオプションでは不十分な場合は、キャッシュする必要のあるファイルを独自のs3/minio/nfsに保存できます。これは非常にカスタムなソリューションになるため、独自の方法を見つける必要があります。
2
Jakub Kania