Azure Pipeline作业中执行docker run挂载源码目录报错问题咨询

核心问题根源 #

该报错的本质不是目录权限问题，最常见的两类触发原因如下：

1. 自托管代理为容器化部署（Docker-in-Docker模式）：你打印出的/var/vsts/28/s是代理容器内部的路径，执行docker run命令时实际调用的是宿主机的Docker daemon，daemon只会在宿主机本地检索该路径，找不到就会抛出路径不存在的错误。微软托管代理直接运行在虚拟机/物理机上，没有容器嵌套层，因此配置可以正常运行。
2. Linux环境下PowerShell变量解析冲突：Azure DevOps预定义变量$(Build.SourcesDirectory)写在内联PowerShell脚本中时，Linux版PowerShell可能会将$()识别为子命令执行，无法正确解析为Azure DevOps的预定义变量值。

排查步骤 #

• 确认自托管代理部署模式：在代理运行的宿主机器上执行ps aux | grep vsts-agent，如果代理进程运行在容器内（即当初使用容器镜像部署的自托管代理），则可判定为Docker-in-Docker嵌套问题。
• 验证变量解析结果：在执行docker run的脚本前增加路径打印命令，确认变量解析结果符合预期：

Write-Host "Source directory path: $(Build.SourcesDirectory)"

随后在代理宿主机器上直接执行ls /var/vsts/28/s，确认该路径是否真实存在于宿主机本地。

• 验证Docker调用权限：执行groups $(whoami)确认代理运行用户在docker用户组内，若不在可执行sudo usermod -aG docker $USER后重启代理服务。

对应解决方法 #

容器化部署代理场景 #

• 方案1：部署代理容器时配置路径挂载，将宿主机的代理工作目录挂载到代理容器的相同路径下，例如代理容器内工作目录为/var/vsts，启动代理容器时增加参数-v /宿主机代理工作目录的真实路径:/var/vsts，保证宿主和代理容器内路径完全一致，Docker daemon即可正常识别挂载路径。
• 方案2：替换挂载源路径为宿主机真实路径，可提前在代理上配置环境变量存储宿主机工作目录前缀，运行时替换掉容器路径前缀即可。

变量解析冲突场景 #

Linux环境下PowerShell调用Azure DevOps预定义变量时，改用环境变量格式调用，所有Azure DevOps预定义变量都会自动转换为大写、点替换为下划线的环境变量，$(Build.SourcesDirectory)对应的环境变量为$ENV:BUILD_SOURCESDIRECTORY，修改docker run命令如下：

docker run --rm --mount type=bind,source=$ENV:BUILD_SOURCESDIRECTORY,target=/project myimage:latest

兜底兼容方案 #

直接切换工作目录到源码根目录后使用$(pwd)传参，和本地测试逻辑保持一致：

cd $(Build.SourcesDirectory)
docker run --rm --mount type=bind,source="$(pwd)",target=/project myimage:latest

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