[IV 21-22] Objetivo 6 #27
Conversation
Crea la documentación en la que se comentan aspectos del setup e importantes de la herramienta
Crea la documentación en la que se comenta y justifica la elección de las herramientas usadas en el Objetivo
Añadimos una opción que nos permita lanzar la imagen del docker automatizándolo.
Incluye un enlace en el README.md a la documentación referente a los sistemas de integración continua.
Crea el archivo de configuración de Github Actions para ejecutar los tests pertinentes.
Corrige fallo de tabulación en la línea 12.
Corrige fallo de tabulación en la línea 14.
Corrige fallo de tabulación en la línea 15.
Corrige fallo de tabulación en la línea 8.
Corrige fallo de tabulación en la línea 4.
Añade imagen de error de versiones de ruby
Corrige dos enlaces
Paszser
added this to the
[M1] - Módulo de almacenamiento de información y despliegue de precios. milestone
|
⛹ Revisores → @danifm1321 @lentes4k @Antobio17 |
lentes4k
left a comment
lentes4k
left a comment
There was a problem hiding this comment.
Muy bien trabajado. Solo he detectado alguna minucia que te aparecerá por aquí abajito.
Como opinión personal creo que hay demasiada documentación en ciertos puntos. Está bien documentar aquello que hay propiciado conflicto o es reseñable, algunas otras cosas se pueden dar por supuestas.
Lo dicho, es mi opinión (realmente soy bastante malo documentando 🤣) y quizás sea una opinión equivocada.
Dicho esto, por mi puedes seguir con los siguientes, ¡ánimo! 💯
¡Muchas gracias! Nada más vuelva a casa me pongo a revisar lo que me has señalado y refinarlo, porque tienes razón. Igualmente también voy aprendiendo poco a poco a documentar, espero poder hacerlo mejor paso a paso 😄 Cualquier duda que tenga luego te la pondré por acá. Si por algún casual me pudieras dar algún ejemplo de documentación excesiva que veas o que dieras por supuesta te lo agradecería para poder entenderlo mejor y a partir de ahí quizás afinar el resto 😢 Como te dije, me cuesta barbaridad acertar al 100% con esto 😂 😂 Y nuevamente muchas gracias ^^. |
Corrige clave version en el config.yml y en Github_Actions.md
Creo que donde quizás algo te hayas excedido es a la hora de documentar por separado los sitemas de integración continua. Pero ya te digo, yo no soy muy bueno documentando 😅 |
Siguiendo los pasos en la documentación de CircleCI, tratamos de solucionar el issue.
Siguiendo los pasos en la documentación de CircleCI, tratamos de solucionar el issue.
Siguiendo los pasos en la documentación de CircleCI, tratamos de solucionar el issue.
Siguiendo los pasos en la documentación de CircleCI, tratamos de solucionar el issue.
Antobio17
left a comment
Antobio17
left a comment
There was a problem hiding this comment.
Mi revisión va un más general, ya que realmente la configuración inicial del sistema de integración continua no es "muy complicado" como has podido ver. Sin embargo creo que la documentación está demasiado enfocada a la teoría. Realmente con los requisitos que tenemos casi cualquier CI nos da buenos recursos para la integración en el proyecto. Por eso hubiera sido buena opción coger algunos sistemas, probar a configurar documentando por ejemplo con imágenes o trozos de código caracteristicos de la configuración y explicar facilidades/inconvenientes que te hubieras podido ir encontrando.
Faltaría también justificar las versiones de Ruby testeadas que es uno de los requisitos del objetivo 6.
Espero que te sirva mi punto de vista 👍 cualquier cosa comenta!
Siguiendo los pasos en la documentación de CircleCI, tratamos de solucionar el issue.
Siguiendo los pasos en la documentación de CircleCI, tratamos de solucionar el issue.
Siguiendo los pasos en la documentación de CircleCI, tratamos de solucionar el issue.
Fallo mío, no vi la justificación de las versiones en un issue y me lo salté sin querer en la documentación agregada. |
¡No te preocupes! La verdad que intentando dejar todo más o menos completo no sé si al final está todo bien, me he pasado o no sé. Creo que al final en la documentación doy algunas razones para desechar algunas herramientas y otras razones para coger las finales, al menos voy haciendo lo que puedo a pesar del catarro que he pillado que apenas puedo respirar 😂 😂 ¡Muchas gracias por todo! |
|
Creo que finalmente está preparado para revisión @JJ . Le recuerdo que puede haber algunos aspectos del Objetivo 5 que falte por repasar, pues dicho objetivo no lo pasé y en este me centré en los contenidos del 6. En la convocatoria extraordinaria me centraré en repasar el 5 y dejarlo listo. Muchas gracias por todo 😄 |
JJ
left a comment
JJ
left a comment
There was a problem hiding this comment.
- No se testean cosas diferentes con el contenedor docker y GH
- Se eligen los mismos que ha elegido (ya a estas alturas, y el 100% de los llegados después del periodo lectivo) el 99% de la clase, y sin justificar suficiente ni usar realmente los criterios escritos para elegirlos.
- No se justifican las versiones que se usan para testear.
|
|
||
| A continuación se va a presentar una lista de las opciones que se han barajado de cara a las dos herramientas a usar: | ||
|
|
||
| * Jenkins: Servidor de automatización open source. Colabora en la automatización de parte del desarrollo software mediante la integración continua y la facilita. No es solo un motor con resultados binarios tales como "Success/Failed" si no que deja un feedback que mediante la webapp de la herramienta se puede visualizar. A su vez, Jenkins es una arquitectura de plugins, lo que la hace fácilemnte extensible y se adapta bien a otras herramientas y lenguajes. Ofrece API REST y cuenta con *matrix jobs*. |
There was a problem hiding this comment.
Si no vas a evaluar los 6 aspectos que has puesto antes, no los pongas.
|
|
||
| ### Justificación de la Elección | ||
|
|
||
| Las principales razones para justificar la elección son que ambas herramientas cumplen con creces los requisitos impuestos con anterioridad. Ambas son compatibles con el testeo de varias versiones de nuestro lenguaje, el cual en este proyecto realizamos con Github Actions. Ambas son de uso libre y gratis, siendo así el nivel más básico de CircleCI, más que suficiente para este proyecto. Por ejemplo en Github Actions podemos hacer uso de *matrix* como nuestra matriz de compilaciones recogiendo así las versiones del lenguaje que queremos usar para hacer el test del proyecto. |
|
|
||
| Aquí comentaremos un aspecto curioso que se ha dado en el desarrollo del archivo de configuración de Github Actions. A pesar de que la última versión estable de Ruby es la *3.1.0* como se puede ver [aquí](https://www.ruby-lang.org/es/downloads/) en el apartado de versiones estables, y siendo la 2.6.9 la más antigua estable, y las versiones anteriores ninguna tiene soporte. En la documentación seguida para enlazar Ruby y setearlo [aquí](https://docs.github.com/es/actions/automating-builds-and-tests/building-and-testing-ruby) nos recomienda hacer uso de una versión del set up en la que las últimas versiones de Ruby no se encuentran soportadas. Como se indica [acá](docs/img/rubyvError.png) la última versión de la que podemos hacer uso es la *3.0.1*. En este caso y a pesar que [aquí](https://github.com/ruby/setup-ruby) se ha dado soporte a las últimas versiones de Ruby hace apenas un par de semanas, se ha preferido seguir las prácticas que se encuentran en la documentación de GithubActions para ceñirnos a pruebas más fiables. | ||
|
|
||
| Por ello hemos optado por usar las versiones 3.0.0, y 3.0.1, pues son distintas a la misma que probamos en la imagen del docker y entran en los parámetros recomendados en la documentación de la herramienta. No newline at end of file |
There was a problem hiding this comment.
Se prueban versiones para ver con cuantas es compatible. En el caso de Ruby sería imprescindible probar con la versión LTS de la 2. Precisamente se usa el CI para saber si es compatible o no.
| - checkout | ||
| - run: | ||
| name: "Task para app test" | ||
| command: "rake docker" |
There was a problem hiding this comment.
¿Dónde se configura Ruby? Si viene de serie, ¿por qué no se pone como justificación para elegir este y no otro?
| push: | ||
| paths: | ||
| - Dockerfile | ||
| - Gemfile |
Aclaro que hay algunos aspectos mejorables del Objetivo 5 los cuales, al no haberlo superado, se han dejado para refinar de cara a la convocatoria extraordinaria (sobre todo de documentación), aunque otros sí que se siguieron las correcciones y sí que se mejoraron. Aquí se abarcan los contenidos del objetivo 6.
sea necesario para que aparezca correctamente en GitHub (y se pueda comprobar
desde los tests)? -> Sí, se ha realizado en CircleCI y se puede comprobar en la documentación del mismo.
del lenguaje con las que funciona correctamente nuestra aplicación? -> Sí, se ha realizado en GithubActions y se puede comprobar en la documentación del mismo.
tanto en el sistema de CI como en el contenedor Docker?
closes #28
closes #29
closes #30