Hemos estado recabado por el mundo on line y así mostrarte la solución a tu duda, en caso de alguna inquietud puedes dejarnos tu inquietud y contestaremos sin falta, porque estamos para servirte.
Solución:
Basado en el problema, Karma 1.6 rompe el soporte Headless para Chrome creado en github, está relacionado con la máquina más lenta y sucede, porque pasaron más de 60 segundos antes de que Chrome analizara y ejecutara el paquete de prueba y, por lo tanto, la ejecución de prueba se inició y se comunicó a Karma servidor. Las razones por las que puede llevar mucho tiempo varían.
Hay 2 formas de gestionar el tiempo de espera:
Investigue por qué su paquete de prueba se carga> 60 segundos y asegúrese de que se cargue más rápido.
- Aumente el valor de browserNoActivityTimeout a un valor más alto, para que el paquete de prueba tenga tiempo suficiente para cargarse.
- Esta apariencia particular de tiempo de espera no parece ser un problema de Karma, sino un problema en el proyecto o una mala configuración.
Basado en el comentario de Derek
Había una conexión que se estaba desconectando demasiado pronto.
Encontró eso en /static/karma.js, cuando se creó el socket, había un valor de tiempo de espera que está codificado en 2 segundos (ver más abajo). Simplemente agregó otro 0 para que sean 20 segundos y la conexión permaneció abierta el tiempo suficiente para que el servidor respondiera a la solicitud inicial. karma / client / main.js
Líneas 14 a 20 en 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
)
El siguiente problema que enfrentó fue que Karma pensó que no había actividad a pesar de que había tráfico yendo y viniendo en el enchufe. Para solucionarlo, acaba de agregar browserNoActivityTimeout: 60000 a la configuración de Karma.
Necesita cambiar la configuración del tiempo de espera más de lo que está en el archivo de configuración.
tenía el mismo problema “ChromHeadless no ha capturado en 60000 ms“(falla después de 3 intentos), en Jenkins que se ejecuta en RHEL 7.5. Probé varias configuraciones y, finalmente, agregué el –proxy-bypass-list, y –servidor proxy lo hizo funcionar.
configuración de trabajo mínima
browsers: ['HeadlessChrome'],
customLaunchers:
HeadlessChrome:
base: 'ChromeHeadless',
flags: [
'--no-sandbox',
'--proxy-bypass-list=*',
'--proxy-server='http://:8080''
]
,
A continuación puede ver algunas opciones más en la configuración como la que usé. Tenemos dos configuraciones de navegador, Chrome para el trabajo de desarrollo diario en el que queremos ver el navegador abierto y un Chrome sin cabeza para las pruebas de CI / CD cuando construimos nuestra solución en un servidor Jenkins.
Línea de comando para ejecutarlo en Jenkins:
npm run test -- -cc -sr --browser HeadlessChrome
En package.json agregamos un par de líneas al guiones sección:
"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://:8080''
]
,
Después de los pasos anteriores, funcionó desde un shell en la máquina Jenkins. Sin embargo, falló al ejecutarse como un trabajo de Jenkins con No se puede iniciar ChromeHeadless Intentando iniciar ChromeHeadless nuevamente (1/2). impreso en la consola.
Comparé las variables env, y después de algunas pruebas y errores encontré que XDG_DATA_DIRS La variable de entorno existe cuando se registra en un shell bash (donde las pruebas de Chrome sin cabeza tienen éxito), y esta variable no se definió en el entorno de trabajo fallido de Jenkins. Entonces agregándolo (copiado del shell env | grep XDG_DATA_DIRS) finalmente lo resolvió. Supongo que debería comprobar cuál es la configuración mínima / directorios que debería poner allí, y cuál es la causa raíz, pero está funcionando ahora 🙂
Se agregó lo siguiente al trabajo de jenkins justo antes de ejecutar la prueba
export XDG_DATA_DIRS=/users//.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/
Otra posible solucion
Un amigo me dijo que resolvió ese problema hace mucho tiempo usando Xvfb
Para mí, tengo que agregar la ip / puerto local de Chrome explícitamente a NO_PROXY de modo que Karma podría capturar el navegador.
En el 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';
Tenga en cuenta que incluso yo lo exporto en nuestro jenkinsfile, no funciona, tiene que estar en el proceso js.
Comentarios y puntuaciones del artículo
Recuerda que tienes permiso de parafrasear tu experiencia si te ayudó.