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 回答