Nodejs npm шаг загружает пакеты при каждой сборке в TeamCity

Я немного n00b, когда дело доходит до nodejs npm, но после его внедрения в нашей среде сборки с использованием шагов, рекомендованных в нескольких статьях, утроилось наше время сборки.

Мы используем его для стандартных материалов (minify/concat/etc js/css/etc)

Мы используем TeamCity и добавили шаг Node.js NPM, затем шаг gulp для выполнения задач (RE: https://github.com/jonnyzzz/TeamCity.Node)

Задача по настройке NPM занимает больше времени, 2 мин. 10 секунд, что составляет более 65% от общего времени сборки, вызывающего команду "npm install" , которая, как представляется, повторно загружает все пакеты в каждой сборке

Шаг 3/7: Настройка NPM (Node.js NPM) (2 м: 10 с)

[npm install] Запуск: cmd/c npm install

Общее время сборки до было около 1 мин 30 сек, включая модульные тесты.

так или иначе, нужно кэшировать эти локальные файлы и предотвращать повторную загрузку в каждой сборке? в профиле пользователя или что-то, возможно, в отличие от папки сборки?

Подробнее..

Это, вероятно, лучше всего объясняет настройку http://www.dotnetcurry.com/visualstudio/1096/using-grunt-gulp-bower-visual-studio-2013-2015

У нас есть проекты С#, которые используют новый проводник запуска задач, Зависимости сохраняются в package.json, вы предварительно запускаете "npm install" один раз в своей локальной среде в вашей рабочей области (нужно использовать .tfignore для предотвращения его проверки в исходный код), а затем снова, если вы не запустите новое локальное рабочее пространство.

При запуске сборки ему нужно запустить "npm install" из командной строки, и он забирает зависимости из файла package.json и каждый раз устанавливает их в подпапку внутри рабочего каталога сборки, даже если файлы уже есть из предыдущей сборки (т.е. агент TC не очистил их), afaik вы не можете установить их за пределы рабочей папки.

Я мог ошибаться... Или я должен сказать, что надеюсь, что ошибаюсь, и ищу способ для gulp, чтобы поддержать это, но каким бы способом мы его работаем, не нужно работать с проводником задач runner поэтому опыт F5 для разработчика все тот же на локальном.

У нас есть несколько агентов да.

Ответ 1

Лучшим способом, который я нашел, чтобы исправить это, было резервное копирование/восстановление папки модулей node, я сделал сообщение в блоге об этом здесь

https://beerandserversdontmix.com/2016/06/04/teamcity-and-avoiding-redownloading-of-npm-packages/

Ответ 2

Я не знаю о Node.js, но вот несколько советов TeamCity:

Может ли NPM загружать файлы в %TEMP%? Если это так, они не будут повторно использоваться между последующими сборками TeamCity, потому что агент TeamCity захватывает каталог %TEMP% (перенаправляет его на <TeamCity Home>/buildAgent/temp/buildTmp) и всегда полностью стирает этот каталог перед каждой новой сборкой. (См. buildTmp здесь.)
- В этом смысле было бы предпочтительнее, если бы вы могли научить NPM хранить загруженные файлы в рабочей области (каталог, где вы проверяете свою сборку).
Если NPM загружается в рабочую область (контрольный каталог), возможно, вы попросили выполнить чистую проверку при каждом запуске? (См. "Редактирование настроек конфигурации" | "Параметры контроля версий" | Показать расширенные параметры | Очистить все файлы в каталоге проверки до сборки.)
- В этом случае снимите флажок.
Возможно ли, что TeamCity очистит каталог выписки из-за небольшого дискового пространства? Эта очистка запускается автоматически, когда TeamCity замечает, что у нее заканчивается пространство. (Очистка может быть еще более агрессивной благодаря функции создания свободного места на диске).
- В этом случае прекратите использование функции сборки. Если он не используется и автоматическая очистка виновата, его трудно контролировать. Лучше всего, если вы просто очистите ту часть файловой системы, которая не управляется TeamCity (ваш собственный %TEMP% и другие места) и, таким образом, дает некоторую свободу действий TeamCity.
Разве ваша сборка работает на другом агенте каждый раз? (Обратитесь к истории сборки.) Если это так, он не может повторно использовать загруженные артефакты (даже если они загружаются в каталог проверки), так как они загружаются в другую компьютерную файловую систему каждый раз. Я сомневаюсь, что это так, потому что TeamCity тяготеет к повторному использованию агента-рабочей области (придерживаясь того же агента).
- В этом случае вы можете принудительно повторно использовать агент, задав требование агента, указав, что вы хотите, чтобы ваши сборки работали на одном конкретном агенте все время. Вы также можете выделить этот агент в свой собственный пул, чтобы на нем не могли работать никакие другие сборки.

Ответ 3

Если вы не используете "свободные" версии пакетов, это может быть вашей проблемой. Вы можете указать что-то вроде npm install [email protected], но тогда вы застряли в старой версии все время, и если ваши разработчики часто меняют то, что они создают против вас, у вас будет сбои в вашей системе сборки.

В your packages.json вы можете использовать * и ~ для определения подстановочных версий, например 3. * или ~ 2.5, которые позволят вам получить любую "небольшую" версию 3.x, например 3.0.2 или 3.0.99, и 2.5 будет что-то подобное, любая версия 2.5.x может быть установлена, но не 2.6.0.