Azure Pipelines跨多作业/阶段容器共享卷发布失败工件的问题

核心问题定位 #

你遇到的touch: cannot touch '/mnt/artifacts/...': No such file or directory错误，本质是容器内的目标目录未被正确挂载或创建，导致无法写入文件。下面提供两种可落地的方案，解决多容器作业的工件收集与条件发布问题。

方案1：显式配置Docker卷映射 #

通过在容器作业中配置卷，将主机代理的目录与容器内目录绑定，确保容器生成的文件能同步到主机，后续可发布为工件。

完整YAML示例 #

stages:
  - stage: RunTests
    jobs:
      - job: JobA
        container:
          image: your-custom-image:tag
          # 绑定主机代理目录到容器内的/mnt/artifacts
          volumes:
            - $(Agent.BuildDirectory)/artifacts/JobA:/mnt/artifacts
          # 可选：如果容器内用户无写入权限，以root身份运行
          options: --user root
        steps:
          - script: |
              # 确保容器内目录存在（避免主机目录为空时Docker不自动创建）
              mkdir -p /mnt/artifacts
              # 执行你的测试逻辑，失败时生成调试文件
              # 示例：生成coredump
              # gcore -o /mnt/artifacts/core $(pidof your-test-process)
              # 示例：打包支持包
              # tar czf /mnt/artifacts/support-package.tar.gz /var/log/app-logs /tmp/debug-files
            displayName: 'Run tests and collect debug artifacts'
            # 即使测试失败，也要继续执行后续步骤确保工件被收集
            continueOnError: true

      - job: JobB
        container:
          image: your-custom-image:tag
          volumes:
            - $(Agent.BuildDirectory)/artifacts/JobB:/mnt/artifacts
        steps:
          # 与JobA逻辑一致，替换为JobB的测试与收集命令
          - script: |
              mkdir -p /mnt/artifacts
              # JobB的测试和工件收集逻辑
            displayName: 'Run JobB tests and collect artifacts'
            continueOnError: true

  - stage: PublishFailureArtifacts
    # 仅当测试阶段失败时执行此阶段
    condition: failed()
    jobs:
      - job: PublishArtifacts
        steps:
          - publish: $(Agent.BuildDirectory)/artifacts
            artifact: failure-debug-artifacts
            displayName: 'Publish all failure debug artifacts'

关键细节说明 #

• 卷路径选择：使用$(Agent.BuildDirectory)（代理主机的默认工作目录）作为主机端路径，确保容器能通过Docker卷访问；每个作业使用独立子目录（如JobA、JobB）避免工件互相覆盖。
• 目录预创建：在容器内执行mkdir -p /mnt/artifacts，解决主机目录为空时Docker不自动创建容器内目录的问题。
• 权限处理：若容器内用户无写入权限，可通过options: --user root以root身份运行容器，或在自定义Dockerfile中提前设置目录权限：RUN mkdir -p /mnt/artifacts && chmod 777 /mnt/artifacts。

方案2：利用默认挂载的源码目录（更简单） #

Azure Pipelines默认会将主机的$(Build.SourcesDirectory)映射到容器内的同一路径，无需额外配置卷，直接将工件写入该目录即可同步到主机。

简化YAML示例 #

stages:
  - stage: RunTests
    jobs:
      - job: JobA
        container: your-custom-image:tag
        steps:
          - script: |
              # 创建作业专属的工件目录
              mkdir -p $(Build.SourcesDirectory)/artifacts/JobA
              # 测试失败时将调试文件复制到该目录
              # 示例：复制coredump
              # cp /path/to/core $(Build.SourcesDirectory)/artifacts/JobA/
              # 示例：打包日志
              # tar czf $(Build.SourcesDirectory)/artifacts/JobA/logs.tar.gz /var/log/app
            displayName: 'Run JobA tests and collect artifacts'
            continueOnError: true
            condition: failed() # 仅失败时执行收集

  - stage: PublishFailureArtifacts
    condition: failed()
    jobs:
      - job: PublishArtifacts
        steps:
          - publish: $(Build.SourcesDirectory)/artifacts
            artifact: failure-debug-artifacts
            displayName: 'Publish failure artifacts'

优势 #

无需手动配置卷映射，利用Azure Pipelines的默认挂载机制，减少配置复杂度，适合快速调试场景。

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