GitLab CI 在构建阶段之间保留环境

Question

我正在开发一个 python 项目并使用 miniconda管理我的环境。我正在使用 GitLab for CI 和以下运行器配置

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 阶段。正在查看this question和 this GitLab issue我看到了

each job defined in .gitlab-ci.yml is run as separate build (where we assume that there's no history)

但是将所有内容集中在一个阶段的替代方案并不吸引人

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 中阶段，但在每个阶段之前不断地重新创建相同的环境似乎是多余的。

Answer 1

作业的独立性是一个设计特征。您可能已经注意到，GitLab 的界面允许您重新运行单个作业，如果作业相互依赖，则这是不可能的。

我不知道Miniconda到底执行什么，但如果它在特定文件夹中构建虚拟环境，您可以使用 cache 在作业之间保留这些文件夹的内容。但是，您不能完全依赖它，因为文档指出...

The cache is provided on a best-effort basis, so don't expect that the cache will be always present. For implementation details, please check GitLab Runner.

考虑到您的工作绝对取决于正在构建的环境，您需要一种机制来检测(缓存的)环境是否存在，并仅在需要时重新创建它。

我认为您正在尝试将环境设置和作业分开，因为如果您决定有一天同时运行不同的测试，这可能会节省大量时间。 >(同一阶段的作业并行运行)。