En AzerothCore nos preocupamos por la calidad y la estabilidad del juego. Por ello, no enviamos los cambios directamente a la rama maestra (master). 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 pueden instalar AzerothCore también pueden contribuir probando los PR. Esta guía explicará cómo hacerlo. Cuantos más usuarios nos ayuden a probar los PRs, mejor será nuestra actividad de desarrollo en términos de velocidad y calidad.
Etiquetamos como Esperando ser probado a todos los PRs que ya han sido completados por el autor y han tenido su código revisado. Al hacer clic en la etiqueta anterior, se mostrará la lista de todos los PR que deben probarse para llegar a la rama maestra (master). Es importante que la comunidad ayude a testear, porque si los desarrolladores suben un cambio, y el mismo esta mucho tiempo sin revisarse, pueden perder un poco la motivación por seguir colaborando.
Es necesario:
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 funcionará para todo tipo de PRs.
git remote add upstream https://github.com/azerothcore/azerothcore-wotlk
Origin, para un colaborador, siempre es el repositorio que él puede modificar, en cambio upstream, es de quien descarga los cambios y actualiza. Porque algo importante, es que el emulador, debe estar siempre lo más actualizado posible. De esa forma, yo puedo realizar un git push a origin, pero no podría hacerlo nunca a upstream porque ese repositorio no me pertenece. Si bien, estamos un poco mezclando los 2 artículos, el de crear un PR y el de testear un PR, es importante que se entienda la diferencia entre solo tester y tester y colaborar.
Ahora, lo que necesitamos hacer, es posicionarnos siempre en la rama master y crear una nueva rama, para poder descargar los cambios del pull request que queremos probar. Por ejemplo, vamos a tomar como referencia el siguiente pull request: PR 5949. De la URL del PR, obtenemos el id, en este caso el 5949
git checkout master
git pull upstream master
git checkout -b pr-5949
git pull upstream pull/5949/head
Nota: si no tienen upstream, porque no son colaboradores, utilicen origin en su lugar. En la documentación de AzerothCore, utilizan ese método, la idea de este artículo, es mostrar ambos puntos al mismo tiempo, el de colaborador y el de tester.
En el caso, de que el PR agregue o elimine archivos, se debe utilizar el CMAKE para que la solución de visual studio o la compilación en Linux, reconozca esos archivos que se agregaron o se eliminaron. Si no ocurre eso, solamente deberíamos de compilar el emulador, y verificar los temas que se suelen detallar en el pull request. También siempre es bueno, adjuntar alguna imagen (se puede arrastrar hasta la caja de texto, y en unos pocos segundos se sube).
De mas esta decirles, que si llegaron hasta este punto y tienen dudas, pueden hacerme consultas por discord, siempre estoy dispuesto a ayudar a las personas que quieran ser testers o contribuidores de AzerothCore y que por algún motivo, no se animen a dar el primer paso. Pueden escribir en el chat, o incluso nombrarme, o enviarme un mensaje privado. Siempre está dispuesto a ayudar a aquellos que quieran colaborar.
En la wiki de AzerothCore, tienen otros ejemplos y también un poco más de documentación, por lo que les dejo el enlace para que lo lean.