Тестирование с Node.js и io.js

  1. Быстрый старт Поместите этот простой appveyor.yml в корень вашего репозитория, и он должен работать...
  2. Выбор версии Node.js или io.js
  3. Как это работает
  4. Установка любой версии Node.js или io.js
  5. Тестирование под несколькими версиями Node.js или io.js
  6. Развертывание веб-сайта Node.js в Azure
  7. Известные вопросы
  8. Искаженный или отсутствующий вывод
  9. Ошибки блокировки (EPERM, EEXIST, tgz.lock)
  10. Неожиданные сообщения об ошибках при успешном запуске

Быстрый старт

Поместите этот простой appveyor.yml в корень вашего репозитория, и он должен работать для большинства проектов Node.js:

# Тестировать последнюю версию этой среды Node.js: nodejs_version: "6" # Установить сценарии. (запускается после клонирования репозитория) install: # Получить последнюю стабильную версию Node.js или io.js - ps: узел Install-Product $ env: nodejs_version # install modules - npm install # Постустановочные сценарии тестирования. test_script: # Вывести полезную информацию для отладки. - node --version - npm --version # запустить тесты - npm test # На самом деле не собирать. build: off

Концы строк

По умолчанию Git на рабочих сборках конфигурируется с помощью git config --global core.autocrlf, что означает, что ваше хранилище клонировано «как есть» без исправления новых строк в Windows. Если у вас есть файл со строкой abc \ n line2, он будет извлечен точно так же, как abc \ n line2, и если в репо есть line1 \ r \ n line2, вы получите то же самое при оформлении заказа. Смотрите этот так ответ, объясняя в деталях режимы core.autocrlf ,

Однако, если вы ожидаете, что Git исправит окончания строк в Windows и извлечет все строки с помощью \ r \ n, вы можете указать Git сделать это на этапе инициализации вашей сборки, который происходит перед командой клонирования:

init: - git config --global core.autocrlf true

Мы не рекомендуем полагаться на значение core.autocrlf, установленное на рабочих сборках AppVeyor, и всегда явно меняем этот параметр во время сборки или это настроено для каждого хранилища ,

Выбор версии Node.js или io.js

Работники сборки предварительно установили самые последние версии Node.js и io.js - как x86, так и x64. Если вы ничего не сделаете, ваши скрипты будут работать под Node.js 4.7.x (x86) (на момент написания).

Чтобы переключиться на другую версию Node.js или io.js, используйте следующую команду PowerShell:

Узел Install-Product <версия> [x86 | x64]

<version> можно указать как MAJOR для установки абсолютной последней версии Node.js или io.js, MAJOR.MINOR для установки последней версии Node.js или io.js или MAJOR.MINOR.BUILD для установки конкретной сборки. Когда MAJOR часть <version> равна 1, тогда устанавливается io.js.

Например, чтобы переключить среду выполнения на последнюю версию Node.js, используйте эту команду (на момент написания статьи это самая последняя ветка 7.x):

Чтобы переключить Node.js на последнюю доступную ветку 6.x, используйте:

Чтобы выбрать конкретную версию Node 6.9.3 для x64:

Узел Install-Product 6.9.3 x64

Любая версия 1.x автоматически предполагает, что вам нужен io.js, поэтому для переключения на последнюю версию io.js используйте эту команду:

В appveyor.yml вы должны поставить перед командой команду ps, чтобы сообщить AppVeyor, что это PowerShell:

установить: - ps: узел 1 продукта установки

Как это работает

Предустановленные дистрибутивы Node.js хранятся в папке C: \ avvm \ node. Когда вы запускаете команду узла Install-Product, это, по сути, перемещение папки nodejs или iojs оттуда в Program Files, поэтому переключение происходит очень быстро. Чтобы проверить, какие версии доступны на сборщике, вы можете сделать dir C: \ avvm \ node.

Следующие пути всегда добавляются в переменную среды PATH:

C: \ Program Files (x86) \ nodejs C: \ Program Files (x86) \ iojs C: \ Program Files \ nodejs C: \ Program Files \ iojs C: \ Users \ appveyor \ AppData \ Roaming \ npm

Установка любой версии Node.js или io.js

Иногда предустановленные версии Node.js или io.js немного отстают (это особенно актуально для io.js), но что делать, если вам нужно тестировать в самом переднем крае. Вы можете использовать другой командлет PowerShell, который выполняет полную переустановку Node.js или io.js для выбранной версии.

Update-NodeJsInstallation <версия> [x86 | x64]

Здесь <версия> является точной версией Node.js или io.js.

Например, следующая команда загрузит и установит Node.js 5.12.0:

Update-NodeJsInstallation 5.12.0

Существует вспомогательный командлет, проверяющий удаленный каталог dist Node.js или io.js, чтобы определить абсолютную последнюю доступную сборку:

Get-NodeJsLatestBuild <major>. <Minor>

Его можно использовать вместе с предыдущим командлетом, чтобы всегда устанавливать последнюю сборку, например:

Update-NodeJsInstallation (Get-NodeJsLatestBuild 1.0)

Тестирование под несколькими версиями Node.js или io.js

AppVeyor позволяет легко тестировать различные комбинации платформ, конфигураций и сред с построить матрицу ,

Чтобы протестировать последнюю версию Node.js и io.js, вы можете указать в appveyor.yml:

среда: матрица: # node.js - nodejs_version: "4" - nodejs_version: "6" # io.js - nodejs_version: "1.0" install: - ps: узел продукта установки $ env: nodejs_version

Чтобы разрешить сбой заданий для передовых версий Node.js:

матрица: allow_failures: - nodejs_version: "7"

Что если вам нужно протестировать под определенной версией Node.js для платформ x86 и x64? Вы можете добавить другое «измерение» в матрицу, например:

среда: матрица: - nodejs_version: "4" - nodejs_version: "6" платформа: - x86 - x64 установка: - ps: узел продукта установки $ env: nodejs_version $ env: платформа

Эта конфигурация создаст сборку с 4 заданиями для всех комбинаций версии узла и платформы:

Node.js 4.x x86 Node.js 4.x x64 Node.js 6.x x86 Node.js 6.x x64

Развертывание веб-сайта Node.js в Azure

Вы можете использовать Web Deploy для разверните свой сайт Node.js на Лазурный.

Для публикации пакетов в реестре NPM во время сборки клиент npm должен пройти аутентификацию. На компьютере разработчика вы запускаете команду npm adduser для установки учетных данных npm.

В сборщике AppVeyor вам не нужно запускать npm adduser, но вы можете просто переместить npm authToken с локального компьютера на виртуальную машину сборки. Это то, что вы должны сделать:

  1. Сделайте npm adduser на вашей локальной машине разработчика.
  2. Скопируйте значение authToken из% userprofile% \. Npmrc на свой локальный компьютер.
  3. В AppVeyor на вкладке «Среда» параметров проекта добавьте новую переменную среды с именем npm_auth_token и скопируйте значение на шаге 2. Нажмите значок «Блокировка», чтобы пометить переменную как «безопасную» (чтобы она не была доступна для сборок PR) ,
  4. Добавьте к вашему appveyor.yml:

установить: - ps: '"//registry.npmjs.org/:_authToken=$env:npm_auth_token`n" | out-файл "$ env: userprofile \ .npmrc" -Кодирование ASCII '- npm whoami

npm whoami должно отобразить ваше имя пользователя.

Известные вопросы

Неправильная кодировка вывода

При запуске npm install (или любой другой программы Node.js, пишущей на консоль), вы можете заметить, что символы Unicode, написанные для построения консоли, выглядят неправильно:

Это потому, что вы вызываете эту программу из PowerShell:

Чтобы исправить это, запустите его в режиме «оболочки»:

Чтобы исправить это, запустите его в режиме «оболочки»:

На данный момент, похоже, проблема с PowerShell и способом перенаправления вывода из консольных приложений на пользовательский хост PowerShell.

Искаженный или отсутствующий вывод

Иногда вы можете заметить, что вывод некоторых программ Node.js (особенно тех, которые активно пишут в StdOut и StdErr) искажен или отсутствует.

В двух словах была специфичная для Windows проблема в Node.js с неблокирующим StdErr ( Joyent / узел # 3584 ) который был исправлен в этом запросе Joyent / узел # 7196 и наконец приземлился в Node.js v0.11.12 ( Joyent / узел @ 20176a9 ). Eсть отличное обсуждение этой проблемы ,

Решение - запустите ваши тесты под последним Node.js.

Ошибки блокировки (EPERM, EEXIST, tgz.lock)

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

нпм ERR! Ошибка: EPERM, откройте 'C: \ Users \ appveyor \ AppData \ Roaming \ npm-cache {кое-что} -package-tgz.lock' npm ERR! EEXIST, откройте '{some-path} \ npm-cache {кое-что} -package-tgz.lock'

По умолчанию Node.js поставляется с предустановленным npm версии 1.x. Тем не менее, большинство этих «гоночных условий» были исправлены в npm 2.0.

Решение - установить npm 2.0:

npm -g установить npm @ 2 установить PATH =% APPDATA% \ npm;% PATH%

Подробнее о Решение проблем с npm в Windows ,

Неожиданные сообщения об ошибках при успешном запуске

Иногда команды / задачи npm будут отображать ошибки в журнале сборки, но сборка будет успешной, как если бы ее не было. Это может произойти с npm ci, где все пакеты разрешены и установлены, но может отобразиться ошибка, указывающая на сценарий сборки.

Это потому, что вы вызываете скрипт из PowerShell:

Чтобы исправить это, запустите его в режиме «shell»:

- powershell ./build.ps1 - cmd: powershell ./build.ps1

Обратите внимание, что это может произойти даже при вызове npm из других инструментов сборки, таких как Кекс и Cake.Npm добавить в.

Js для платформ x86 и x64?