GitLab CI сохраняет среду между этапами сборки

Я работаю над проектом python и использую miniconda для управления своей средой. Я использую GitLab для 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 этап. Глядя на этот вопрос и эта проблема GitLab Я вижу, что

каждое задание, определенное в .gitlab-ci.yml, запускается как отдельная сборка (где мы предполагаем, что истории нет)

Но альтернатива объединить все вместе на одном этапе не очень привлекательна.

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, но кажется излишним постоянно воссоздавать одну и ту же среду перед каждым этапом.


gitlab gitlab-ci gitlab-ci-runner
person Philip O'Brien    schedule 10.08.2016    source источник

Ответы (3)


arrow_upward
11
arrow_downward

Независимость рабочих мест - это особенность дизайна. Вы могли заметить, что интерфейс GitLab позволяет повторно запустить одно задание, что было бы невозможно, если бы задания зависели друг от друга.

Я не знаю, что именно выполняет Miniconda, но если он создает виртуальную среду в определенных папках, вы можете использовать cache, чтобы сохранить содержимое этих папок между заданиями. Однако вы не можете полностью полагаться на него, потому что в документации указано, что ...

Кэш предоставляется по принципу «максимальных усилий», поэтому не ожидайте, что кеш будет всегда. Подробнее о реализации см. В GitLab Runner.

Учитывая, что ваша работа полностью зависит от создаваемой среды, вам понадобится механизм, чтобы определить, существует ли (кешированная) среда, и воссоздать ее только в случае необходимости.

Я думаю, вы идете по правильному пути, пытаясь разделить настройку среды и задания, потому что это может сэкономить много времени, если вы однажды решите запустить разные тесты одновременно (задания на этом же этапе запустить параллельно).

person tmt    schedule 10.08.2016
comment
Обратите внимание, что указанное выше предупреждение отсутствует в обновленной документации Gitlab. - person Dark_eye; 28.12.2020

arrow_upward
7
arrow_downward

Вы можете использовать артефакты для передачи файлов между этапами сборки.

Однако, если общие части относятся к среде (т.е. это не код, который вы написали), вам, вероятно, следует использовать кеш.

person Matthew    schedule 19.08.2016

arrow_upward
3
arrow_downward

Вы можете поместить свои общие команды в 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 >>
person GMishx    schedule 05.12.2018