Gitlabドッカーエグゼキュータ - before_scriptの後にイメージをキャッシュ

Question

には、before_scriptと呼ばれる実際のスクリプトが実行される前にコマンドを実行するオプションが.gitlab-ci.ymlにあります。 .gitlab-ci.ymlの例では、補助プログラムのインストールを示しています。しかし、私が気づいたのは、ドッカーエグゼキュータを使用しているときに、これらの変更がDockerにキャッシュされていないことです。これらのコマンドを実行した後、ドッカーがイメージをキャッシュすると仮定していたので、次の実行またはテストでは、ドッカーはbefore_scriptの後に生成されたキャッシュされたイメージをロードします。これはビルドを大幅に高速化します。

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

image: ubuntu 

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

build: 
    script: 
     - cd project && make 

可能な解決策は、ランナーのマシンに移動し、他のインストールせずに、私のソフトウェアを構築し、それを参照することができるドッキングウィンドウの画像を作成することですyamlファイルのimageセクションにあります。これの欠点は、依存関係を追加するときはいつでも、ビルダーが成功する前にランナーマシンにログインしてイメージを更新する必要があることです。 apt-get installの末尾に依存関係を追加し、docker/gitlab-ciが適切なキャッシュを処理しなければならない場合は、はるかに良いでしょう。

私は私のプロジェクトの副産物ではなかったのすべてをキャッシュするだろうが、どんな効果があるようには見えなかったと思った私はuntracked: trueに設定しようとした.gitlab-ci.ymlでcacheコマンドは、もあります。

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

Answer 1

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

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ファイルとして）をテストしようとしていますコミットするかによって異なる依存関係を持つことができます。また、依存関係にランナーがいる限り、それは変更されないのと同じ画像を再利用するようなテストは、特定のランナー上で実行されるたびにインストールする必要がなくなります。

Docker Hubでホストされている画像では、ランナーがローカルにない特定のタグを必要とする場合は、正しいものを自動的に取得して10人のランナーと単一のイメージを維持してください。このメンテナンスは、お客様のワークステーションまたは任意のマシンで行うことができます。

個人的には、これはランナーの画像内に何かをキャッシュしようとするよりはるかに良い解決策だと思います。これは、依存関係の新しいバージョンでコードをテストするために新しいブランチを作成するときに特に当てはまります。キャッシングをしていれば、安定したデベロッパーブランチのためのテスト環境が異なることがあります。私の意見では、テストは可能な限りクリーンな環境で実行されなければならず、この設定はこれを実現します。

Answer 2

ステージを追加して、最初に画像を構築できます。画像に変化がない場合、ステージは1秒以下で非常に短くなります。

あなたは全体のプロセスをスピードアップするには、次の段階でそのイメージを使用することができます。

これは.gitlab-ci.ymlの例である：

stages: 
    - build_test_image 
    - test 

build_test: 
    stage: build_test_image 
    script: 
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY 
    - docker build -t $CI_REGISTRY_IMAGE:test -f dockerfiles/test/Dockerfile . 
    - docker push $CI_REGISTRY_IMAGE:test 
    tags: 
    - docker_build 

test_syntax: 
    image: $CI_REGISTRY_IMAGE:test 
    stage: test 
    script: 
    - pip install flake8 
    - flake8 --ignore=E501,E265 app/ 

は、タグdocker_buildを見てください。このタグは、そのタグを持つランナーのステージの実行を強制するために使用されます。その実行者のエグゼキュータはshellで、Dockerイメージを構築するためにのみ使用されます。だから、ランナーが住んでいるホストはDocker Engineをインストールしているはずです。私はこの解決策がドッカーのドッカーよりも私のニーズに合っており、another solutionsであることを発見しました。

また、私は$CI_REGISTRY*変数を使用していますが、プライベートレジストリを使用していますが、レジストリを指定しなくてもDockerHubを使用できます。しかし問題は、DockerHubで認証することです。