我在我们的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 ;也许这是一个服务帐户与它有关?
我看到a similar questions has been asked for using grunt-cli with Team City,但建议使用Team City特定的插件。
还有this post表示他们改变了Team City作为不同的用户运行,然后一切都开始正常运行。将我们的版本更改为与 tfsservice 不同的用户运行对我来说不是一个真正的选择。
任何建议都表示赞赏。感谢。
答案 0 :(得分:6)
以 tfsservice 登录并运行 npm install -g grunt-cli 后,它将所有grunt文件放在 C:\ Users \ tfsservice \ AppData中\漫游\ npm ,但在添加 C:\ Users之前找不到 C:\ Users \ tfsservice \ AppData \ Roaming \ npm \ grunt.cmd 文件\ tfsservice \ AppData \ Roaming \ npm 到系统路径;您可能只为tfsservice用户的变量创建一个新的Path变量,但我希望它在以其他用户身份登录时也能正常工作。
当我手动以tfsservice身份登录并打开一个新的命令提示符时, grunt deploy 工作了,但是当实际的TFS Build将构建执行为tfsservice时仍然无法工作。起初我刚刚修改了我的构建过程,通过使用其完整路径从命令行调用grunt.cmd,如下所示:
"C:\Users\tfsservice\AppData\Roaming\npm\grunt.cmd" deploy
并确保我在所有构建计算机上运行 npm install -g grunt-cli 作为tfsservice,以确保grunt存在于每个构建服务器上的tfsservice用户的AppData目录中。这有效,但更多的是解决方法而不是修复。
原来最后一步是我不得不重新启动TFS Build服务器。一旦我做了 grunt deploy 按预期的方式工作,所以我不需要再指定完整路径:)只需重新启动tfsservice可能已经足够了,但我只是重新启动了PC安全。
答案 1 :(得分:1)
我也经历过这次失败。将npm文件夹添加到全局路径并重新启动服务器确实解决了这个问题。
答案 2 :(得分:1)
我们遇到了同样的问题,我们做了以下事情:
首先,我们在我们的系统用户上安装了每个软件,也用于构建。
要找出将使用哪个用户,我们添加了一个带有echo%username%的批处理文件,并将“批处理脚本”任务添加到构建过程中,并让此任务执行我们的脚本。
因此,我们可以在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的这种行为?
我发现way与windows cli的行为相同,可以想象它仍然是同一个问题所以我们可以在每次构建之前运行这个脚本。 但对我的看法来说,这看起来有些苛刻。
Thx家伙为好帖子。