Karma Chrome Headless не работает на Jenkins

Ответ 1

Проблема заключалась в xbmc дисплея jenkin xbmc.

Я исправил его, переключившись на Travic-CI

before_install: - export DISPLAY=:99.0 - sh -e /etc/init.d/xvfb start - sleep 3

Ответ 2

Основываясь на выпуске Karma 1.6 Breaks Поддержка Chrome для Chrome, созданная на github, связана с более медленной машиной и происходит, потому что потребовалось> 60 секунд до того, как тестовый комплект был разобран и выполнен Chrome, и поэтому был запущен пробный запуск и передан обратно в Karma сервер. Причины, по которым это может занять много времени.

Существует два способа обработки тайм-аута:

Изучите, почему ваш тестовый комплект нагрузок> 60 секунд и убедитесь, что он загружается быстрее.

1. Увеличьте значение browserNoActivityTimeout до максимального значения, поэтому тестовый комплект имеет достаточно времени для загрузки.
2. Этот вид тайм-аута, похоже, не является проблемой кармы, а скорее проблемой в проекте или неправильной конфигурацией.

Основываясь на комментарии Дерека

Была связь, которая слишком рано отключилась.

Он обнаружил, что в /static/karma.js, когда сокет был создан, было значение тайм-аута, жестко запрограммированное на 2 секунды (см. Ниже). Он добавил еще 0, чтобы сделать это 20 секунд, и соединение оставалось открытым достаточно долго, чтобы сервер мог ответить на первоначальный запрос. карма/клиент/main.js

Строки с 14 по 20 в e79463b

var socket = io(location.host, { 
   reconnectionDelay: 500, 
   reconnectionDelayMax: Infinity, 
   timeout: 2000, 
   path: KARMA_PROXY_PATH + KARMA_URL_ROOT.substr(1) + 'socket.io', 
   'sync disconnect on unload': true 
 }) 

Следующая проблема, с которой он столкнулся, заключалась в том, что Карма считал, что нет активности, хотя в сокете происходит движение. Чтобы исправить это, он просто добавил браузерNoActivityTimeout: 60000 в конфигурацию Karma.

Вам нужно изменить конфигурацию тайм-аута больше, чем в файле конфигурации.

Ответ 3

имел ту же проблему: " ChromHeadless не захватили в 60000 мс " (неудача после 3 попыток), на Jenkins, работающем на RHEL 7.5. Пробовал несколько конфигураций и, в конечном итоге, добавлял список -proxy-bypass, и -proxy-server заставлял его работать.

минимальная рабочая конфигурация

 browsers: ['HeadlessChrome'],
    customLaunchers:{
      HeadlessChrome:{
        base: 'ChromeHeadless',
        flags: [
          '--no-sandbox',
          '--proxy-bypass-list=*',
          '--proxy-server=\'http://<my org proxy server>:8080\''
       ]
      }
    },

Ниже вы можете увидеть еще несколько параметров в конфиге, например, тот, который я использовал. У нас есть две конфигурации браузера: Chrome для повседневной работы Dev, где мы хотим видеть браузер открытым, и безголовый хром для тестов CI/CD при построении нашего решения на сервере Jenkins.

Командная строка для запуска в Jenkins:

npm run test -- -cc -sr --browser HeadlessChrome

В package.json мы добавили пару строк в раздел сценариев:

 "test": "ng test",
    "test-dev": "ng test --browser Chrome",

karma.conf.js

 browsers: ['Chrome', 'HeadlessChrome'],
    customLaunchers:{
      HeadlessChrome:{
        base: 'ChromeHeadless',
        flags: [
          '--no-sandbox',
       //   '--remote-debugging-port=9222',
       //   '--enable-logging',
       //   '--user-data-dir=./karma-chrome',
       //   '--v=1',
       //   '--disable-background-timer-throttling',
       //   '--disable-renderer-backgrounding',
          '--proxy-bypass-list=*',
          '--proxy-server=\'http://<my org proxy server>:8080\''
       ]
      }
    },

После этих шагов он работал из оболочки на машине Дженкинса. Однако это не сработало при работе в качестве задания Jenkins. Не удается запустить ChromeHeadless. Попробуйте снова запустить ChromeHeadless (1/2). напечатан на консоли.

Я сравнивал переменные env и после нескольких проб и ошибок обнаружил, что переменная среды XDG_DATA_DIRS существует при регистрации в оболочке bash (где успешно выполняются тесты без головок chrome), и эта переменная не была определена в случае неудачной работы Jenkins. Поэтому его добавление (скопированное из оболочки env | grep XDG_DATA_DIRS) окончательно разрешило его. Думаю, я должен проверить, что такое минимальная конфигурация /dirs, которую я должен поставить там, и что является основной причиной, но теперь она работает :-)

Добавлено ниже для работы jenkins непосредственно перед запуском теста

export XDG_DATA_DIRS=/users/<jenkins user e.g. jk1003>/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/

Другое возможное решение

Друг сказал мне, что он давно решил такую проблему, используя Xvfb

Ответ 4

Для меня я должен добавить chrome local ip/port явно к NO_PROXY чтобы Karma могла захватывать браузер.

В karma.conf.js:

process.env.NO_PROXY = 'localhost, 0.0.0.0/4201, 0.0.0.0/9876';
process.env.no_proxy = 'localhost, 0.0.0.0/4201, 0.0.0.0/9876';

Обратите внимание, что даже я экспортирую его в наш jenkinsfile, он не работает, должен быть в процессе js.