Aller au contenu

Développement

Cette page détaille la façon dont nos référentiels sont organisés, comment commencer à éditer le code et créer votre première demande de tirage, ainsi que quelques procédures générales sur les demandes de tirage dans Jellyfin.

Sur quoi devez-vous travailler?

Il y a beaucoup de projets d'organisation Jellyfin sur Github à revoir et à contribuer. Pour résumer, voici les deux plus grands, un pour les développements de fond et un pour les premiers:

 Développement Développement
  • Jellyfin Server - Le serveur principal de l'application Jellyfin. Il est construit à l'aide de .NET Core 3.1 et C#.
  • Jellyfin Web - L'application cliente principale de Jellyfin. Conçu pour le Web, mais également utilisé dans certains de nos autres clients qui ne sont que des wrappers de ce client Web.

Notez que chacun des référentiels possède également sa propre documentation sur la façon de démarrer avec ce projet, qui se trouve généralement dans le référentiel README. Vous pouvez également afficher l'arborescence source de l'organisation pour voir comment certains des grands projets sont structurés.

La meilleure façon de démarrer un véritable développement est de parcourir la liste des problèmes dans le référentiel associé, de trouver un problème sur lequel vous souhaitez travailler et de commencer le piratage! Les problèmes sont examinés régulièrement par l'équipe de gestion et des étiquettes sont attribuées qui devraient vous aider à trouver des problèmes dans votre ensemble de compétences. Une fois que vous commencez à travailler sur un problème, veuillez le commenter en indiquant votre intention de travailler sur le problème, pour éviter la duplication inutile du travail.

Types de questions principales

Une liste des types de questions se trouve dans la section Directives pour les questions.

Et s'il n'y a pas de problème?

S'il n'y a pas déjà un problème lié aux modifications que vous souhaitez apporter, veuillez créer un problème pour le suivre en premier, puis assurez-vous que vos relations publiques font référence au problème en question. Ceci est particulièrement utile pour les erreurs détectées puis corrigées par l'auteur, afin que le problème d'origine et le correctif puissent être documentés et suivis en détail.

Comment dois-je effectuer les modifications?

Une fois que vous avez trouvé quelque chose sur lequel vous souhaitez travailler ou vous améliorer, l'étape suivante consiste à apporter vos modifications de code, à les tester, puis à soumettre une demande de pull (PR) sur GitHub.

Pour plus de simplicité, tous les exemples supposent que le développeur fonctionne sous Linux avec un accès SSH à GitHub, cependant les idées générales peuvent être appliquées aux interfaces GitHub basées sur HTTP et peuvent être traduites vers Windows ou MacOS.

Si vous n'êtes pas familier avec Git, nous vous recommandons la documentation officielle pour comprendre comment ce système de contrôle de version fonctionne et comment l'utiliser.

Préparez votre copie du dépôt

La première étape consiste à créer une copie du référentiel Git du projet auquel vous souhaitez contribuer. Jellyfin suit un modèle de «contributions, fonctionnalités et relations publiques».

  1. Sur GitHub, "Fork" le dépôt Jellyfin auquel vous souhaitez contribuer, à votre propre compte utilisateur en utilisant le bouton "Fork" du dépôt correspondant.
  2. Clonez votre fork sur votre machine locale et entrez dans le répertoire: git clone git@github.com: yourusername / projectname.gitcd projectname /
  3. Ajoutez la télécommande "en amont", qui vous permet de télécharger facilement les modifications du projet principal: git remote ajoutez en amont git@github.com: jellyfin / projectname.git
  4. Initialisez les sous-modules Git; la plupart des projets ont au moins une mise à jour du sous-module Git –initNoteÉvitez de modifier les fichiers dans les sous-modules. Cela peut entraîner des effets secondaires indésirables, notamment le remplacement de votre travail. Modifiez toujours le sous-module dans son propre référentiel cloné ailleurs.
  5. Pour que le projet Jellyfin.Server s'exécute correctement, il vérifie à la fois le serveur et le projet client Web.
  6. Générez le projet Web Jellyfin avec Yarn ou NPM et copiez l'emplacement du dossier dist résultant. Dans votre projet Jellyfin.Server, ajoutez une variable d'environnement appelée JELLYFIN_WEB_DIR avec la valeur définie sur le chemin complet de votre dossier dist.

Vous êtes maintenant prêt à commencer à créer ou à modifier le projet.

Apportez des modifications au référentiel

Une fois que vous avez votre dépôt, vous pouvez vous mettre au travail.

  1. Relayez vos branches locales contre le maître en amont pour travailler avec les dernières modifications: git fetch –allgit rebase upstream / master
  2. Créez une branche de fonctionnalité locale du maître pour effectuer vos modifications: git checkout -b my-feature master
  3. Apportez vos modifications et vos engagements dans cette branche de fonctionnalités locales.
  4. Répétez l'étape 1 à votre succursale locale après avoir terminé votre travail, pour vous assurer que vous n'avez aucun conflit avec les autres travaux effectués depuis votre déclaration.
  5. Téléchargez la branche de fonctionnalité locale sur votre fork GitHub: git push –set-upstream origin my-feature
  6. Sur GitHub, créez un nouveau RP contre la branche principale de mise à jour en suivant les conseils ci-dessous.
  7. Une fois votre RP fusionné, assurez-vous de garder vos succursales locales à jour: git fetch –allgit checkout mastergit rebase upstream / mastergit push -u origin master
  8. Supprimez la branche de votre fonctionnalité locale si vous n'en avez plus besoin: git branch -d my-feature

CONTRIBUTORS.md

S'il s'agit de votre premier code de contribution à un référentiel particulier, veuillez l'ajouter au fichier CONTRIBUTORS.md à la fin de la section Contributeurs Jellyfin. Bien que GitHub suive cela, avoir le document écrit clarifie les choses si le code quitte GitHub et permet à tout le monde de voir rapidement qui a travaillé sur le projet pour le droit d'auteur ou les éloges!

Succursales officielles

Branches fonctionnelles

Parfois, de grands projets peuvent émerger qui nécessitent de multiples relations publiques et des contributions de plusieurs personnes. Pour ces tâches, des branches de fonction spécifiques à la fonction doivent être créées en fonction du maître. Cela permet de poursuivre le travail sans interrompre le maître pendant de longues périodes et permet aux personnes intéressées par ce projet particulier de travailler à leur propre rythme plutôt que de se précipiter pour corriger une fonctionnalité cassée avant la prochaine version. Pour créer une branche de fonctionnalités, veuillez contacter un membre de l'équipe Core et cela peut être corrigé.

Une fois que la fonction pour laquelle une branche de fonction a été créée est prête, elle peut être fusionnée en une prise sur le maître et la branche de fonction supprimée. Alternativement, pour des caractéristiques de durée de vie très longue, certains instantanés "stables" peuvent être fusionnés dans le maître selon les besoins.

The Master Branch

La branche maître est la face principale du projet et la branche principale de développement. À l'exception des correctifs de version d'urgence, toutes les relations publiques doivent cibler l'enseignant. En règle générale, aucun RP ne doit casser le maître et tous les RP doivent être testés avant la fusion pour s'assurer que cela ne se produit pas. Nous ne sommes qu'humains et cela est susceptible de se produire, mais en général, il devrait être sûr de construire à partir du maître si vous voulez la dernière et la meilleure version de Jellyfin.

Tester une demande de tournage

Pour tester la demande de retrait de quelqu'un d'autre, vous devez importer les modifications dans votre référentiel local.

  1. Récupérez les modifications dans une demande de pull et liez-les à une nouvelle branche locale: git fetch upstream pull / / head: my-testing-branchNote est le numéro de demande d'extraction sur GitHub.
  2. Vérifier la nouvelle branche locale: git vérifier ma branche de test
  3. Effectuez tous les tests ou builds nécessaires pour tester, puis revenez au maître et supprimez la branche: git checkout mastergit branch -D my-testing-branch

Directives de demande d'extraction

Lorsque vous soumettez un nouveau RP, assurez-vous de procéder comme suit. Si vous ne l'avez pas déjà fait, veuillez lire Comment écrire un message d'engagement Git car c'est une excellente ressource pour écrire des messages d'engagement utiles.

  • Avant de déposer un RP, la "camelote" de citrouille s'engage à garder toute l'histoire propre. Un seul commit devrait couvrir un seul changement significatif: évitez d'écraser toutes vos modifications, en particulier pour les gros RP qui touchent beaucoup de fichiers, mais ne laissez pas non plus «fixe», «whoops typo» s'engage dans l'historique de votre branche car il s'agit d'un encombrement inutile dans l'histoire finale du projet.
  • Écrivez un bon titre qui décrit rapidement ce qui a été changé. Par exemple, «Ajouter la prise en charge LDAP à Jellyfin». Comme mentionné dans Comment écrire un message d'engagement Git, utilisez toujours l'humeur impérative et gardez le titre court mais descriptif. Le titre finira par être une entrée dans le journal des modifications, veuillez donc essayer d'utiliser les majuscules appropriées mais pas de ponctuation; Veuillez noter que l'équipe principale peut modifier les titres pour mieux confirmer cette norme avant de fusionner.
  • Pour tout sauf les changements les plus insignifiants qui peuvent être entièrement décrits dans le titre (court), suivez le modèle de relations publiques et écrivez un organisme de relations publiques pour décrire, avec autant de détails que possible: pourquoi le changements. Si possible, référencez des sujets spécifiques avec des mots clés (correctifs, fermetures, adresses, etc.) Comment le sujet a été traité (le cas échéant) et décrivez brièvement les changements, en particulier pour les gros RP.
  • Si votre demande de retrait n'est pas encore terminée, veuillez la marquer comme "brouillon" lorsque vous l'ouvrez. Tant que cette balise est en place, la demande d'extraction ne sera pas fusionnée et les révisions doivent rester uniquement des commentaires. Une fois que vous êtes satisfait du statut final de votre RP, veuillez supprimer cette balise; L'oublier pourrait faire en sorte que votre RP soit involontairement ignoré comme s'il était encore en développement actif! Les WIP inactifs peuvent parfois amener des pings d'équipe à demander un statut et sont fermés s'il n'y a pas de réponse.
  • Évitez de dépasser et de forcer les demandes de tirage volumineuses ou complexes si possible, et surtout après les correctifs. Force les révisions inutiles à vérifier que les modifications sont toujours correctes et correctement construites.
  • Attendez-vous à un examen et à une discussion. Si vous ne pouvez pas sauvegarder vos modifications avec une bonne description et à travers la révision, veuillez reconsidérer si cela doit être fait du tout. Toutes les relations publiques nécessitent au moins un examen d'approbation par un membre de l'équipe de direction, mais nous accueillons et encourageons les examens de tout contributeur, surtout si c'est dans un domaine que vous connaissez. Plus d'yeux, c'est toujours mieux.
  • Toutes les relations publiques nécessitent l'examen d'au moins deux membres de l'équipe avant d'être fusionnés dans le maître, bien que les commentaires de tout contributeur soient les bienvenus! Après l'examen du deuxième membre de l'équipe, le RP peut être fusionné immédiatement, ou d'autres examens ou commentaires explicitement demandés à d'autres contributeurs si nécessaire.

Nous devons installer toutes les dépendances de développement et extraire le code du conteneur avant de pouvoir compiler et exécuter.

Remarque

Mettez chaque commande sur une ligne distincte. Le conteneur dans lequel nous allons tester est appelé jftest. Dans Docker, chaque fois que l'exécutable du point d'entrée est arrêté, la session redémarre, il suffit donc de la relancer pour continuer. Nous le supprimons donc explicitement pour recharger la nouvelle version.

Branche principale

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 publie Jellyfin. Server --configuration Debug --output = "/ jellyfin" - autonome --runtime linux-x64cd / opt / jellyfin-web && yarn install && yarn build && cp -r / opt / jellyfin-web / dist / jellyfin / jellyfin-webkill -15 $ (pidof jellyfin)

Demande de lancer

Tout d'abord, effectuez les étapes précédentes pour configurer votre conteneur pour créer la branche principale.

Remarque

est le numéro de demande d'extraction sur GitHub.

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

fr_FRFrançais
es_ESEspañol zh_CN简体中文 hi_INहिन्दी arالعربية pt_BRPortuguês do Brasil bn_BDবাংলা ru_RUРусский ja日本語 de_DEDeutsch it_ITItaliano fr_FRFrançais