为 gitlab-ci 缓存虚拟环境答案

【问题标题】：Caching virtual environment for gitlab-ci为 gitlab-ci 缓存虚拟环境
【发布时间】：2018-01-31 10:47:42
【问题描述】：

我使用 Gitlab CI 脚本缓存了 Pip 包，所以这不是问题。

现在我还想捕获一个 Conda 虚拟环境，因为它可以减少设置环境的时间。

我缓存了一个虚拟环境。不幸的是，最后缓存所有 venv 文件需要很长时间。

我尝试只缓存$CI_PROJECT_DIR/myenv/lib/python3.6/site-packages 文件夹，它似乎减少了管道的运行时间。

我的问题是：我做得对吗？

脚本如下：

gitlab-ci.yml

image: continuumio/miniconda3:latest

cache:
  paths:
    - .pip
    - ls -l $CI_PROJECT_DIR/myvenv/lib/python3.6/site-packages
    - $CI_PROJECT_DIR/myvenv/lib/python3.6/site-packages

before_script:
  - chmod +x gitlab-ci.sh
  - ./gitlab-ci.sh

stages:
  - test

test:
  stage: test
  script:
    - python eval.py

gitlab-ci.sh

#!/usr/bin/env bash
ENV_NAME=myenv
ENV_REQUIREMENTS=requirements.txt

if [ ! -d $ENV_NAME ]; then
    echo "Environment $ENV_NAME does not exist. Creating it now!"
    conda create --path --prefix "$CI_PROJECT_DIR/$ENV_NAME"
fi

echo "Activating environment: $CI_PROJECT_DIR/$ENV_NAME"
source activate "$CI_PROJECT_DIR/$ENV_NAME"

echo "Installing PIP"
conda install -y pip

echo "PIP: installing required packages"
echo `which pip`
pip --cache-dir=.pip install -r "$ENV_REQUIREMENTS"

【问题讨论】：

标签： python-3.x caching pip conda gitlab-ci

【解决方案1】：

在构建之间重用 pip 缓存是一个非常好的主意，但对 virtualenvs 这样做是一个非常糟糕的主意。

这是因为 virtualenv 很容易以一种您在运行时无法真正检测到的方式变得混乱。这不仅会发生，而且发生的频率比您想象的要多，因此请避免它。

PS。向那些以艰难的方式了解到这一点的人提供建议。

【讨论】：

您能否详细说明一下它会以何种方式变得混乱？
@sorin - 您可能是正确的，但是gitlab 官方文档与您的回答相矛盾。您的答案需要解释或否决。 docs.gitlab.com/ee/ci/caching/#caching-python-dependencies

【解决方案2】：

我们成功地使用了文档https://docs.gitlab.com/ee/ci/caching/#caching-python-dependencies中列出的方法

# Change pip's cache directory to be inside the project directory since we can
# only cache local items.
variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"

# Pip's cache doesn't store the python packages
# https://pip.pypa.io/en/stable/reference/pip_install/#caching
#
# If you want to also cache the installed packages, you have to install
# them in a virtualenv and cache it as well.
cache:
  paths:
    - .cache/pip
    - venv/

可能还缺少其他东西，但您的第一遍可能会错过：

当减小整个.../venv/ 目录树的大小时，您可能需要.../venv/bin，因为这是找到正确的python 版本所必需的；在activate使用venv 命令which -a python3 之后在本地查看此内容
如果 pip 将再次被使用（例如稍后在您的构建中通过一些 make 配方），您需要移动 pip 缓存，如上所示。

【讨论】：

【解决方案3】：

我没有足够的代表来评论@sorin 的回答，但是我们现在在使用当前的 GitLab (14.6) 时遇到了同样的问题。

我们有四个作业，都使用相同的基础 Docker 映像。一方面，我们建立一个virtualenv，然后缓存它；其他 3 个作业拉缓存，激活 venv，然后尝试使用它。这 3 个作业经常失败，因为它们无法找到正确的 python 或从激活的 venv 加载特定模块。

virtualenv 的问题在于（至少从 Python 3.3 中的 venv 模块开始）virtualenvs 不可重定位。 activate 脚本在 VIRTUAL_ENV 变量中包含指向 virtualenv 的绝对路径。 GitLab 跑步者默认包含唯一跑步者令牌作为build directory 的一部分，然后成为VIRTUAL_ENV 变量的一部分。因此，如果您将 virtualenv 缓存在一个运行器上，然后尝试在另一个运行器上使用它，它将失败，因为路径不匹配。 activate 甚至不会警告您 VIRTUAL_ENV 路径不存在。

如果你有一个 GitLab 跑步者，你可能没问题。如果没有，您可以编写脚本来自己更新 virtualenv，这可能会或可能不会正常工作（请参阅Can I move a virtualenv?）。或者做安全的事情并在每项工作中重新创建venv；你可以至少缓存 pip 缓存。

【讨论】：