Cómo probar un PR (pull request)

Introducción

En AzerothCore nos preocupamos por la calidad y la estabilidad del juego. Por ello, no enviamos los cambios directamente a la rama maestra. En su lugar, cada vez que introducimos un nuevo cambio, creamos un nuevo Pull Request (a menudo acortado en PR).

Esto nos permite revisar y probar adecuadamente cualquier cambio antes de que llegue a los entornos de producción. Todos los que puedan instalar AzerothCore también pueden contribuir probando los PRs. Esta guía explicará cómo hacerlo.

Cuantos más usuarios nos ayuden a probar los PR, mejor será nuestra actividad de desarrollo en términos de velocidad y calidad.

¿Qué PRs hay que probar?

Etiquetamos como A la espera de ser probado todos los PRs que ya han sido completados por el autor y han tenido su código revisado.

Al hacer clic en la etiqueta de arriba se mostrará la lista de todos los PRs que deben ser probados para llegar a la rama master.

¿Qué necesito antes de probar un PR?

Es necesario:

• Tener AzerothCore instalado en tu sistema (ver Instalación).
• Tener una cuenta en GitHub, puede registrar una aquí de forma gratuita.

¿Y si el PR sólo tiene cambios en la BD (base de datos)?

Algunos PRs sólo tienen cambios en la base de datos (sin cambios en C++). Si ese es el caso, hay un procedimiento simplificado para probar esos cambios.

Si no estás seguro, sigue leyendo aquí y haz la prueba tradicional de PR que servirá para todo tipo de PR.

Notas que clonaron un fork de AzerothCore en lugar del repo principal:

Es típico crear y clonar tu propio fork de AzerothCore si también eres desarrollador.

Si ese es tu caso, entonces tienes que

• añadir el principal AzerothCore remoto utilizando:

git remote add upstream https://github.com/azerothcore/azerothcore-wotlk.git

• sustituya origin por upstream en todos los comandos indicados a continuación

Obtenga el código PR para ser probado

• Abre un terminal y ve al directorio de tus fuentes de AzerothCore, por ejemplo usando cd azerothcore-wotlk.

• Aquí asumimos que estás comenzando desde una rama "master" limpia y actualizada. Puedes verificar en qué rama estás escribiendo "git checkout". Si no estás en master, vuelve a master usando git checkout master. Ya que estás aquí, también puedes hacer git pull para asegurarte de que tienes la última rama maestra. Y recuerda, nunca añadas cambios personalizados a la rama maestra (crea siempre una rama nueva y separada si es necesario).

• Comprueba el ID del PR que quieres probar, aparecerá en la URL y el título del PR. Por ejemplo, el ID de este PR es 1383: PR 1383

• Ahora debe ejecutar los siguientes comandos sustituyendo "XXXX" por el ID del PR que desea probar:

git checkout -b pr-XXXX

git pull origin pull/XXXX/head

Ejemplo:

git checkout -b pr-1383

git pull origin pull/1383/head

Los comandos anteriores crearán una nueva rama local llamada pr-XXXX que contendrá todos los cambios que deben ser probados.

La terminal mostrará un editor (normalmente nano o vim) que le pedirá que guarde el mensaje de confirmación de la fusión. Simplemente guarde los cambios y salga del editor.

• Si el editor es nano, puedes hacerlo simplemente usando ctrl + o y ENTER para guardar y luego ctrl + x para salir.
• Si el editor es vim puedes mantener la tecla SHIFT y pulsar dos veces Z para guardar y existir.

Puedes leer más sobre la configuración de git y su editor por defecto aquí.

• Nota: Compruebe el mensaje en su consola. Si dice "La fusión automática ha fallado; arregle los conflictos y luego confirme el resultado", debe informar al PR, pidiendo al desarrollador que por favor arregle los conflictos de fusión, y elimine la etiqueta "esperando a ser probado" y adjunte una etiqueta "conflicto de fusión".

Actualice su servidor local para aplicar los cambios

Ahora sólo tiene que actualizar su servidor local con los nuevos cambios. El procedimiento es análogo al de una actualización normal del servidor.

Básicamente necesitas recompilar tus fuentes y actualizar la BD.

Nota: Si se agregaron archivos nuevos o se eliminaron algunos / renombraron, recuerdo ejecutar el cmake para que los reconozca durante la compilación.

Utilizando la configuración tradicional

Si está utilizando la instalación tradicional, tiene que volver a compilar siguiendo los pasos de la 3) Compilación de la guía de instalación principal.

También necesita actualizar su DB. Puede utilizar el ensamblador de BD para hacerlo, pero normalmente es más rápido importar manualmente los archivos sql pendientes que incluye el PR. Estos archivos se encuentran en data/sql/updates/pending_db_*.

Consejo: Normalmente, un PR consiste en un archivo de actualización del mundo nuevo ubicado en data/sql/updates/pending_db_world. Puede comprobar qué archivos se han añadido para detectar cualquier archivo sql añadido yendo a la pestaña "Archivos cambiados" de la página de PR:

A continuación, inicie el servidor como lo hace siempre.

Uso de la configuración de Docker

Si está utilizando la configuración de Docker, puede simplemente activar la recompilación ejecutando:

• Linux:

./bin/acore-docker-build

• Windows:

./acore.sh docker build

Entonces para lanzar el servidor tienes que destruir y recrear los contenedores usando docker-compose down y docker-compose up.

Nota: esto también actualizará automáticamente su DB.

Verifique su versión actual

Para asegurarse de que está ejecutando correctamente su servidor con el PR, compruebe la fecha y el nombre de la rama en la salida del comando server info. Deben coincidir con el PR.

Ahora entra en el juego y haz tus pruebas.

¿Qué hay que probar?

Las instrucciones sobre lo que hay que probar en el ámbito de un PR deben ser proporcionadas por el autor del PR en la descripción del mismo. Si no es el caso, no dudes en dejar un comentario en la descripción del PR pidiendo instrucciones de prueba.

Para los usuarios avanzados: también puedes echar un vistazo a lo que realmente se ha cambiado en el PR y decidir tú mismo qué probar. A veces es bueno tener un punto de vista diferente. Sólo asegúrese de describir lo que ha probado en su informe.

Informar de los resultados de las pruebas

Es importante informar de los resultados de las pruebas dejando un comentario en la página de PR.

Deberías escribir:

• Lo que ha probado
• ¿Las cosas que ha probado funcionan como se pretendía?
• A veces también puede especificar cómo funcionaban las cosas antes y después del PR
• Por favor, inserte tantos detalles como sea posible
• También puede insertar capturas de pantalla o vídeos

Ejemplos de buenos informes de pruebas

Pruebas de finalización

Una vez que haya dejado un informe de prueba, querrá revertir su instalación de AC al estado base para realizar más pruebas. Para ello, utiliza git reset --hard para eliminar todos los cambios no realizados, seguido de git checkout master para volver a la rama maestra. Para poner orden, también puedes usar git clean -fd para deshacerte de cualquier archivo sin seguimiento. Finalmente, puedes escribir git status para asegurarte de que todo vuelve a la normalidad.