Python CI/CD 管道的故障恢复

ci/cd流水线pip install失败主因是网络不稳、默认pypi源不可靠及缓存缺失；应指定国内镜像源、加–no-cache-dir、锁requirements.txt版本。

CI/CD 流水线卡在 pip install 阶段失败怎么办

常见现象是流水线日志里反复出现 ConnectionError、ReadTimeout 或 Could not find a version that satisfies...，尤其在 gitHub Actions、gitlab CI 这类共享构建环境中。根本原因不是代码问题，而是网络不稳定 + 默认 PyPI 源不可靠 + 缓存缺失三重叠加。

实操建议：

立即学习“Python免费学习笔记（深入）”；

• 强制指定国内镜像源：在 pip install 命令后加 --index-url https://pypi.tuna.tsinghua.edu.cn/simple/，比改 pip.conf 更直接可控
• 加 --no-cache-dir 反而更稳——CI 环境里旧缓存常损坏，跳过它能避免“明明装过却报找不到包”的诡异错误
• 如果用 requirements.txt，别只写包名，显式锁版本（如 requests==2.31.0），否则某天上游包更新引入不兼容，故障就悄无声息地来了

github Actions 中 setup-python 版本不匹配导致测试失败

典型表现是本地跑通的单元测试，在 CI 里报 ModuleNotFoundError 或语法错误（比如用了 match/case 却配了 Python 3.8）。这不是代码问题，是 uses: actions/setup-python@v4 的 python-version 和项目实际依赖不一致。

实操建议：

立即学习“Python免费学习笔记（深入）”；

• 检查项目根目录是否有 pyproject.toml 或 runtime.txt，优先按它们声明的版本设 python-version，而不是凭经验填 3.x
• 避免用 3.x 这类模糊写法——actions/setup-python 对 x 的解析逻辑会随插件版本变，某次更新后可能从选 3.11 变成选 3.12，引发意外兼容问题
• 在 workflow 文件里加一步验证：python -c "import sys; print(sys.version)"，确保实际运行版本和预期一致

pytest 在 CI 中跳过部分测试但本地全过

最常踩的坑是测试里用了 os.getenv() 或 pathlib.Path().exists() 读取本地路径或环境变量，而 CI 环境默认没这些值，导致测试被静默跳过（pytest 遇到 SkipTest 不报错也不标红）。

实操建议：

立即学习“Python免费学习笔记（深入）”；

• 把所有 pytest.skipif 条件拆出来单独打印，比如在跳过前加 print(f"Skipping because {condition} is {value}")，CI 日志里一眼看出为什么跳
• 禁用隐式跳过：在 pytest 命令里加 --strict-markers --strict-config，让未注册的标记或配置直接报错，而不是吞掉
• 对路径相关测试，统一用 tmp_path fixture 创建临时目录，别碰绝对路径——CI 构建机的文件系统结构和你本地完全不同

流水线里 docker build 层缓存失效太频繁

Python 项目 Docker 化时，经常发现每次 CI 都从 RUN pip install 开始重跑，镜像体积暴涨、构建时间翻倍。核心矛盾是：requirements.txt 文件内容没变，但它的修改时间变了（Git 检出机制导致），Docker 认为这一层必须重建。

实操建议：

立即学习“Python免费学习笔记（深入）”；

• 在 Dockerfile 里把 copy requirements.txt . 放在 COPY . . 之前，并且用 COPY --chown=nonroot:nonroot requirements.txt . 显式控制时间戳
• 改用多阶段构建，把 pip install 放进 builder 阶段，再用 COPY --from=builder 复制已安装的包，彻底绕过缓存判断逻辑
• CI 脚本里加校验：sha256sum requirements.txt 打印哈希值，确认每次触发是否真有依赖变更——很多所谓“缓存失效”其实是误触发

真正难处理的是跨平台环境差异：Mac 上跑通的 CI 配置，到了 linux runner 上因为 glibc 版本或 openssl 库路径不同，pip install 可能静默降级编译方式，最后跑测试才暴露 C 扩展崩溃。这类问题不会出现在日志开头，得盯着最后一行 core dump 或 segmentation fault 才能找到线索。