将步骤放入Job后Azure DevOps流水线集成测试随机失败

问题背景 #

• 测试基于VMSS实例运行，流程包括：Docker部署PostgreSQL（此环节正常）、环境变量配置代码、访问Key Vault（此环节正常）、启动gevent Flask容器、tox环境执行pytest测试
• 异常现象：直接在VMSS实例运行、仅用steps的流水线运行都正常；把所有步骤放进jobs>job后，测试随机失败

两种流水线配置示例 #

仅Steps的正常配置 #

steps:
  - script: docker run -d --name postgres -e POSTGRES_PASSWORD=xxx postgres:14
    displayName: '启动PostgreSQL容器'

  - script: az keyvault secret show --vault-name my-vault --name db-connection-string --query value -o tsv > connection.txt
    displayName: '从Key Vault获取配置'

  - script: export DB_CONNECTION=$(cat connection.txt)
    displayName: '设置环境变量'

  - script: docker run -d --name flask-app -p 5000:5000 -e DB_CONNECTION=$DB_CONNECTION my-flask-image:latest
    displayName: '启动Flask应用容器'

  - script: tox -e integration-test
    displayName: '执行集成测试'

放入Jobs>Job的异常配置 #

jobs:
- job: IntegrationTestJob
  pool:
    name: MyVMSSPool
  steps:
    - script: docker run -d --name postgres -e POSTGRES_PASSWORD=xxx postgres:14
      displayName: '启动PostgreSQL容器'

    - script: az keyvault secret show --vault-name my-vault --name db-connection-string --query value -o tsv > connection.txt
      displayName: '从Key Vault获取配置'

    - script: export DB_CONNECTION=$(cat connection.txt)
      displayName: '设置环境变量'

    - script: docker run -d --name flask-app -p 5000:5000 -e DB_CONNECTION=$DB_CONNECTION my-flask-image:latest
      displayName: '启动Flask应用容器'

    - script: tox -e integration-test
      displayName: '执行集成测试'

差异原因排查方向 #

1. 环境变量作用域问题 #

仅用steps时，所有步骤默认在同一个shell会话里执行，export的环境变量能被后续步骤继承。但放进job后，每个script步骤是独立的shell进程，export的变量跨步骤传不过去。要是Flask容器没拿到正确的DB_CONNECTION，就会随机出现数据库连接失败的情况。

验证修复：改用ADO的task.setvariable命令设置全局变量，确保job内所有步骤都能拿到：

- script: |
    CONN_STRING=$(az keyvault secret show --vault-name my-vault --name db-connection-string --query value -o tsv)
    echo "##vso[task.setvariable variable=DB_CONNECTION]$CONN_STRING"
  displayName: '设置全局环境变量'

2. 容器/端口残留冲突 #

VMSS代理机器可能有之前job留下的未清理容器，job模式下不同job的隔离性可能导致端口（比如5000）被占用，而steps模式是同一会话，残留清理更彻底，所以不会出问题。

验证修复：启动容器前先清理残留：

- script: |
    docker stop flask-app || true
    docker rm flask-app || true
    docker stop postgres || true
    docker rm postgres || true
  displayName: '清理残留容器'

3. 服务启动等待时间不足 #

job模式下代理机器的资源调度可能有延迟，Flask或PostgreSQL还没完全启动就开始跑测试，导致连接超时。steps模式步骤执行连贯，等待时间足够，所以不会触发这个问题。

验证修复：测试前加等待逻辑，检查服务是否就绪：

- script: |
    until curl -s http://localhost:5000/healthcheck; do
      echo "等待Flask应用启动..."
      sleep 2
    done
  displayName: '等待Flask应用就绪'

4. Job级别的资源/权限差异 #

job模式下ADO会创建独立的工作目录或权限上下文，可能导致tox环境依赖安装不全，或者测试访问资源时出现权限问题，进而随机失败。

验证修复：在tox执行前打印环境信息，对比steps模式的输出：

- script: |
    pwd
    ls -la
    whoami
  displayName: '检查工作环境'

内容的提问来源于stack exchange，提问作者Dave