Nodejs npm step 在 TeamCity 中的每个构建上下载包
Nodejs npm step downloads packages on every build in TeamCity
当谈到 nodejs npm 时，我有点 n00b，但是自从使用几篇文章中推荐的步骤在我们的构建环境中实现它后，我们的构建时间增加了两倍。
我们将其用于标准内容 (minify/concat/etc js/css/etc)
我们使用 TeamCity 并添加了一个 Node.js NPM 步骤，然后添加了一个 gulp 步骤到 运行 任务（回复：https://github.com/jonnyzzz/TeamCity.Node）
设置 NPM 的任务花费的时间最多，为 2 分 10 秒，超过调用命令 "npm install" 的总构建时间的 65%，这似乎是在每次构建时重新下载所有包
Step 3/7: NPM Setup (Node.js NPM) (2m:10s)
[npm install] Starting: cmd /c npm install
之前的总构建时间约为 1 分 30 秒，包括单元测试。
有没有办法在本地缓存这些并防止在每次构建时重新下载？在用户配置文件或其他可能与构建文件夹相反的地方？
更多详情..
这可能最能说明设置 http://www.dotnetcurry.com/visualstudio/1096/using-grunt-gulp-bower-visual-studio-2013-2015
我们有使用新的 Task Runner Explorer 的 C# 项目，依赖项被保存到 package.json 中，您在本地环境中预 运行 "npm install" 一次你的工作区（需要使用 .tfignore 来防止它签入源代码）然后就不会了，除非你启动一个新的本地工作区。
当构建 运行 时，它需要从命令行 运行 "npm install" 并从 package.json 文件中获取依赖项并将它们安装到子文件夹中每次都在构建的工作目录中，即使文件已经存在于以前的构建中（即 TC 代理没有清理它们），afaik 你不能将它们安装在工作文件夹之外。
我可能是错的...或者我应该说我希望我是错的，并且正在寻找一种方法 gulp 来支持它，但是我们使它起作用的任何方法都需要起作用使用任务 运行ner explorer，因此开发人员的 F5 体验在他们的本地仍然相同。
是的，我们确实有多个代理。
我不知道 Node.js，但这里有一些针对 TeamCity 的建议：
- NPM 是否可能将文件下载到
%TEMP%？如果是这样，它们将无法在后续的 TeamCity 构建之间重复使用，因为 TeamCity 代理会劫持 %TEMP% 目录（将其重定向到 <TeamCity Home>/buildAgent/temp/buildTmp）并始终在每次新构建之前完全擦除该目录。 （参见 buildTmp here。）
- 从这个意义上说，如果您可以指示 NPM 将下载的文件存储在 workspace（您检查构建的目录）中，那将是更好的选择相反。
- 如果 NPM 是 下载到作品 space（结帐目录），您是否可能要求对每个 运行 进行干净的结帐？ （请参阅编辑配置设置 | 版本控制设置 | 显示高级选项 | 清理build 复选框之前结帐目录中的所有文件。）
- 在这种情况下，请取消选中该复选框。
- TeamCity 是否可能由于磁盘空间不足 space 而正在清理结帐目录？当 TeamCity 注意到它 运行 正在退出 space 时，此清理会自动启动。 （使用 可用磁盘 space 构建功能可以使清理工作更加积极。）
- 在这种情况下，请停止使用构建功能。如果它没有被使用，而自动清理是罪魁祸首，那就很难控制了。最好只是清理文件系统中不受 TeamCity 管理的那部分（您自己的
%TEMP% 和其他地方），从而给 TeamCity 一些回旋余地。
- 您的构建 运行每次都在不同的代理上吗？ （查阅构建历史。）如果是这样，它就不能重用下载的工件（即使它们被下载到结帐目录中），因为它们每次都被下载到不同机器的文件系统。不过，我怀疑情况是否如此，因为 TeamCity 倾向于代理工作 space 重用（坚持使用同一个代理）。
- 在这种情况下，您可以通过设置代理要求强制代理重用，指定您希望构建始终在一个特定代理上 运行。您还可以将该代理单独放入其自己的池中，这样其他构建就无法在其上 运行。
我发现解决此问题的最佳方法是 backup/restore 节点模块文件夹，我在这里写了一篇博客 post 关于它
https://beerandserversdontmix.com/2016/06/04/teamcity-and-avoiding-redownloading-of-npm-packages/
如果您没有使用 "loose" 软件包版本，这可能是您的问题。您可以指定诸如 npm install angular-cli@0.1.0.0-beta.10 之类的内容，但是您会一直停留在旧版本上，如果您的开发人员经常更改他们针对您构建的内容，那么您的构建系统将会发生变动。
在您的 packages.json 中，您可以使用 * 和 ~ 来定义通配符版本，例如 3.* 或 ~2.5，这将使您获得 3.x 的任何 "minor" 修订版，例如 3.0 .2 或 3.0.99，2.5 类似，可以安装 2.5.x 的任何版本，但不能安装 2.6.0.
对于同样为此苦苦挣扎的人。其他原因可能是在切换分支时清理目录。
项目设置 -> 版本控制设置 -> VCS 根设置（编辑）
TeamCity 默认设置是在分支更改时清除所有未跟踪的文件（甚至忽略的文件），这会导致 node_modules 在每次分支更改时被删除。
将此设置更改为“所有 non-ignored 个未跟踪的文件”应该会有所帮助。
当谈到 nodejs npm 时，我有点 n00b，但是自从使用几篇文章中推荐的步骤在我们的构建环境中实现它后，我们的构建时间增加了两倍。
我们将其用于标准内容 (minify/concat/etc js/css/etc)
我们使用 TeamCity 并添加了一个 Node.js NPM 步骤，然后添加了一个 gulp 步骤到 运行 任务（回复：https://github.com/jonnyzzz/TeamCity.Node）
设置 NPM 的任务花费的时间最多，为 2 分 10 秒，超过调用命令 "npm install" 的总构建时间的 65%，这似乎是在每次构建时重新下载所有包
Step 3/7: NPM Setup (Node.js NPM) (2m:10s)
[npm install] Starting: cmd /c npm install
之前的总构建时间约为 1 分 30 秒，包括单元测试。
有没有办法在本地缓存这些并防止在每次构建时重新下载？在用户配置文件或其他可能与构建文件夹相反的地方？
更多详情..
这可能最能说明设置 http://www.dotnetcurry.com/visualstudio/1096/using-grunt-gulp-bower-visual-studio-2013-2015
我们有使用新的 Task Runner Explorer 的 C# 项目，依赖项被保存到 package.json 中，您在本地环境中预 运行 "npm install" 一次你的工作区（需要使用 .tfignore 来防止它签入源代码）然后就不会了，除非你启动一个新的本地工作区。
当构建 运行 时，它需要从命令行 运行 "npm install" 并从 package.json 文件中获取依赖项并将它们安装到子文件夹中每次都在构建的工作目录中，即使文件已经存在于以前的构建中（即 TC 代理没有清理它们），afaik 你不能将它们安装在工作文件夹之外。
我可能是错的...或者我应该说我希望我是错的，并且正在寻找一种方法 gulp 来支持它，但是我们使它起作用的任何方法都需要起作用使用任务 运行ner explorer，因此开发人员的 F5 体验在他们的本地仍然相同。
是的，我们确实有多个代理。
我不知道 Node.js，但这里有一些针对 TeamCity 的建议：
- NPM 是否可能将文件下载到
%TEMP%？如果是这样，它们将无法在后续的 TeamCity 构建之间重复使用，因为 TeamCity 代理会劫持%TEMP%目录（将其重定向到<TeamCity Home>/buildAgent/temp/buildTmp）并始终在每次新构建之前完全擦除该目录。 （参见buildTmphere。）- 从这个意义上说，如果您可以指示 NPM 将下载的文件存储在 workspace（您检查构建的目录）中，那将是更好的选择相反。
- 如果 NPM 是 下载到作品 space（结帐目录），您是否可能要求对每个 运行 进行干净的结帐？ （请参阅编辑配置设置 | 版本控制设置 | 显示高级选项 | 清理build 复选框之前结帐目录中的所有文件。）
- 在这种情况下，请取消选中该复选框。
- TeamCity 是否可能由于磁盘空间不足 space 而正在清理结帐目录？当 TeamCity 注意到它 运行 正在退出 space 时，此清理会自动启动。 （使用 可用磁盘 space 构建功能可以使清理工作更加积极。）
- 在这种情况下，请停止使用构建功能。如果它没有被使用，而自动清理是罪魁祸首，那就很难控制了。最好只是清理文件系统中不受 TeamCity 管理的那部分（您自己的
%TEMP%和其他地方），从而给 TeamCity 一些回旋余地。
- 在这种情况下，请停止使用构建功能。如果它没有被使用，而自动清理是罪魁祸首，那就很难控制了。最好只是清理文件系统中不受 TeamCity 管理的那部分（您自己的
- 您的构建 运行每次都在不同的代理上吗？ （查阅构建历史。）如果是这样，它就不能重用下载的工件（即使它们被下载到结帐目录中），因为它们每次都被下载到不同机器的文件系统。不过，我怀疑情况是否如此，因为 TeamCity 倾向于代理工作 space 重用（坚持使用同一个代理）。
- 在这种情况下，您可以通过设置代理要求强制代理重用，指定您希望构建始终在一个特定代理上 运行。您还可以将该代理单独放入其自己的池中，这样其他构建就无法在其上 运行。
我发现解决此问题的最佳方法是 backup/restore 节点模块文件夹，我在这里写了一篇博客 post 关于它
https://beerandserversdontmix.com/2016/06/04/teamcity-and-avoiding-redownloading-of-npm-packages/
如果您没有使用 "loose" 软件包版本，这可能是您的问题。您可以指定诸如 npm install angular-cli@0.1.0.0-beta.10 之类的内容，但是您会一直停留在旧版本上，如果您的开发人员经常更改他们针对您构建的内容，那么您的构建系统将会发生变动。
在您的 packages.json 中，您可以使用 * 和 ~ 来定义通配符版本，例如 3.* 或 ~2.5，这将使您获得 3.x 的任何 "minor" 修订版，例如 3.0 .2 或 3.0.99，2.5 类似，可以安装 2.5.x 的任何版本，但不能安装 2.6.0.
对于同样为此苦苦挣扎的人。其他原因可能是在切换分支时清理目录。
项目设置 -> 版本控制设置 -> VCS 根设置（编辑）
TeamCity 默认设置是在分支更改时清除所有未跟踪的文件（甚至忽略的文件），这会导致 node_modules 在每次分支更改时被删除。
将此设置更改为“所有 non-ignored 个未跟踪的文件”应该会有所帮助。