Как рассказать Дженкинсу об использовании конкретного виртуального питона

Я уже создал virtualenv для запуска моего python script.

Теперь, когда я интегрирую этот скрипт python с Jenkins, я обнаружил, что в данный момент Jenkins использует неправильную среду python.

Как я могу гарантировать, что Дженкинс использует правильный virtualenv?

В качестве примера, для моего случая я хочу использовать virtualenv test. Как я могу использовать этот предварительно подготовленный virtualenv для запуска моего python script.

source test/bin/activate

Ответ 1

Вы должны установить один из плагинов python. Я использовал ShiningPanda. Затем вы сможете создавать отдельные конфигурации виртуальной среды в разделе "Управление установками Jenkins > Настройка системы > Python > Python". В конфигурации задания будет шаг Python Builder, где вы можете выбрать среду python.

Просто убедитесь, что вы не запускаете сервис Jenkins из существующей виртуальной среды python.

Ответ 2

Во-первых, вам следует избегать использования ShiningPanda, потому что он сломан. Он будет сбой, если вы попытаетесь параллельно выполнять задания и также несовместимы с конвейерами Jenkins2.

Когда сборки выполняются параллельно (параллельно), Jenkins добавит @2, @3... в каталог рабочей области, так что два исполнения не будут использовать одну и ту же папку. Дженкинс делает клонирование исходного рабочего пространства, поэтому не удивляйтесь, если он будет содержать virtualenv, который вы создали в предыдущей сборке.

Вам нужно самостоятельно позаботиться о создании virtualenv, но вы должны быть очень осторожны в том, как вы его используете:

папка рабочих пространств может не очищаться, и ее местоположение может меняться от одной сборки к другой.
virtualenvs знает, что их сломают, когда они перемещаются, а дженкинс перемещает их.
создание файлов за пределами рабочего пространства - это действительно плохая практика CI, избегайте соблазна использовать /tmp

Таким образом, ваш единственный безопасный вариант - создать уникальную папку виртуальной среды для каждой сборки внутри рабочей области. Вы можете легко сделать это, используя переменную среды $JOB_NUMBER.

Это будет отличаться, даже если у вас есть задания, выполняемые параллельно. Также это не повторится.

Downsides:

скорость: virtualenvs не используются повторно между сборками, поэтому они полностью воссозданы. Если вы используете --site-packages, вы можете значительно ускорить создание (если тяжелые пакеты уже установлены в системе)
space: если рабочее пространство не очищается регулярно, количество виртуальных серверов будет расти. Обход проблемы: работа, которая очищает рабочие пространства каждую неделю или каждые две недели. Это также хорошая практика для выявления других ошибок. Некоторые люди выбирают очистку рабочего пространства для каждого выполнения.

Отрывок оболочки

      #/bin/bash
      set -euox pipefail

      # Get an unique venv folder to using *inside* workspace
      VENV=".venv-$BUILD_NUMBER"

      # Initialize new venv
      virtualenv "$VENV"

      # Update pip
      PS1="${PS1:-}" source "$VENV/bin/activate"

      # <YOUR CODE HERE>

В первой строке используется bash строковый режим, подробнее в http://redsymbol.net/articles/unofficial-bash-strict-mode/

Ответ 3

Вы можете использовать Pyenv Pipeline Plugin. Использование очень просто, просто добавьте


stage('my_stage'){
    steps{
        script{
            withPythonEnv('path_to_venv/bin'){
                sh("python foo.py")                              
                ...

Вы можете добавить pip install whatever в свои действия для обновления любой виртуальной среды, которую вы используете.

По умолчанию он будет искать виртуальную среду в рабочем пространстве jenkins, а если он не найдет ее, он создаст новую.