TFS Build не может найти Grunt
Я установил npm и grunt на наш сервер сборки TFS. Я установил grunt-cli с помощью npm install -g grunt-cli и затем смог запустить grunt deploy из командной строки, когда вошел в систему под своим именем.
Однако наши сборки TFS запускаются от имени пользователя tfsservice, и когда он пытается выполнить развертывание grunt, он получает сообщение об ошибке:
'grunt' is not recognized as an internal or external command, operable program or batch file.
Таким образом, при входе в систему под своим именем на сервере сборки, если я запускаю командную строку как tfsservice, я получаю ту же ошибку. Поэтому я попытался выполнить команду npm install -g grunt-cli из этой командной строки, и она выглядела правильно установленной и создала файлы grunt в C:\Users\tfsservice\AppData\Roaming\npm, но затем я все еще получаю ту же ошибку при запуске ворчать развернуть.
Похоже, grunt-cli не устанавливается для tfsservice? Когда я получаю tfsservice %homepath%, я вижу, что он имеет значение \ Windows \ system32, а не ожидаемый \ Users \ tfsservice; может быть, это учетная запись службы как-то связана с этим?
Я вижу, что аналогичные вопросы задавались для использования grunt-cli с Team City, но он рекомендует использовать специальный плагин для Team City.
Также есть этот пост, в котором говорится, что они сменили Team City на другого пользователя, а затем все стало работать правильно. Изменение моих сборок для запуска от имени другого пользователя, чем tfsservice, на самом деле не вариант для меня.
Любые предложения приветствуются. Благодарю.
3 ответа
После входа в систему как 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 в системный путь; Возможно, вам удастся избежать создания новой переменной Path только для переменных пользователя tfsservice, но я хотел, чтобы она работала, когда вы вошли в систему как другие пользователи.
Как только я это сделал, grunt deploy работало, когда я вошел в систему вручную как tfsservice и открыл новую командную строку, но все равно не работал, когда фактическая сборка TFS выполняла сборку как tfsservice. Сначала я просто изменил свой процесс сборки для вызова grunt.cmd из командной строки, используя его полный путь, например, так:
"C:\Users\tfsservice\AppData\Roaming\npm\grunt.cmd" deploy
и убедился, что я запустил npm install -g grunt- cli в качестве tfsservice на всех моих машинах сборки, чтобы убедиться, что grunt существует в каталоге AppData пользователя tfsservice на каждом сервере сборки. Это сработало, но было скорее обходным путем, чем исправлением.
Оказывается, последний шаг - перезагрузить сервер сборки TFS. Как только я сделал это, grunt deploy работало, как и ожидалось, для сборок, поэтому мне больше не нужно было указывать полный путь:) Простого перезапуска tfsservice могло бы быть достаточно, но я просто перезагрузил компьютер, чтобы быть в безопасности.
Мы столкнулись с той же проблемой, и мы сделали следующее:
Прежде всего, мы установили на нашего системного пользователя каждое программное обеспечение, которое также используется для сборки.
Чтобы выяснить, какой пользователь будет использоваться, мы добавили пакетный файл с echo %username% и добавили задачу "Batch Script" в процесс сборки, и позволили этой задаче выполнить наш сценарий.
Таким образом, мы можем установить все необходимое Программное обеспечение на 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 и мог представить, что это все та же проблема, поэтому мы могли запускать этот скрипт перед каждой сборкой. Но это выглядит немного хакерским для моего мнения.
Спасибо ребята за хорошие посты.
Я также испытал эту неудачу. Добавление папки npm к глобальному пути и перезагрузка сервера исправили это.