31

gitlab-ci-multi-runner 0.6.0でGitlab CI 8.0 を使用しています。次のようなファイルがあります。.gitlab-ci.yml

before_script:
  - npm install

server_tests:
  script: mocha

client_tests:
  script: karma start karma.conf.js

これは機能しますが、各テスト ジョブの前に依存関係が個別にインストールされることを意味します。多くの依存関係を持つ大規模なプロジェクトの場合、これによりかなりのオーバーヘッドが追加されます。

Jenkins では、1 つのジョブを使用して依存関係をインストールし、TAR を実行してビルド アーティファクトを作成し、それをダウンストリーム ジョブにコピーします。Gitlab CI でも同様のことができますか? 推奨されるアプローチはありますか？

4

7 に答える 7

17

更新artifacts:ショート での使用をお勧めしexpire_inます。cacheこれは、ジョブごとにキャッシュが更新されるのに対し、パイプラインごとに 1 回だけアーティファクトを書き込む必要があるため、優れています。また、キャッシュはランナーごとであるため、ジョブを複数のランナーで並行して実行すると、集中的に保存されるアーティファクトとは異なり、データが読み込まれることが保証されません。

Gitlab CI 8.2 では、ビルド間でファイルを再利用できるランナー キャッシュが追加されています。ただし、これは非常に遅いことがわかりました。

代わりに、ちょっとしたシェル スクリプトを使用して独自のキャッシュ システムを実装しました。

before_script:
  # unique hash of required dependencies
  - PACKAGE_HASH=($(md5sum package.json))
  # path to cache file
  - DEPS_CACHE=/tmp/dependencies_${PACKAGE_HASH}.tar.gz
  # Check if cache file exists and if not, create it
  - if [ -f $DEPS_CACHE ];
    then
      tar zxf $DEPS_CACHE;
    else
      npm install --quiet;
      tar zcf - ./node_modules > $DEPS_CACHE;
    fi

これは、すべてのジョブの前に実行され、依存関係が変更された場合、またはキャッシュ ファイルが見つからない場合 (たとえば、最初の実行、またはファイルが手動で削除された場合) に.gitlab-ci.ymlのみ依存関係がインストールされます。package.json異なるサーバーに複数のランナーがある場合、それぞれに独自のキャッシュ ファイルがあることに注意してください。

最新の依存関係を取得するために、キャッシュ ファイルを定期的にクリアすることをお勧めします。これは、次の cron エントリで行います。

@daily               find /tmp/dependencies_* -mtime +1 -type f -delete
于 2015-12-03T17:33:45.653 に答える
7

ドキュメントから：

  • cache:プロジェクトの依存関係を一時的に保存するために使用します。jarやapkファイルなどの中間ビルド結果を保持するのには役立ちません。キャッシュは、依存関係など (npm パッケージ、Go ベンダー パッケージなど) を保持することで、特定のジョブの後続の実行の呼び出しを高速化するために使用されるように設計されているため、パブリックから再フェッチする必要はありません。インターネット。ステージ間でビルドの中間結果を渡すためにキャッシュが悪用される可能性がありますが、アーティファクトの方が適している場合もあります。

  • artifacts:ステージ間で渡されるステージ結果に使用します。アーティファクトは、ビルドのコンパイル/生成されたビットをアップロードするように設計されており、任意の数の同時実行ランナーがフェッチできます。それらは利用可能であることが保証されており、ジョブ間でデータを渡すために存在します。また、UI からダウンロードできるように公開されています。アーティファクトは、ビルド ディレクトリに関連するディレクトリにのみ存在でき、このルールに準拠しないパスを指定すると、直感的でない非論理的なエラー メッセージが表示されます (拡張については、https://gitlab.com/gitlab-org/gitlab-ceで説明されています)。 /issues/15530）。次のステージのジョブを開始する前に、アーティファクトを (GitLab ランナーだけでなく) GitLab インスタンスにアップロードする必要があるため、時間をかける前に、帯域幅がステージと共有アーティファクトの並列化から利益を得ることができるかどうかを慎重に評価する必要があります。セットアップの変更で。

だから、私は使用しますcache。キャッシュを更新する必要がない場合 (例: テスト ジョブのビルド フォルダー) を使用しますpolicy: pull(こちらを参照)。

于 2019-06-21T16:03:25.430 に答える
1

同じステージのすべてのジョブが並行して実行される可能性があるため、お勧めしません。

  1. まず、ビルドのすべてのジョブが並行して実行されます。
  2. ビルドのすべてのジョブが成功すると、テスト ジョブが並行して実行されます。
  3. テストのすべてのジョブが成功すると、デプロイ ジョブが並行して実行されます。
  4. デプロイのすべてのジョブが成功すると、コミットは成功としてマークされます。
  5. 以前のジョブのいずれかが失敗した場合、コミットは失敗としてマークされ、それ以降のステージのジョブは実行されません。

私はここでそれを読んだ：

http://doc.gitlab.com/ci/yaml/README.html

于 2015-11-04T16:10:19.770 に答える
0

GitLab は、ジョブごとに依存関係を再ダウンロードすることを避けるためにキャッシュを導入しました。

次の Node.js の例は、キャッシングのドキュメントから着想を得ています。

image: node:latest

# Cache modules in between jobs
cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .npm/

before_script:
  - npm ci --cache .npm --prefer-offline

server_tests:
  script: mocha

client_tests:
  script: karma start karma.conf.js

この例では を使用していることに注意してくださいnpm ci。このコマンドは に似npm installていますが、自動化された環境で使用するように設計されています。詳細についてnpm ciは、ドキュメントと渡すことができるコマンド ライン引数を参照してください。

詳細については、GitLab CI/CDでのキャッシングおよびcache キーワード リファレンスを確認してください。

于 2021-12-20T13:15:39.817 に答える