web-dev-qa-db-ja.com

GitLabCIはビルドステージ間で環境を保護します

pythonプロジェクトに取り組んでおり、 miniconda を使用して環境を管理しています。次のランナー構成でGitLab forCIを使用しています

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;}'

buildステージが、testステージを実行できる正しい環境をセットアップすると（誤って）想定しました。 この質問 と このGitLabの問題 を見ると

.gitlab-ci.ymlで定義された各ジョブは、個別のビルドとして実行されます（履歴がないと想定しています）

しかし、すべてを1つの段階にまとめるという選択肢は魅力的ではありません

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;}'

私が考えることができる他の唯一のオプションは、環境作成ステップを before_script ステージに置くことですが、各ステージの前に同じ環境を継続的に再作成することは冗長に思えます。

gitlabgitlab-cigitlab-ci-runner
9
Philip O'Brien

ジョブの独立性は設計機能です。 GitLabのインターフェースを使用すると、ジョブが相互に依存している場合には不可能な単一のジョブを再実行できることに気付いたかもしれません。

Minicondaが正確に何を実行するかはわかりませんが、特定のフォルダーに仮想環境を構築する場合は、cacheを使用できます。ジョブ間でこれらのフォルダーの内容を保持します。ただし、ドキュメントには次のように記載されているため、完全に信頼することはできません...

キャッシュはベストエフォートベースで提供されるため、キャッシュが常に存在することを期待しないでください。実装の詳細については、GitLabRunnerを確認してください。

ジョブは構築中の環境に完全に依存することを考えると、（キャッシュされた）環境が存在するかどうかを検出し、必要な場合にのみ再作成するメカニズムが必要になります。

ある日runを実行することにした場合、多くの時間を節約できる可能性があるため、環境設定とジョブを分離しようとしているのは良い道だと思いますテスト同時に（同じステージのジョブは並行して実行されます）。

10
tmt

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

ただし、共有部分が環境関連のものである場合（つまり、作成したコードではない場合）、おそらくキャッシュを使用する必要があります。

6
Matthew

一般的なコマンドは before_script の下に置くことができます。これは、すべての子ステージに適用されます。このように、コードを繰り返す必要はありません。

次のようなものを使用できます。

stages:
  - build
  - test
  - deploy 

before_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

build:
  stage: build
  script:
    - << Your build script >>

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;}'

deploy:
  stage: deploy
  before_script:
    - << Override to global before_script >>
    - << DO something else >>
2
GMishx