python-3.x - Azure 管道找不到用户创建的 python 模块

Question

我正在尝试使用 Azure DevOps 从 python 模块运行测试。我有一个管道build设置来构建一个 yml 文件并使用经典编辑器。我收到一个错误，我的导入模块名称不正确。当我在本地运行它时，它工作得很好。

我的 Repo 结构:

我正在使用此命令作为批处理文件运行我的测试:

cd 测试用例

pytest -v test_msoffice.py

并给我错误:

______________________ ERROR collecting test_msoffice.py ______________________
ImportError while importing test module 'D:\a\1\s\testcases\test_msoffice.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
test_msoffice.py:7: in <module>
    from util import utility_method_class
E   ModuleNotFoundError: No module named util

有人请帮助我。

Answer 1

我在过去两天遇到了同样的症状。我假设您的包在本地位于一个名为 "util" 的目录中，带有(或根据您的评论没有)__init__.py文件。这导致 python 将该目录下的所有模块识别为属于 utils 包。 (从 Python 3 开始，python 将在没有 __init__.py 的情况下管理对本地目录结构的“命名空间引用”)在 Pipeline 代理上，代码直接复制到 D:\a\1\s\- 因此 python 将认为该包被称为 "s"

我找到了以下解决方法:在管道中包含一个脚本，用于将源代码移动到一个新的适当命名的目录中，然后在那里进行测试。

我的管道 YAML 看起来像这样。它基于这样的假设，即您的 ADO 项目的名称与您的包的名称相同 - 因此在您的情况下，“util” 是为 ubuntu/bash 设置的。如果您必须在 Windows 代理上进行测试，那么脚本将需要移植，或者您可以切换到 ubuntu 代理并复制整个内容。

# Python package
# Create and test a Python package on multiple Python versions.
# Add steps that analyze code, save the dist with the build record, publish to a PyPI-compatible index, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/python

trigger:
- azure-pipelines
- master
- pipeline/*

variables:
  PythonPackagePath: ORIGINALVALUE

pool:
  vmImage: ubuntu-latest
strategy:
  matrix:
    # Python27:
    #   python.version: '2.7'
    # Python35:
    #  python.version: '3.5'
    # Python36:
    #   python.version: '3.6'
    # Python37:
    #   python.version: '3.7'
    Python310:
      python.version: '3.10'

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '$(python.version)'
  displayName: 'Use Python $(python.version)'

- script: |
    cd $(System.DefaultWorkingDirectory)
    export ParentDir=${PWD%/*}

    echo Setting PythonPackagePath to $ParentDir/$(System.TeamProject)
    echo "##vso[task.setvariable variable=PythonPackagePath;]$ParentDir/$(System.TeamProject)"

  displayName: 'Set Package Path'

- script: |
    echo PythonPackagePath is $(PythonPackagePath)
    
    echo Moving files from $(System.DefaultWorkingDirectory) to $(PythonPackagePath)
    mv $(System.DefaultWorkingDirectory) $(PythonPackagePath)

    echo SymLinking old Working Directory back in case needed
    ln -s $(PythonPackagePath) $(System.DefaultWorkingDirectory)
    ls -l $(System.DefaultWorkingDirectory)/..
  displayName: 'Move Working Directory'

- script: |
    python -m pip install --upgrade pip
    pip install -r requirements.txt
  displayName: 'Install dependencies'
  # continueOnError: true

- script: |
    export PYTHONPATH=$(PythonPackagePath)
    echo PYTHONPATH is set to $PYTHONPATH

    cd $(PythonPackagePath)
    echo Working in:
    pwd

    pip install pytest pytest-azurepipelines
    pip install pytest-cov
    pytest --cov=. --cov-report=xml
  displayName: 'pytest'

- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: Cobertura
    summaryFileLocation: '$(PythonPackagePath)/**/coverage.xml'

一路上我掉进的几个陷阱:

1. $(VariableName) 形式的 ADO 管道变量在步骤开始时解决，而不是在到达行时解决 - 因此您需要在使用前在上一步中设置变量。
2. bash 将在变量中保留相对目录引用。所以你不能export ParentDir=..也不export ParentDir=$(System.DefaultWorkingDirectory)/..在第一种情况下，ParentDir 始终是当前工作目录的父目录，在第二种情况下，由于循环引用，符号链接(symbolic link)将失败。正则表达式 ${PWD%/*}获取当前目录的值并返回到最后一个斜线的值。
3. pytest 不喜欢跟随符号链接(symbolic link) - 所以你不能简单地 ln -s path/to/code/s path/to/code/PackageName pytest 仍会考虑将包称为 s
4. 设置PYTHONPATH不是绝对必要的，从正确的目录运行 pytest 似乎是配置中最稳定的选项
5. 我在获取代码覆盖率以正确发布方面遇到了一些问题。我认为它也不喜欢符号链接(symbolic link) - 所以不要忘记在相关步骤中更新路径。

无论测试是否在子文件夹中，这都有效。我的整体结构是:

FooBar
      __init__.py
    ¦
    -- Doomsday
      __init__.py
      Fuel.py
      test_Fuel.py
      ...
    ¦
    -- Utils
          __init__.py
          Maths.py
          ...
        ¦
        --test
              test_Maths1.py
              test_Maths2.py
              ...

哪里:

• FooBar也是我在ADO中的项目名
• Doomsday 的 pytest 测试在 Doomsday 目录中
• Utils 的 pytest 测试在子文件夹中
• 引用格式为 from FooBar.Utils.Maths import prod这些都正常工作