13

ファイルには、実際のスクリプトが実行される前にコマンドを実行するgitlab-ciオプションがあり、. ここでは、補助プログラムのインストール例を示します。ただし、docker executor を使用すると、これらの変更が Docker にキャッシュされないことに気付きました。これらのコマンドを実行した後、docker はイメージをキャッシュするので、次の実行またはテストでは、docker は. これにより、ビルドが大幅に高速化されます。.gitlab-ci.ymlbefore_script.gitlab-ci.ymlbefore_script

例として、私の.gitlab-ci.yml見た目は次のようになります。

image: ubuntu

before_script:
    - apt-get update -qq && apt-get install -yqq make ...

build:
    script:
        - cd project && make

考えられる解決策は、ランナー マシンに移動し、他のインストールなしでソフトウェアをビルドできる Docker イメージを作成しimage、yaml ファイルのセクションでそれを参照することです。これの欠点は、依存関係を追加するたびに、ビルドが成功する前にランナー マシンにログインしてイメージを更新する必要があることです。の最後に依存関係を追加し、apt-get installdocker / gitlab-ci に適切なキャッシュを処理させるだけでよければ、はるかに良いでしょう。

に設定しようとした にもcacheコマンドがあります。これは、プロジェクトの副産物ではないすべてのものをキャッシュすると思っていましたが、何の効果もないようでした。.gitlab-ci.ymluntracked: true

私が望む動作を取得する方法はありますか?

4

2 に答える 2

2

これを処理する方法は、Docker Hub にプロジェクトごとにカスタム イメージを用意し、それらを から参照することです.gitlab-ci.yml。新しい依存関係が必要な場合は、初期イメージの作成に使用した Dockerfile を編集し、イメージを再構築して、特定のタグを使用してタグ付けし、Docker Hub にプッシュします。

cat "RUN apt-get install gcc" >> Dockerfile
ID=$(docker build)
docker tag $ID ACCOUNT/gitlab_ci_image:gcc
docker push ACCOUNT/gitlab_ci_image

.gitlab-ci.yml次に、その特定のバージョンのイメージを指すようにファイルを更新します。

image: ACCOUNT/gitlab_ci_image:gcc

build:
    script:
        - cd project && make

これにより、テストしようとしているコミットに応じて異なる依存関係を持つことができます (gitlab-ci.ymlそのコミット内のファイルがランナーにどちらを使用するかを指示するため)。また、ランナーは変更されない限り同じイメージを再利用するため、特定のランナーでテストが実行されるたびに依存関係をインストールする必要がなくなります。

もう 1 つの優れた点は、Docker Hub でホストされているイメージを使用すると、ランナーがローカルにはない特定のタグを必要とする場合、正しいタグが自動的に取得されるため、10 個のランナーを使用して 1 つのイメージのみを維持できることです。このメンテナンスは、自分のワークステーションまたは任意のマシンで実行できます。

個人的には、これはランナーの画像内に何かをキャッシュしようとするよりもはるかに優れたソリューションだと思います。これは、依存関係の新しいバージョンでコードをテストするために新しいブランチを作成する場合に特に当てはまります。キャッシングがあれば、安定ブランチと開発ブランチのテスト環境が異なるという問題が発生します。また、私の意見では、テストはできるだけクリーンな環境で実行する必要があり、このセットアップはそれを実現します。

于 2016-01-15T22:19:00.253 に答える