GitLab CIはビルドステージ間の環境を維持します

Question

私はPythonプロジェクトに取り組んでおり、minicondaを使って自分の環境を管理しています。私は私のbuildステージはセットアップ私はtest段階を実行することがあった正しい環境をだろうと私は（間違って）想定し、次のランナー構成

stages: 
    - build 
    - test 

build: 
    stage: build 
    script: 
    - if hash $HOME/miniconda/bin/conda 2>/dev/null; 
     then 
     export PATH="$HOME/miniconda/bin:$PATH"; 
     else 
     wget http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh -O miniconda.sh; 
     bash miniconda.sh -b -p $HOME/miniconda; 
     export PATH="$HOME/miniconda/bin:$PATH"; 
     fi 
    - conda update --yes conda 

test: 
    stage: test 
    script: 
    - conda env create --quiet --force --file environment.yml 
    - source activate myenv 
    - nosetests --with-coverage --cover-erase --cover-package=mypackage --cover-html 
    - pylint --reports=n tests/test_final.py 
    - pep8 tests/test_final.py 
    - grep pc_cov cover/index.html | egrep -o "[0-9]+\%" | awk '{ print "covered " $1;}' 

とCIのためにGitLabを使用しています。 this questionとthis GitLab issueを見て私は

.gitlab-ci.ymlで定義された各ジョブは別々の（私たちは何の歴史がありませんと仮定し ）ビルド

しかし塊の代替として実行されていることがわかり1つの段階で一緒にすべてが私は考えることができる唯一の他のオプションはbefore_script段階で環境の作成手順を置くことです

stages: 
    - test 

test: 
    stage: test 
    script: 
    - if hash $HOME/miniconda/bin/conda 2>/dev/null; 
     then 
     export PATH="$HOME/miniconda/bin:$PATH"; 
     else 
     wget http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh -O miniconda.sh; 
     bash miniconda.sh -b -p $HOME/miniconda; 
     export PATH="$HOME/miniconda/bin:$PATH"; 
     fi 
    - conda update --yes conda 
    - conda env create --quiet --force --file environment.yml 
    - source activate myenv 
    - nosetests --with-coverage --cover-erase --cover-package=mypackage --cover-html 
    - pylint --reports=n tests/test_final.py 
    - pep8 tests/test_final.py 
    - grep pc_cov cover/index.html | egrep -o "[0-9]+\%" | awk '{ print "covered " $1;}' 

をアピールされていない、BU各段階の前に同じ環境を継続的に再現することは冗長であるようです。

Answer 1

ジョブの独立は設計上の特徴です。 GitLabのインターフェースでは、ジョブがお互いに依存している場合には不可能であった単一のジョブを再実行することができます。

Minicondaが正確に実行するものはわかりませんが、特定のフォルダに仮想環境を構築する場合は、cacheを使用してジョブ間のフォルダの内容を保持できます。

キャッシュはベストエフォートベースで提供されているので、期待しないでください...ドキュメントの状態が キャッシュが常に存在することをしかし、あなたは完全にそれに頼ることはできません。実装の詳細については、 GitLab Runnerを確認してください。

あなたの仕事は構築されている環境によって決まることを考慮すると、（キャッシュされた）環境が存在するかどうかを検出し、必要な場合にのみ再作成するメカニズムが必要です。

は、私はあなたがそれはあなたが同じステージ実行中で1日に実行異なるテスト同時に（ジョブを決める場合には多くの時間を節約する可能性があるため、環境設定やジョブを分離しようとして良いパスを取っていると思います平行）。

Answer 2

​​を使用すると、ビルドステージ間でファイルを渡すことができます。

共有部分が環境のもの（つまり、あなたが書いたコードではない）の場合、おそらくキャッシュを使うべきです。