Desarrollo

Esta página detalla cómo están organizados nuestros repositorios, cómo empezar a editar el código y crear su primera solicitud de extracción, y algunos procedimientos generales sobre las solicitudes de extracción en Jellyfin.

¿En qué deberías trabajar?

Hay muchos proyectos de la organización Jellyfin en Github para examinar y contribuir a ellos. Resumiendo, aquí están los dos más grandes, uno para los desarrollos de fondo y otro para los de frente:

• Servidor Jellyfin – El servidor back-end de la aplicación Jellyfin. Está construido usando .NET Core 3.1 y C#.
• Jellyfin Web – La principal aplicación cliente de Jellyfin. Construida para la web, pero también utilizada en algunos de nuestros otros clientes que son sólo envoltorios de este cliente web.

Nótese que cada uno de los repositorios también tiene su propia documentación sobre cómo comenzar con ese proyecto, que generalmente se encuentra en el repositorio README. También puede ver el árbol de fuentes de la organización para ver cómo están estructurados algunos de los proyectos más grandes.

La mejor manera de empezar un desarrollo real es revisar la lista de problemas del repositorio asociado, encontrar un problema en el que te gustaría trabajar, y empezar a hackear! Los problemas son revisados regularmente por el equipo administrativo, y se asignan etiquetas que deberían ayudarte a encontrar problemas dentro de tu conjunto de habilidades. Una vez que empieces a trabajar en un problema, por favor, coméntalo indicando tu intención de trabajar en el problema, para evitar la duplicación innecesaria de trabajo.

Tipos de cuestiones principales

En la sección de directrices sobre cuestiones se puede encontrar una lista de tipos de cuestiones.

¿Y si no hay un problema?

Si no hay ya un asunto relacionado con los cambios que quiere hacer, por favor cree un asunto para rastrearlo primero, luego asegúrese de que sus relaciones públicas hagan referencia al asunto en cuestión. Esto es especialmente útil para los errores que son encontrados y luego arreglados por el autor, de modo que tanto el problema original como el arreglo pueden ser documentados y rastreados en detalle.

¿Cómo debería hacer los cambios?

Una vez que hayas encontrado algo en lo que quieras trabajar o mejorar, el siguiente paso es hacer tus cambios en el código, probarlos, y luego enviar una solicitud de extracción (PR) en GitHub.

Para simplificar, todos los ejemplos asumen que el desarrollador está operando en Linux con acceso SSH a GitHub, sin embargo las ideas generales pueden aplicarse a las interfaces GitHub basadas en HTTP, y pueden ser traducidas a Windows o MacOS.

Si no estás familiarizado con Git, te recomendamos la documentación oficial para entender cómo funciona este sistema de control de versiones y cómo utilizarlo.

Prepara tu copia del repo

El primer paso es crear una copia del repositorio Git del proyecto en el que quieres contribuir. Jellyfin sigue un modelo de «bifurcación, características y relaciones públicas» para las contribuciones.

1. En GitHub, «Fork» el repositorio Jellyfin al que desea contribuir, a su propia cuenta de usuario utilizando el botón «Fork» del repositorio correspondiente.
2. Clona tu tenedor en tu máquina local y entra en el directorio:git clone git@github.com:yourusername/projectname.gitcd projectname/
3. Añade el control remoto «upstream», que te permite bajar los cambios del proyecto principal fácilmente:git remote add upstream git@github.com:jellyfin/projectname.git
4. Inicializar los submódulos de Git; la mayoría de los proyectos tienen al menos una actualización del submódulo de Git –initNoteAvitar la edición de archivos dentro de los submódulos. Hacerlo puede resultar en efectos secundarios no deseados, incluyendo la sobreescritura de tu trabajo. Siempre modifica el submódulo en su propio repositorio clonado en otro lugar.
5. Para que el proyecto Jellyfin.Server se ejecute con éxito, comprueba tanto el servidor, como el proyecto del cliente web.
6. Construya el proyecto Jellyfin Web con Yarn o NPM, y copie la ubicación de la carpeta dist resultante. En su proyecto Jellyfin.Server añada una variable de entorno llamada JELLYFIN_WEB_DIR con el valor establecido en la ruta completa de su carpeta dist.

Ahora estará listo para empezar a construir o modificar el proyecto.

Hacer cambios en el repo

Una vez que tengas tu depósito, puedes ponerte a trabajar.

1. Rebase sus ramas locales contra el maestro upstream para trabajar con los últimos cambios:git fetch –allgit rebase upstream/master
2. Crea una rama de características locales del maestro para hacer tus cambios:git checkout -b my-feature master
3. Haga sus cambios y compromisos en esta rama de características locales.
4. Repita el paso 1 en su sucursal local una vez que haya terminado su trabajo, para asegurarse de no tener conflictos con otros trabajos realizados desde que declaró.
5. Sube la rama de características locales a tu horquilla GitHub:git push –set-upstream origin my-feature
6. En GitHub, crea un nuevo RP contra la rama maestra de la corriente ascendente siguiendo el consejo de abajo.
7. Una vez que tu RP se fusione, asegúrate de mantener tus sucursales locales actualizadas:git fetch –allgit checkout mastergit rebase upstream/mastergit push -u origin master
8. Borra la rama de tu característica local si ya no la necesitas:git branch -d my-feature

CONTRIBUIDORES.md

Si es la primera vez que contribuyes con código a un repositorio en particular, por favor añádase al archivo CONTRIBUTORS.md al final de la sección de Contribuidores de Jellyfin. Aunque GitHub hace un seguimiento de esto, tener el documento escrito aclara las cosas si el código sale de GitHub y permite a todos ver rápidamente quién ha trabajado en el proyecto por derechos de autor o elogios!

Ramas oficiales

Ramas de características

De vez en cuando, pueden surgir proyectos importantes que requieren múltiples relaciones públicas y contribuciones de varias personas. Para estas tareas, se deben crear ramas de características específicas de la característica, basadas en el maestro. Esto ayuda a permitir que el trabajo avance sin romper el master durante largos períodos, y permite a los interesados en ese proyecto en particular la posibilidad de trabajar a su propio ritmo en lugar de correr para arreglar una característica rota antes del próximo lanzamiento. Para crear una rama de la característica, por favor comuníquese con un miembro del equipo de Core y eso se puede arreglar.

Una vez que la característica para la que se creó una rama de la característica está lista, puede ser fusionada en una toma en el maestro y la rama de la característica eliminada. Alternativamente, para las características de vida muy larga, ciertas instantáneas «estables» pueden ser fusionadas en el master según se requiera.

La Rama Maestra

La rama maestra es la cara principal del proyecto y la principal rama de desarrollo. Excepto para los hotfixes de liberación de emergencia, todas las relaciones públicas deben tener como objetivo al maestro. Como regla general, ningún RP debe romper el maestro y todos los RP deben ser probados antes de fusionarse para asegurar que esto no ocurra. Sólo somos humanos y es probable que esto ocurra, pero en general, debería ser seguro construir a partir del maestro si quiere la última y más grande versión de Jellyfin.

Probando una petición de tirar

Para probar la solicitud de extracción de otra persona, debe importar los cambios a su depósito local.

1. Obtener los cambios en una solicitud de extracción y vincularlos a una nueva rama local:git fetch upstream pull/<PR_ID>/head:my-testing-branchNote<PR_ID> es el número de solicitud de extracción en GitHub.
2. Comprobar la nueva sucursal local:git comprobar mi sucursal de pruebas
3. Realiza cualquier prueba o construcción necesaria para probar, luego regresa al maestro y borra la rama:git checkout mastergit branch -D my-testing-branch

Directrices de la solicitud de extracción

Al presentar un nuevo RP, por favor asegúrese de hacer lo siguiente. Si no lo has hecho, por favor lee Cómo escribir un mensaje de compromiso de Git, ya que es un gran recurso para escribir mensajes de compromiso útiles.

• Antes de presentar un RP, la «basura» de la calabaza se compromete a mantener limpia la historia general. Una sola confirmación debería cubrir un único cambio significativo: evita aplastar todos tus cambios, especialmente para los grandes RP que tocan muchos archivos, pero tampoco dejes las confirmaciones «arregladas», «whoops typo» en el historial de tu rama ya que esto es un desorden innecesario en la historia final del proyecto.
• Escriba un buen título que describa rápidamente lo que se ha cambiado. Por ejemplo, «Añadir soporte LDAP a Jellyfin». Como se menciona en Cómo escribir un mensaje de compromiso Git, usa siempre el estado de ánimo imperativo, y mantén el título corto pero descriptivo. El título será eventualmente una entrada en el registro de cambios, así que por favor trata de usar las mayúsculas adecuadas pero sin puntuación; ten en cuenta que el equipo del núcleo puede alterar los títulos para confirmar mejor a este estándar antes de fusionarse.
• Para cualquier cosa que no sean los cambios más triviales que pueden ser descritos completamente en el (corto) título, siga la plantilla de relaciones públicas y escriba un cuerpo de relaciones públicas para describir, con el mayor detalle posible: Por qué se están haciendo los cambios. Haga referencia a temas específicos con palabras clave (arreglos, cierres, direcciones, etc.) si es posible.Cómo se ha abordado el tema (si procede) y describa brevemente los cambios, especialmente para los grandes RP.
• Si su solicitud de extracción no está terminada aún, por favor márquela como «borrador» cuando la abra. Mientras esta etiqueta esté en su lugar, la solicitud de extracción no se fusionará, y las revisiones deben permanecer sólo como comentarios. Una vez que esté satisfecho con el estado final de su RP, por favor retire esta etiqueta; ¡olvidarlo podría resultar en que su RP sea ignorado involuntariamente como si estuviera todavía en desarrollo activo! Los WIPs inactivos pueden ocasionalmente provocar pings del equipo preguntando por el estado, y se cierran si no hay respuesta.
• Evite rebasar y forzar las solicitudes de extracción grandes o complejas si es posible, y especialmente después de las revisiones. Obliga a revisiones innecesarias para verificar que los cambios siguen estando bien y se construyen adecuadamente.
• Espere una revisión y discusión. Si no puede respaldar sus cambios con una buena descripción y a través de la revisión, por favor reconsidere si debe hacerse en absoluto. Todas las relaciones públicas requieren al menos una revisión de aprobación por parte de un miembro del equipo administrativo, sin embargo damos la bienvenida y animamos a las revisiones de cualquier colaborador, especialmente si es en un área que usted conoce. Más ojos siempre son mejores.
• Todas las relaciones públicas requieren la revisión de al menos dos miembros del equipo antes de ser fusionadas en el maestro, aunque las revisiones de cualquier colaborador son bienvenidas! Después de la revisión del segundo miembro del equipo, el RP puede ser fusionado inmediatamente, o más revisiones o comentarios solicitados explícitamente a otros contribuyentes si es necesario.

Necesitamos instalar todas las dependencias de desarrollo y sacar el código dentro del contenedor antes de poder compilar y ejecutar.

Nota

Ponga cada comando en una línea separada. El contenedor en el que haremos la prueba se llama jftest. Dentro de Docker, cada vez que el ejecutable del punto de entrada se termina, la sesión se reinicia, así que sólo tienes que ejecutarlo de nuevo para continuar. Por eso también lo matamos explícitamente para recargar la nueva versión.

Rama maestra

docker exec -ti jftest bashapt-get update && apt-get install gnupg wget apt-transport-https curlwget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg && mv microsoft.asc.gpg /etc/apt/trusted.gpg. d/wget -q https://packages.microsoft.com/config/debian/10/prod.list && mv prod.list /etc/apt/sources.list.d/microsoft-prod.listcurl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources. list.d/yarn.listapt-get update && apt-get install dotnet-sdk-3.1 yarncd /opt && git clone https://github.com/jellyfin/jellyfin.git && git clone https://github.com/jellyfin/jellyfin-web.gitmv /jellyfin/ /jellyfin.bak && cd /opt/jellyfin && dotnet publish Jellyfin. Server --configuration Debug --output="/jellyfin" --self-contained --runtime linux-x64cd /opt/jellyfin-web && yarn install && yarn build && cp -r /opt/jellyfin-web/dist /jellyfin/jellyfin-webkill -15 $(pidof jellyfin)

Petición de tirar

Primero, completa los pasos anteriores para configurar tu contenedor para construir la rama maestra.

Nota

es el número de solicitud de extracción en GitHub.

docker exec -ti jftest bashcd /opt/jellyfingit fetch origin pull/<PR_ID>/head:my-testing-branchgit merge my-testing-branchdotnet publish Jellyfin.Server --configuration Debug --output="/jellyfin" --self-contained --runtime linux-x64kill -15 $(pidof jellyfin)