Contribuir

Haz un cambio pequeño en el lugar correcto y envíalo como pull request.

Antes de empezar

• Abre primero un issue, o comenta en uno que ya exista. Di qué quieres cambiar y por qué.
• Espera una respuesta, para no construir algo que no se va a fusionar.
• Termina la Configuración para poder compilar y ejecutar HolyArrs.

Las preguntas van a Discord. Las ideas van a r/HolyArrs. Los issues son para errores y para la hoja de ruta.

Envía tu primer pull request

1. Busca el módulo al que pertenece tu cambio. Los nombres de Módulos coinciden con los nombres de las carpetas, así que un aviso de Discord incorrecto es un cambio en alerts.

2. Haz el cambio en app/backend/internal/<module>/ y app/frontend/src/lib/<module>/. Limítalo a una corrección o a una función.

3. Compila la app web, luego el programa, y prueba el cambio en el navegador. Consulta Configuración.

4. Ejecuta las comprobaciones de Pruebas.

   No deberías ver ningún fallo.

5. Si cambiaste una página, ejecuta su proyecto de extremo a extremo, por ejemplo npm --prefix app/frontend run e2e -- --project=movies.

6. Abre el pull request. Enlaza el issue, di qué cambió y cómo lo probaste, y añade o actualiza las pruebas del cambio.

7. En tu primer pull request, un bot te pide que firmes el acuerdo de licencia de colaborador. Responde con la frase que te pide.

Nota

Conservas los derechos de autor de tu trabajo. El acuerdo permite ofrecer HolyArrs bajo la AGPL-3.0 y bajo una licencia comercial. Todo lo que se fusiona sigue disponible también bajo la AGPL-3.0. El texto está en .github/CLA.md.

Opciones

Dónde va un cambio

Cambio	Ve a
Una ruta nueva	Módulos
Un módulo nuevo	Módulos. Abre primero un issue
Una función retenida	Configuración
Una versión	Publicar una versión. Solo mantenedores

Cómo es un buen pull request

• Escribe comentarios que digan por qué el código hace lo que hace. Sin números de la hoja de ruta, fechas, nombres ni rayas en los comentarios.
• No toques los textos de la app, salvo que el issue trate de los textos.
• Deja como están las rutas de la API, los nombres de campos, las claves de ajustes, los nombres de tablas y los nombres de tareas ya publicados. Añade, nunca renombres.

Si no funciona

Síntoma. Falla una comprobación de estructura. Causa. El mensaje indica el archivo y la regla. Solución. Mueve el código, o pasa datos simples desde el módulo superior. Consulta Módulos.

Síntoma. La app web se ve antigua. Causa. El programa sirve la compilación que incorporó. Solución. Vuelve a compilar la app web antes que el programa.

Síntoma. Las pruebas de extremo a extremo no pueden iniciarse. Causa. El navegador de pruebas no está instalado. Solución. Ejecuta npx --prefix app/frontend playwright install chromium.

Para expertos

Reglas que un pull request debe respetar

• Un módulo habla con otro módulo solo a través de su servicio (Go) o de su index.ts (web). Nunca a través de su store ni de sus archivos.
• El SQL vive solo en los archivos store*.go de un módulo, sobre las tablas propias de ese módulo.
• Una parte web va en lib/ui solo cuando la usan 2 o más módulos.
• Nada de paquetes util, common, shared ni helpers.
• Toda llamada al exterior pasa por core/outbound.

Hay pruebas que comprueban estas reglas, así que una importación incorrecta hace fallar la compilación. La lista completa y los nombres de las comprobaciones están en Módulos.

Qué ejecuta CI

Tarea	Ejecuta
Web	check, lint, test, build y el conjunto de extremo a extremo
Go	go build, go vet y go test -timeout 60m ./... en amd64 y arm64, de forma nativa y con emulación
Race	go test -race ./...
Contrato	La coincidencia de openapi.json, las comprobaciones de alcance en cada ruta, el conjunto de gestores de descargas
Fallos y escala	Ejecuciones de caídas, escritura lenta, servicio externo defectuoso y memoria
Imagen	Una imagen de desarrollo se compila, se inicia e informa de su versión

Los detalles de las ejecuciones largas están en Pruebas.

Relacionado

• Configuración
• Pruebas
• Arquitectura