Azure Pipelines从Azure Artifacts下载工件失效求助

背景与配置 #

我配置了一组Azure Pipelines，流水线一完成后触发流水线二。流水线一向Azure Artifacts发布小型JSON文件，流水线二则负责下载该文件。

流水线一配置 #

# Pipeline one

trigger:
- '*'

pool:
  name: 'Default'
  demands:
  # I use this property to make sure it runs on the correct build agent
  - Can_do_builds -equals true

steps:
- script: |
    echo This is Pipeline One.
    echo Running on $(Agent.MachineName)
    echo Running in $(Pipeline.Workspace)
  displayName: 'Display Pipeline One info'

- powershell: |
    $json = @"
    {
        'build_id': '$(Build.BuildID)',
        'build_number': '$(Build.BuildNumber)',
        'build_type': '$(Build.Reason)',
        'source_repo': '$(Build.Repository.Name)',
        'source_branch': '$(Build.SourceBranchName)',
        'source_commit_id': '$(Build.SourceVersion)'
    }
    "@
    $f = '$(Pipeline.Workspace)/s/dropfile.json'
    Add-Content -Path $f -Value $json
    Write-Host Contents of $f
    Write-Host "================="
    Get-Content $f
  displayName: Create the dropfile

- publish: dropfile.json
  artifact: theDropfile
  displayName: Publish the dropfile

流水线二配置 #

# Pipeline two

trigger:
- master

pool:
  name: 'Default'
  demands:
  # I use this property to make sure it runs on the other build agent
  - Can_do_integration_tests -equals true

resources:
  pipelines:
  - pipeline: pipeline-one
    source: my_workspace.pipeline-one
    trigger:
      enabled: true
      branches:
        include:
        - master
        - develop
        - release_*
        - passing-info-btwn-pipelines

steps:
- script: |
    echo This is Pipeline Two.
    echo Running on $(Agent.MachineName)
    echo Running in $(Pipeline.Workspace)
    echo Build reason is $(Build.Reason)
    echo Triggering resource is $(Resources.TriggeringAlias)
    echo Triggering category is $(Resources.TriggeringCategory)
  displayName: 'Display Pipeline Two info'

# - task: DownloadPipelineArtifact@2
#   displayName: Download the dropfile
#   inputs:
#     source: 'specific'
#     project: 'QA'
#     pipeline: 'my_workspace.pipeline-one' # if it will accept strings
#     # pipeline: 12 # if it won't accept strings
#     preferTriggeringPipeline: 'true'
#     runVersion: 'latest'
#     artifact: theDropfile
#     path: '$(Pipeline.Workspace)/s/'

- download: pipeline-one
  artifact: theDropfile
  patterns: '**/*.json'
  displayName: Download the dropfile the other way

- powershell: |
      $f = "$(Pipeline.Workspace)/s/dropfile.json"
      if( Test-Path $f ) {
        Get-Content $f
      } else {
        Write-Host '$f not found'
      }
  displayName: Read the dropfile

故障现象 #

原本一切正常，但IT团队执行两项操作后出现问题：

1. 移除了Just-In-Time功能；
2. 将两台自托管VM（运行Windows Server 2016）加入companyname.local域。

流水线一仍可正常发布工件，我能通过构建日志中的链接手动下载验证，但流水线二下载工件时尝试18分钟后失败，日志报错No such host is known，使用DownloadPipelineArtifact@2任务和download快捷方式均出现相同故障。

原因分析 #

报错“No such host is known”本质是DNS解析失败，结合IT的操作，核心原因集中在：

• 自托管代理加入域后，DNS配置被覆盖，导致无法解析Azure DevOps/Artifacts的公网域名
• 域环境下的防火墙、组策略或DNS转发规则限制了代理对Azure服务的访问
• 移除JIT功能后，代理的网络访问策略可能发生变更，进一步加剧了域名解析或访问问题

排查与解决步骤 #

1. 验证代理的DNS解析能力 #

在流水线二所在的代理VM上执行以下命令，测试能否解析Azure相关域名：

# 测试Azure DevOps主域名
nslookup dev.azure.com
# 测试组织工件域名（替换为你的组织名称）
nslookup your-org-name.artifacts.azure.com

如果解析失败，需IT团队：

• 检查域DNS服务器的转发规则，确保能正常转发公网域名查询请求
• 为代理VM配置备用DNS服务器（如8.8.8.8），避免域DNS无法解析公网地址

2. 检查代理的网络访问权限 #

• 在代理VM上打开浏览器，访问你的Azure DevOps组织门户（https://dev.azure.com/your-org-name），确认能正常加载页面
• 检查域防火墙/组策略是否新增了出站访问限制，确保允许代理访问Azure DevOps和Artifacts的服务端点
• 确认Azure Pipelines代理服务的运行账户：加入域后若使用域账户运行，需确保该账户有访问Azure DevOps组织的权限，且网络策略允许其出站流量

3. 重新配置自托管代理 #

• 卸载代理VM上的现有Azure Pipelines代理，重新从Azure DevOps门户下载并配置，确保在域环境下正确注册
• 检查代理配置文件（config.cmd）中的组织URL是否正确，避免因域环境导致的端点配置错误

4. 确认工件访问权限 #

• 在Azure DevOps门户中，检查流水线一的工件权限，确保流水线二所在的项目或用户组拥有下载权限
• 验证流水线二的运行账户（或服务连接）有读取流水线一工件的权限

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