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