运行可能无法启动的另一个原因是，组织在最后一个用户注销 Azure DevOps 五分钟后进入休眠状态。 之后，每个生成管道将再运行一次。 例如，当组织处于休眠状态时：

UI 设置替代 YAML 触发器设置

YAML 管道可以在管道设置 UI 中重写其 trigger 和 pr 触发器设置。 trigger 如果 或 pr 触发器似乎未触发，请检查该设置。 编辑管道时，选择 “...” ，然后选择 “触发器 ”。

选中“ 从此处替代 YAML 触发器 ”设置，了解存储库可用的触发器类型 ( 持续集成 或 拉取请求验证 ) 。

Azure Repos 不支持拉取请求触发器

pr 如果触发器未触发，并且使用的是Azure Repos，则这是因为 pr Azure Repos不支持触发器。 在 Azure Repos Git 中，分支策略用于实现拉取请求生成验证。 有关详细信息，请参阅 拉取请求验证的分支策略 。

CI 和 PR 触发器中配置错误的分支筛选器

定义 YAML PR 或 CI 触发器时，可以为分支和路径指定 include 和 exclude 子句。 确保 include 子句与提交的详细信息匹配， exclude 并且 子句不会排除它们。

定义 YAML PR 或 CI 触发器时，只有显式配置为包含的分支才会触发运行。 首先处理包含，然后从列表中删除排除项。 如果指定排除但未指定任何包含项，则不会触发任何内容。 有关详细信息，请参阅 pr 和 触发器 。

定义 YAML PR 或 CI 触发器时，可以为分支、标记和路径指定 include 和 exclude 子句。 确保 include 子句与提交的详细信息匹配， exclude 并且 子句不会排除它们。 有关详细信息，请参阅 pr 和 触发器 。

如果在没有 子句的情况下 include 指定 exclude 子句，则等效于在 子句中 include 指定 * 。

计划的触发器时区转换

YAML 计划触发器是使用 UTC 时区设置的。 如果计划的触发器似乎未在正确的时间触发，请确认 UTC 与本地时区之间的转换，同时考虑日期设置。 有关详细信息，请参阅 计划的触发器 。

UI 设置替代 YAML 计划触发器

如果 YAML 管道同时具有 YAML 计划触发器和 UI 定义的计划触发器，则仅运行 UI 定义的计划触发器。 若要在 YAML 管道中运行 YAML 定义的计划触发器，必须删除管道设置 UI 中定义的计划触发器。

若要从 YAML 管道访问管道设置 UI，请编辑管道，选择 “...” ，然后选择 “触发器 ”。

删除所有计划的触发器。

删除所有 UI 计划的触发器后，必须进行推送，以便 YAML 计划的触发器开始运行。 有关详细信息，请参阅 计划的触发器 。

管道队列，但永远不会获取代理

如果管道排队但从未获取代理，请检查以下项。

以下方案不会使用并行作业：

了解详细信息： 管道如何使用并行作业 、 添加预部署审批 、 服务器作业 、 部署组

对于公共项目和某些专用项目，Azure Pipelines 暂时禁用了在新组织中自动免费授予 Microsoft 托管的并行作业。 如果没有任何并行作业，管道将失败并出现以下错误： ##[error]No hosted parallelism has been purchased or granted. To request a free parallelism grant, please fill out the following form https://aka.ms/azpipelines-parallelism-request 。 如以下部分所述检查 Microsoft 托管的并行作业，如果并行作业为零，则可以请求免费授予并行作业。 若要为组织请求免费授予并行作业， 请提交请求 。 请留出 2-3 个工作日来回复你的授权请求。

若要检查限制，请导航到 “项目设置”、“ 并行作业 ”。

如果使用 Microsoft 托管 的代理，请检查 Microsoft 托管 的 专用项目 或 公共项目的 并行作业限制，具体取决于 Azure DevOps 项目是 专用项目 (默认) 还是公共项目 。

查看限制后，检查并发性以查看当前正在运行的作业数以及可用的作业数。

如果当前正在运行其他管道，则可能没有任何剩余的并行作业，或者可能已达到 免费限制 。

无法从 Azure DevOps 访问防火墙后面的 Azure 密钥保管库

如果无法从管道访问 Azure 密钥保管库，防火墙可能会阻止Azure DevOps Services代理 IP 地址。 必须在每周 JSON 文件中 发布的 IP 地址列入允许列表。 有关详细信息，请参阅 Microsoft 托管的代理：网络 。

并发性不足

若要检查并发量，请执行以下操作：

仅在本地 TFS (测试代理连接时配置失败)

Testing agent connection.
VS30063: You are not authorized to access http://<SERVER>:8080/tfs
如果在配置代理时收到上述错误，请登录到 TFS 计算机。 启动 Internet Information Services (IIS) 管理器。 确保已启用 匿名身份验证 。
代理丢失通信
此问题的特点是错误消息：
The job has been abandoned because agent did not renew the lock. Ensure agent is running, not sleeping, and has not lost communication with the service.
此错误可能表示代理在几分钟内丢失了与服务器的通信。 检查以下内容以排除代理计算机上的网络或其他中断：
验证自动更新是否已关闭。 从更新重启计算机将导致生成或发布失败并出现上述错误。 以受控方式应用更新，以避免这种类型的中断。 在重新启动代理计算机之前，请在池管理页中将代理标记为已禁用，并让任何正在运行的生成完成。
验证睡眠设置是否已关闭。
如果代理在虚拟机上运行，请避免任何实时迁移或其他 VM 维护操作，这些操作可能会严重影响计算机的运行状况数分钟。
如果代理在虚拟机上运行，则相同的操作系统更新建议和睡眠设置建议适用于主机。 以及其他任何影响主机的维护操作。
性能监视器日志记录或其他运行状况指标日志记录有助于将这种类型的错误与代理计算机上的受限资源可用性相关联， (磁盘、内存、页文件、处理器、网络) 。
将错误与网络问题关联的另一种方法是无限期地 ping 服务器，并将输出和时间戳转储到文件。 使用正常间隔，例如 20 或 30 秒。 如果使用 Azure Pipelines，则需要 ping Internet 域，例如 bing.com。 如果使用本地 TFS 服务器，则需要在同一网络上对服务器执行 ping 操作。
验证计算机的网络吞吐量是否足够。 可以执行联机速度测试来检查吞吐量。
如果使用代理，请验证代理是否已配置为使用代理。 请参阅代理部署主题。
TFS 作业代理未启动
这可能由 Web 控制台中的消息“正在等待代理请求”来描述。 验证 TFSJobAgent (显示名称： Visual Studio Team Foundation 后台作业代理) Windows 服务是否已启动。
 (1.x 代理版本) 配置错误的通知 URL
这可能表现为 Web 控制台中的消息“正在等待代理的控制台输出”，并且进程最终超时。
不匹配的通知 URL 可能会导致进程无法连接到服务器。 请参阅 Team Foundation 管理控制台，应用程序层。 1.x 代理使用配置的消息队列的 URL 侦听消息队列。 但是，从队列中拉取作业消息时，工作进程使用通知 URL 与服务器通信。
检查服务降级的 Azure DevOps 状态
检查 Azure DevOps 服务状态门户 ，了解可能导致服务降级的任何问题，例如代理的队列时间延长。 有关详细信息，请参阅 Azure DevOps 服务状态。
管道无法完成
如果管道获取代理但无法完成，请检查以下常见问题。 如果问题似乎与其中之一不匹配，请参阅 获取日志以诊断问题。
下载代码时出现问题
我的管道在命令行步骤（如 MSBUILD）上失败
文件或文件夹正在使用错误
间歇性或不一致的 MSBuild 失败
进程停止响应
多个平台的行尾
追加 (单引号) 变量
服务连接相关问题
失败管道运行的任务见解
Azure DevOps 提供 “失败管道运行任务见解” 设置，启用该设置后，会提供生成失败的弹出通知以及用于查看报告的链接。
若要配置此设置，请导航到 “预览功能”，找到 “失败管道运行的任务见解”，然后选择所需的设置。
管道可能会长时间运行，然后由于作业超时而失败。作业超时取决于所使用的代理。 对于专用存储库，免费 Microsoft 托管代理的每个作业的最大超时时间为 60 分钟，公共存储库的最大超时时间为 360 分钟。
若要增加作业的最大超时时间，可以选择以下任一选项。
购买 Microsoft 托管代理，它将为所有作业提供 360 分钟，而不考虑使用的存储库
使用自承载代理排除因代理而导致的任何超时问题
详细了解作业 超时。
如果 Microsoft 托管的代理作业超时，请确保未指定小于作业最大超时的管道超时。 若要检查，请参阅 超时。
下载代码时出现问题
我的管道在签出步骤中失败
Team Foundation 版本控制 (TFVC) 问题
我的管道在签出步骤中失败
如果在组织中Azure Repos Git 存储库上使用checkout的步骤，而该步骤位于管道不同的项目中，请确保禁用“将作业授权范围限制为当前项目”设置，或按照作用域内生成标识中的步骤操作，以确保管道有权访问存储库。
当管道由于作业授权范围有限而无法访问存储库时，将收到错误 Git fetch failed with exit code 128 ，并且日志将包含类似于 的条目 Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.
如果管道立即出现故障，请确保 Could not find a project that corresponds with the repository步骤或存储库资源声明中的项目和存储库名称正确 checkout 。
Team Foundation 版本控制 (TFVC) 问题
获取未下载某些文件的源
通过 Team Foundation 代理获取源
获取未下载某些文件的源
这可能由命令的日志中“所有文件都为最新” tf get 的消息来表示。 验证内置服务标识是否有权下载源。 标识 项目集合生成服务 或 项目生成服务 将需要下载源的权限，具体取决于生成管道的“常规”选项卡上的所选授权范围。 在版本控制 Web UI 中，可以在文件夹层次结构的任何级别上浏览项目文件并检查安全设置。
通过 Team Foundation 代理获取源
配置代理以通过 Team Foundation 代理获取源的最简单方法是设置环境变量，该环境变量 TFSPROXY 指向代理以用户身份运行的 TFVC 代理服务器。
Windows：
    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable
macOS/Linux：
    export TFSPROXY=http://tfvcproxy:8081
我的管道在命令行步骤（如 MSBUILD）上失败
缩小生成或发布失败是 Azure Pipelines/TFS 产品问题导致的， (代理或任务) ，这很有帮助。 生成和发布失败也可能由外部命令导致。
检查日志中是否有失败任务执行的确切命令行。 尝试从命令行本地运行命令可能会重现问题。 从自己的计算机本地运行命令和/或登录到计算机并作为服务帐户运行命令可能会有所帮助。
例如，在生成管道的 MSBuild 部分期间是否 (出现问题，是否使用 MSBuild 或 Visual Studio 生成 任务) ？ 如果是这样，请尝试使用相同的参数在本地计算机上运行相同的 MSBuild 命令 。 如果可以在本地计算机上重现问题，则后续步骤是调查 MSBuild 问题。
生成所需的工具、库、标头和其他内容在托管代理上的位置可能与本地计算机不同。
如果生成因找不到这些文件之一而失败，则可以使用以下脚本检查代理上的布局。
这可能有助于跟踪缺少的文件。
在临时位置创建新的 YAML 管道 (例如为排查) 问题而创建的新存储库。
编写后，脚本将搜索路径上的目录。
可以选择编辑该 SEARCH_PATH= 行以搜索其他位置。
# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
本地命令提示符和代理之间的差异
请记住，在本地计算机上执行命令以及代理上运行生成或发布时，某些差异会有效。 如果代理配置为在 Linux、macOS 或 Windows 上作为服务运行，则它不会在交互式登录会话中运行。 如果没有交互式登录会话，UI 交互和其他限制就存在。
文件或文件夹正在使用错误
File or folder in use 错误通常由错误消息指示，例如：
Access to the path [...] is denied.
The process cannot access the file [...] because it is being used by another process.
Access is denied.
Can't move [...] to [...]
疑难解答步骤：
检测正在使用的文件和文件夹
防病毒排除
MSBuild 和 /nodeReuse：false
MSBuild 和 /maxcpucount：[n]
检测正在使用的文件和文件夹
在 Windows 上， 进程监视器 等工具可用于捕获特定目录下的文件事件的跟踪。 或者，对于实时快照，可以使用 进程资源管理器 或 句柄 等工具。
防病毒排除
防病毒软件扫描文件可能会导致生成或发布期间出现文件或文件夹使用错误。 为代理目录添加防病毒排除并配置了“工作文件夹”可能有助于将防病毒软件识别为干扰过程。
MSBuild 和 /nodeReuse：false
如果在生成期间调用 MSBuild，请确保 (短格式/nr:false) 传递参数/nodeReuse:false。 否则，生成完成后，MSBuild 进程 (es) 将继续运行。 该过程 (es) 保留一段时间，以预期潜在的后续生成。
MSBuild 的此功能可能会干扰删除或移动目录的尝试 - 由于与 MSBuild 进程的工作目录发生冲突， (es) 。
MSBuild 和 Visual Studio 生成任务已添加到 /nr:false 传递给 MSBuild 的参数。 但是，如果从自己的脚本调用 MSBuild，则需要指定 参数。
MSBuild 和 /maxcpucount：[n]
默认情况下，生成任务（如 MSBuild 和 Visual Studio 生成） 使用 /m 开关运行 MSBuild。 在某些情况下，这可能会导致问题，例如多个进程文件访问问题。
尝试将 /m:1 参数添加到生成任务，以强制 MSBuild 一次只运行一个进程。
利用 MSBuild 的并发进程功能时，可能会导致文件使用中问题。 不 (短格式/m:[n]指定参数/maxcpucount:[n]) 指示 MSBuild 仅使用单个进程。 如果使用 MSBuild 或 Visual Studio 生成任务，则可能需要指定“/m：1”以替代默认添加的“/m”参数。
间歇性或不一致的 MSBuild 故障
如果遇到间歇性或不一致的 MSBuild 故障，请尝试指示 MSBuild 仅使用单进程。 间歇性或不一致错误可能表明目标配置与 MSBuild 的并发进程功能不兼容。 请参阅 MSBuild 和 /maxcpucount：[n]。
进程停止响应
进程停止响应原因和故障排除步骤：
正在等待输入
WiX 项目
正在等待输入
停止响应的进程可能指示进程正在等待输入。
从交互式登录会话的命令行运行代理可能有助于确定进程是否在提示输入对话框。
将代理作为服务运行可能有助于消除程序提示输入。 例如，在 .NET 中，程序可能依赖于 System.Environment.UserInteractive Boolean 来确定是否提示。 代理作为 Windows 服务运行时，值为 false。
分析进程的转储有助于确定死锁进程正在等待什么。
WiX 项目
启用自定义 MSBuild 记录器后生成 WiX 项目可能会导致 WiX 死锁等待输出流。 添加其他 MSBuild 参数 /p:RunWixToolsOutOfProc=true 将解决此问题。
多个平台的行尾
在多个平台上运行管道时，有时可能会遇到不同行尾的问题。
从历史上看，Linux 和 macOS 使用换行 (LF) 字符，而 Windows 使用回车加上换行符 (CRLF) 。
Git 尝试通过在存储库中自动使行以 LF 结尾，但在 Windows 上的工作目录中使行以 CRLF 结尾来弥补差异。
大多数 Windows 工具都适合仅使用 LF 结束，并且这种自动行为可能会导致比它解决的更多问题。
如果遇到基于行尾的问题，建议将 Git 配置为在任意位置首选 LF。
为此，请将文件添加到 .gitattributes 存储库的根目录。
在该文件中，添加以下行：
* text eol=lf
 (单引号) 追加的变量
如果管道包含使用 ##vso 命令设置变量的 Bash 脚本，则可能会在设置的变量的值后面附加一个 ' 附加内容。
发生这种情况的原因是与 set -x交互。
解决方法是在设置变量之前暂时禁用 set -x 。
用于执行此操作的 Bash 语法为 set +x。
set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x
为何发生这种情况？
许多 Bash 脚本都包含 set -x 命令来帮助调试。
Bash 将准确跟踪执行了哪个命令，并将其回显到 stdout。
这将导致代理看到 ##vso 命令两次，第二次，Bash 会将字符添加到 ' 末尾。
例如，请考虑以下管道：
steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value
在 stdout 上，代理将看到两行：
##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'
当代理看到第一行时， MY_VAR 将设置为正确的值“my_value”。
但是，当它看到第二行时，代理将处理所有内容到该行的末尾。
MY_VAR 将设置为“my_value”。
执行脚本时，不会为 Python 应用程序安装库
部署 Python 应用程序时，在某些情况下，CI/CD 管道运行并成功部署代码，但负责安装所有依赖项库的 requirements.txt 文件不会执行。
若要安装依赖项，请在App 服务部署任务中使用部署后脚本。 以下示例演示必须在部署后脚本中使用的命令。 可以更新方案的脚本。
D:\home\python364x64\python.exe -m pip install -r requirements.txt
服务连接相关问题
若要排查与服务连接相关的问题，请参阅 服务连接故障排除。
启用 存储资源管理器，通过 Azure Pipelines 将静态内容（如 .css 和 .js）部署到 Azure DevOps 中的静态网站
在此方案中，可以使用 Azure 文件复制任务 将内容上传到网站。 可以使用 上传内容 中所述的任何工具将内容上传到 Web 容器。
获取日志以诊断问题
如果上述建议都不符合你的问题，则可以使用日志中的信息来诊断失败的管道。
首先查看已完成的生成或版本中的日志。 可导航到管道运行摘要并选择作业和任务来查看日志。 如果某个任务失败，请检查该任务的日志。
除了在管道生成摘要中查看日志外，还可以下载包含其他诊断信息的完整日志，还可以配置更详细的日志来帮助进行故障排除。
有关配置和使用日志的详细说明，请参阅查看日志以诊断管道问题。
我需要更多帮助。 我发现了一个 bug。 我有一个建议。 我该去哪里？
获取订阅、计费和技术支持
在开发者社区报告任何问题或提交反馈。
欢迎你提供建议：