6

我已经在我们的 TFS 构建服务器上安装了 npm 和 grunt。我使用npm install -g grunt-cli 安装了 grunt-cli ，然后以我自己的身份登录时能够从命令行运行grunt deploy 。

不过， Out TFS 构建以tfsservice用户身份运行，当它尝试执行grunt deploy时，它会收到一条错误消息：

'grunt' is not recognized as an internal or external command, operable program or batch file.

因此，当我在构建服务器上以我自己的身份登录时，如果我以tfsservice 身份运行命令提示符，我会得到同样的错误。所以我尝试从该命令提示符执行npm install -g grunt-cli，它看起来已经正确安装并在 C:\Users\tfsservice\AppData\Roaming\npm 中创建了 grunt 文件，但是我仍然得到同样的错误运行grunt deploy时。

所以看起来 grunt-cli 没有为tfsservice安装？当我得到 tfsservice %homepath% 时，我看到它设置为\Windows\system32，而不是预期的\Users\tfsservice；也许它是一个服务帐户与它有关？

我看到有人询问了将 grunt-cli 与 Team City 一起使用的类似问题，但它建议使用特定于 Team City 的插件。

还有这篇文章说他们改变了 Team City 作为不同的用户运行，然后一切都开始正常工作。不过，将我们的构建更改为以与tfsservice不同的用户身份运行对我来说并不是一个真正的选择。

任何建议表示赞赏。谢谢。

4

3 回答 3

7

以tfsservice登录并运行npm install -g grunt-cli后，它将所有 grunt 文件放在C:\Users\tfsservice\AppData\Roaming\npm中，但找不到C:\Users\tfsservice\AppData \Roaming\npm\grunt.cmd文件，直到我将C:\Users\tfsservice\AppData\Roaming\npm添加到系统路径；您可能能够为 tfsservice 用户的变量创建一个新的 Path 变量，但我希望它在以其他用户身份登录时也能工作。

在此处输入图像描述

一旦我以 tfsservice 身份手动登录并打开一个新的命令提示符时，grunt deploy就可以工作，但是当实际的 TFS 构建以 tfsservice 执行构建时仍然无法工作。起初我只是修改了我的构建过程，通过使用其完整路径从命令行调用 grunt.cmd，如下所示：

"C:\Users\tfsservice\AppData\Roaming\npm\grunt.cmd" deploy

并确保我在所有构建机器上运行npm install -g grunt-cli as tfsservice 以确保 grunt 存在于每个构建服务器上的 tfsservice 用户的 AppData 目录中。这行得通，但更多的是一种解决方法而不是修复。

原来最后一步是我只需要重新启动 TFS 构建服务器。一旦我完成了grunt deploy就可以按预期进行构建，所以我不需要再指定完整路径:) 只需重新启动 tfsservice 可能就足够了，但我只是重新启动了 PC 以确保安全。

于 2013-11-14T20:03:24.887 回答
1

我也经历过这种失败。将 npm 文件夹添加到全局路径并重新启动服务器确实解决了这个问题。

于 2014-11-25T15:55:42.317 回答
1

我们遇到了同样的问题，我们做了以下事情：

首先，我们在我们的系统用户上安装了所有用于构建的软件。

为了找出将使用哪个用户，我们添加了一个带有 echo %username% 的批处理文件，并将“批处理脚本”任务添加到构建过程中，并让该任务执行我们的脚本。

因此，如果 TFS 正在构建工件，我们可以使用 TFS 使用的同一用户在 TFS 上安装所有需要的软件。

我们尝试了 npm 是否正常工作，grunt 是否已全局安装，并且 ruby​​ 也获得了它的 sass gem。在一些配置和添加丢失的路径变量后一切正常。

所以我们知道构建用户理解所有给定的批处理命令，因为我们也在这个用户登录的情况下进行了尝试。对吧？

错误 =( ...每次构建总是向我们展示：

'grunt' is not recognized as an internal or external command, operable program or batch file.

以及 npm 和 ruby​​ sass。

所以我们以与描述相同的方式执行了一个批处理脚本，只是 echo %path% 作为其内容。

经过大量失败的构建并通过批处理脚本和绝对路径调用所有工具后，我们找到了这篇文章并简单地重新启动了 TFS，一切都像魅力一样。

因此，似乎 TFS 正在缓存给定的路径变量，并且没有在每次构建时都查找它们。其他一些解释或提示如何避免 TFS 的这种行为？

我找到了一种在 windows cli 中实现相同行为的方法，并且可以想象它仍然是同样的问题，因此我们可以在每次构建之前运行这个脚本。但在我看来，这看起来有点骇人听闻。

谢谢大家的好帖子。

于 2017-01-19T16:10:48.887 回答