1

我在 Visual Studio Team Services 中有一个构建配置，它一直运行良好，直到今天它莫名其妙地开始使用节点执行步骤而不是 PowerShell 步骤。构建代理在 Windows 机器上运行，因此根据我的知识，它不应该使用 Node 路由。

任何人都可以提供对此的见解吗？其中一项任务是 NPM 和 NPM 安装任务。

第一行通常是：

2015-11-30T17:57:28.3209069Z Executing the powershell script: C:\agent-internal\tasks\NpmInstall\0.1.3\NpmInstall.ps1

它已切换到：

2015-11-30T19:36:08.2543618Z Set workingFolder to default: C:\agent-internal\tasks\Npm\0.2.0

这导致了涟漪错误效应。有任何想法吗？如果我可以强制执行 PowerShell 脚本，我想我会很好。

4

1 回答 1

1

简而言之：Node 处理程序可以在 Windows 上正常运行。该任务已更新为跨平台兼容。

每个构建任务都可以附带同一任务的多个实现。有许多处理程序：

  • powershell - 现在已弃用（从代理 2.0 开始）的 powershell 处理程序，它使用在特殊的 powershell 主机内运行 powershell 脚本。
  • powershell3 - 新的 powershell 处理程序，它使用特殊模块与代理交互，允许脚本也在代理之外运行（便于调试）
  • javascript - 现在已弃用的跨平台处理程序，它在节点内运行 javascript
  • node - 新的 javascript 处理程序，它使用 vsts-node-lib 以与 powershell3 处理程序相同的方式与代理通信。这在节点 5 或节点 6 LTS 中。
    • node10 - 与节点处理程序相同的基础架构，但它在自 2018 年 11 月以来与代理一起提供的节点 10 版本中运行。

task.json 中的执行部分定义了运行哪个实现。Windows 上的代理支持 powershell、powershell3 和 node，它支持 Node 运行器，然后是 powershell3，然后是 powershell，除非有一个特定的“平台”部分优先于特定的处理程序。

当构建代理更新自身以及将新版本的任务发布到 VSTS 的 Marketplace 时，任务作者可以选择包含节点实现，从而使任务跨平台。大多数任务作者更愿意在所有平台上使用该一种实现，以确保功能奇偶校验并防止仅在调用特定处理程序时出现的问题。出于向后兼容的原因，任务作者也倾向于发布旧的实现。在我自己的情况下，当使用旧实现时，我已经开始记录构建警告。

于 2016-12-29T12:44:48.137 回答