Contribución a uvlhub - Daniel Galván - Historial de revisiones

Dangalcan en 20:41 4 feb 2025

2025-02-04T20:41:40Z

Dangalcan en 20:40 4 feb 2025

2025-02-04T20:40:52Z

Dangalcan en 20:40 4 feb 2025

2025-02-04T20:40:09Z

Dangalcan en 20:39 4 feb 2025

2025-02-04T20:39:32Z

Dangalcan en 20:37 4 feb 2025

2025-02-04T20:37:30Z

Dangalcan en 20:36 4 feb 2025

2025-02-04T20:36:16Z

Dangalcan en 20:34 4 feb 2025

2025-02-04T20:34:23Z

Dangalcan en 20:33 4 feb 2025

2025-02-04T20:33:27Z

Dangalcan: Página creada con «* Página_Principal -> [[Salón_de_la_fama_de_EGC] ] =Resumen= Resumen de unas 500/600 palabras del proyecto. =Resultados obtenidos= [Enlace a github con lo que...»

2025-02-04T20:32:44Z

Página creada con «* Página_Principal -> [[Salón_de_la_fama_de_EGC] ] =Resumen= Resumen de unas 500/600 palabras del proyecto. =Resultados obtenidos= [Enlace a github con lo que...»

Página nueva

* [[Página_Principal]] -> [[Salón_de_la_fama_de_EGC] ]

=Resumen=

Resumen de unas 500/600 palabras del proyecto.

=Resultados obtenidos=

[Enlace a github con lo que se entrega (si son vídeos o documentos, tmb)]

=Tareas realizadas=

En esta sección se describe todo lo que se ha hecho para completar el trabajo. Es recomendable añadir enlaces a cualquier elemento que se haya generado en el proceso de realización del trabajo. (links a videos, presentaciones, repositorios de código, etc).

=Obstáculos=

En esta sección se describen todos los problemas que hayan sucedido a lo largo del trabajo así como sus soluciones. También pueden incluirse los cambios o dificultades que hayan puesto en peligro la finalización del trabajo.

=Conclusiones y posibles trabajos futuros=

Conclusiones a las que se ha llegado y posibles extensiones o trabajos futuros

@@ Línea 10: / Línea 10: @@
 . En el comando del CLI mencionado con anterioridad, debe haber una opción que permita escoger driver. Si no se escoge ninguno, se utiliza el driver del navegador firefox. En caso contrario, solo se dispondrá de la opción “chrome”.
 =Resultados obtenidos=
@@ Línea 24: / Línea 23: @@
 Enlace al proyecto de github: https://github.com/Dangalcan/uvlhub
 Enlace al video explicativo: https://youtu.be/KSV1k8lpERM
 =Tareas realizadas=
@@ Línea 37: / Línea 35: @@
 Para añadir la opción de escoger el driver, lo que hice fue realizar una variable de entorno que por defecto siempre vale “firefox” pero que con rosemary selenium podemos hacer que valga “chrome”. El valor de la variable indica el driver que debe seleccionar uvlhub. Esta opción permite que podamos seleccionar el navegador deseado a nuestro antojo, sin necesidad de preocuparnos por incompatibilidades. En docker la implementación es simétrica sólo que se escoge el driver remoto.
 ==Corregir tests==
 Realmente no me lo pidieron pero arreglé 2 tests porque había un par de erratas.
 ==Video explicativo==
 Aunque tampoco se pidió, realicé un video mostrando el funcionamiento y la implementación donde se habla lo mismo que en este documento: https://youtu.be/KSV1k8lpERM
 =Obstáculos=

@@ Línea 34: / Línea 34: @@
 Para completar esta tarea se ha necesitado utilizar una herramienta externa. En este caso, Selenium-grid. Selenium-grid es una herramienta gratuita que nos permite lanzar pruebas de interfaz de selenium en contenedores de forma dinámica y estática. Para simplificar la situación y porque no estamos ante un conjunto de tests excesivamente grande, se ha implementado de forma estática. Selenium-grid consiste en crear una red de contenedores que serán gestionados con Selenium-hub (el contenedor padre). Para integrar la herramienta he añadido la imagen de Selenium-hub y las imágenes standalone de firefox y chrome. Estas versiones tienen la ventaja de ser ligeras, ya que tienen lo justo para correr el navegador, y el propio navegador en sí. Ambas imágenes crean 1 contenedor, al que llamaremos nodo. Cada nodo depende y es gestionado por Selenium-hub, que se encarga de distribuir la ejecución de los tests. La configuración de los nodos ha sido la recomendada, salvo por un aspecto importante, la variable VNC_NO_PASSWORD. Esta variable nos permitirá entrar a las sesiones de chrome y firefox en las que se ejecutan las pruebas para poder visualizarlas. Se pueden ejecutar en paralelo, pero como consume demasiados recursos he dejado la opción por defecto de 1 sesión. Al levantar el entorno docker, tendremos disponible selenium-hub en el puerto 4444 de nuestro localhost. Cuando ejecutemos pruebas de selenium con pytest o python, uvlhub detectará que estamos en docker observando la variable de entorno WORK_DIR. De esta forma, al inicializar el driver de selenium, uvlhub configurará un driver remoto, para que sea ejecutable por Selenium-hub. No obstante, aunque funcione no es del todo recomendable por el tema de las grabaciones de vídeo, de las cuales hablaremos a continuación. Cuando ejecutamos el comando “rosemary selenium” se comporta de forma parecida a ejecutar pytest solo que hace algo adicional, invocar al nodo de video del driver correspondiente. Esto es más por buena práctica que por necesidad. Funciona igualmente si no lo hiciera pero puede dar problemas en caso de que se quieran grabar vídeos. Esto es por alguna razón que a día de hoy desconozco pues no siempre aparece el mismo error y/o no siempre falla. Hasta donde he descubierto, a veces da fallo en los permisos, y otras da fallo en la comunicación entre nodos. Sea como fuere, tal cual está sigue las pocas recomendaciones que he podido encontrar y ejecuta las pruebas de forma correcta. En cuanto al video, como el hecho de mirar las sesiones en Selenium-hub puede ser tedioso al haber muchos tests ejecutándose muy rápido, he decidido añadir una opción para que se graben los tests. Esto se controla con la opción booleana  –video. Por defecto, es “false”. En caso de ser verdadera, grabarán las pruebas y se guardará el video en “/docker/tmp/videos”. Siempre se generarán 2, uno para firefox y otro para chrome. No obstante, sólo tendrá contenido el del navegador seleccionado (recordemos que por defecto es firefox). Estos videos pueden descargarse, pero no debemos eliminar esos archivos, puesto que en ese caso los nodos no tienen permiso para crearlos y salta un error. Nota: Para ejecutar la opción –video=true deberemos desplegar previamente en local los nodos de video usando docker-compose, de modo que puedan conectarse a los nodos de los navegadores.
-. Añadir opción de escoger el driver
+==Añadir opción de escoger el driver==
 Para añadir la opción de escoger el driver, lo que hice fue realizar una variable de entorno que por defecto siempre vale “firefox” pero que con rosemary selenium podemos hacer que valga “chrome”. El valor de la variable indica el driver que debe seleccionar uvlhub. Esta opción permite que podamos seleccionar el navegador deseado a nuestro antojo, sin necesidad de preocuparnos por incompatibilidades. En docker la implementación es simétrica sólo que se escoge el driver remoto.
-. Corregir tests
+==Corregir tests==
 Realmente no me lo pidieron pero arreglé 2 tests porque había un par de erratas.
-. Video explicativo
+==Video explicativo==
 Aunque tampoco se pidió, realicé un video mostrando el funcionamiento y la implementación donde se habla lo mismo que en este documento: https://youtu.be/KSV1k8lpERM

@@ Línea 30: / Línea 30: @@
 A continuación explicaremos qué se ha hecho y cómo. Adelantándonos un poco, se completaron ambas tareas.
-. Implementación de “rosemary selenium” en docker:
+==Implementación de “rosemary selenium” en docker==
 Para completar esta tarea se ha necesitado utilizar una herramienta externa. En este caso, Selenium-grid. Selenium-grid es una herramienta gratuita que nos permite lanzar pruebas de interfaz de selenium en contenedores de forma dinámica y estática. Para simplificar la situación y porque no estamos ante un conjunto de tests excesivamente grande, se ha implementado de forma estática. Selenium-grid consiste en crear una red de contenedores que serán gestionados con Selenium-hub (el contenedor padre). Para integrar la herramienta he añadido la imagen de Selenium-hub y las imágenes standalone de firefox y chrome. Estas versiones tienen la ventaja de ser ligeras, ya que tienen lo justo para correr el navegador, y el propio navegador en sí. Ambas imágenes crean 1 contenedor, al que llamaremos nodo. Cada nodo depende y es gestionado por Selenium-hub, que se encarga de distribuir la ejecución de los tests. La configuración de los nodos ha sido la recomendada, salvo por un aspecto importante, la variable VNC_NO_PASSWORD. Esta variable nos permitirá entrar a las sesiones de chrome y firefox en las que se ejecutan las pruebas para poder visualizarlas. Se pueden ejecutar en paralelo, pero como consume demasiados recursos he dejado la opción por defecto de 1 sesión. Al levantar el entorno docker, tendremos disponible selenium-hub en el puerto 4444 de nuestro localhost. Cuando ejecutemos pruebas de selenium con pytest o python, uvlhub detectará que estamos en docker observando la variable de entorno WORK_DIR. De esta forma, al inicializar el driver de selenium, uvlhub configurará un driver remoto, para que sea ejecutable por Selenium-hub. No obstante, aunque funcione no es del todo recomendable por el tema de las grabaciones de vídeo, de las cuales hablaremos a continuación. Cuando ejecutamos el comando “rosemary selenium” se comporta de forma parecida a ejecutar pytest solo que hace algo adicional, invocar al nodo de video del driver correspondiente. Esto es más por buena práctica que por necesidad. Funciona igualmente si no lo hiciera pero puede dar problemas en caso de que se quieran grabar vídeos. Esto es por alguna razón que a día de hoy desconozco pues no siempre aparece el mismo error y/o no siempre falla. Hasta donde he descubierto, a veces da fallo en los permisos, y otras da fallo en la comunicación entre nodos. Sea como fuere, tal cual está sigue las pocas recomendaciones que he podido encontrar y ejecuta las pruebas de forma correcta. En cuanto al video, como el hecho de mirar las sesiones en Selenium-hub puede ser tedioso al haber muchos tests ejecutándose muy rápido, he decidido añadir una opción para que se graben los tests. Esto se controla con la opción booleana  –video. Por defecto, es “false”. En caso de ser verdadera, grabarán las pruebas y se guardará el video en “/docker/tmp/videos”. Siempre se generarán 2, uno para firefox y otro para chrome. No obstante, sólo tendrá contenido el del navegador seleccionado (recordemos que por defecto es firefox). Estos videos pueden descargarse, pero no debemos eliminar esos archivos, puesto que en ese caso los nodos no tienen permiso para crearlos y salta un error. Nota: Para ejecutar la opción –video=true deberemos desplegar previamente en local los nodos de video usando docker-compose, de modo que puedan conectarse a los nodos de los navegadores.

@@ Línea 3: / Línea 3: @@
 =Resumen=
-En el presente documento se explica y detalla el trabajo realizado para optar a la matrícula de honor en la asignatura Evolución y Gestión de la Configuración. En mi caso, consiste en realizar una contribución al repositorio uvlhub. Dicha contribución, además de cumplir con los requisitos especificados por el profesor, debe realizarse mediante una Pull Request al repositorio oficial. Los requisitos son los siguientes:
+En el presente documento se explica y detalla el trabajo realizado para optar a la matrícula de honor en la asignatura Evolución y Gestión de la Configuración.
-Dar la posibilidad de ejecutar los tests de selenium en un entorno docker a través del CLI incluido en el repositorio (rosemary). La idea es que los tests de selenium se ejecuten y puedan visualizarse dentro del entorno docker. En cuanto a la visualización, se deja libre la decisión a tomar (ya sea una pestaña del navegador, un contenedor, etc)
+En mi caso, consiste en realizar una contribución al repositorio uvlhub. Dicha contribución, además de cumplir con los requisitos especificados por el profesor, debe realizarse mediante una Pull Request al repositorio oficial. Los requisitos son los siguientes:
-En el comando del CLI mencionado con anterioridad, debe haber una opción que permita escoger driver. Si no se escoge ninguno, se utiliza el driver del navegador firefox. En caso contrario, solo se dispondrá de la opción “chrome”.
+. Dar la posibilidad de ejecutar los tests de selenium en un entorno docker a través del CLI incluido en el repositorio (rosemary). La idea es que los tests de selenium se ejecuten y puedan visualizarse dentro del entorno docker. En cuanto a la visualización, se deja libre la decisión a tomar (ya sea una pestaña del navegador, un contenedor, etc)
 =Resultados obtenidos=
 Se consiguieron completar todas las tareas y ahora rosemary selenium está soportado en docker.
@@ Línea 22: / Línea 22: @@
 * –video, que puede valer “true” o “false” (por defecto false) y sirve para grabar las pruebas de selenium * *
+Enlace al proyecto de github: https://github.com/Dangalcan/uvlhub

← Revisión anterior		Revisión del 20:34 4 feb 2025
Línea 1:		Línea 1:
−	* [[Página_Principal]] -> [[Salón_de_la_fama_de_EGC]]	+	* [[Página_Principal]] -> [[Salón_de_la_fama_de_EGC]] -> [[MH - 2024 2025]]

	=Resumen=		=Resumen=

@@ Línea 28: / Línea 28: @@
 =Tareas realizadas=
-En esta sección se describe todo lo que se ha hecho para completar el trabajo. Es recomendable añadir enlaces a cualquier elemento que se haya generado en el proceso de realización del trabajo. (links a videos, presentaciones, repositorios de código, etc).
+A continuación explicaremos qué se ha hecho y cómo. Adelantándonos un poco, se completaron ambas tareas.
 =Obstáculos=
-En esta sección se describen todos los problemas que hayan sucedido a lo largo del trabajo así como sus soluciones. También pueden incluirse los cambios o dificultades que hayan puesto en peligro la finalización del trabajo.
+Como principal problema he tenido la poca documentación que hay sobre Selenium-grid y su uso. Aunque es de gran utilidad, es complejo entender su funcionamiento en un inicio y a veces hay que recurrir a experimentar para entender y a videotutoriales así como leer el código. Teniendo en cuenta que en mi caso personal tengo una agenda muy apretada, fue un poco estresante integrar una herramienta de esta forma.
 =Conclusiones y posibles trabajos futuros=
-Conclusiones a las que se ha llegado y posibles extensiones o trabajos futuros
+Hemos aprendido que es importante documentar para evitar que otras personas tengan tantos problemas a la hora de usar nuestras herramientas. Además, podemos concluir que las tareas se completaron con éxito así como se explicaron de forma audiovisual y por escrito.

← Revisión anterior		Revisión del 20:33 4 feb 2025
Línea 1:		Línea 1:
−	* [[Página_Principal]] -> [[Salón_de_la_fama_de_EGC] ]	+	* [[Página_Principal]] -> [[Salón_de_la_fama_de_EGC]]

	=Resumen=		=Resumen=