在构建任务中强制执行PowerShell

Question

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

有人能提供这方面的见解吗？其中一项任务是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脚本，我想我会很好。

Answer 1

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

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

• powershell - 现在已弃用的（代理2.0）powershell处理程序，它使用特殊PowerShell主机中的powershell脚本。
• powershell3 - 新的powershell处理程序，它使用特殊模块与代理交互，允许脚本也在代理之外运行（方便调试）
• javascript - 在节点
中运行javascript的现已弃用的跨平台处理程序
• node - 使用vsts-node-lib以与powershell3处理程序大致相同的方式与代理进行通信的新javascript处理程序。

task.json中的执行部分定义了运行的实现。 Windows上的代理程序支持powershell，powershell3和node，它支持Node运行程序，然后是powershell3，然后是powershell，除非there is a specific "platforms" section that gives precedence to a specific handler。

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