Zum Inhalt springen

Entwicklung

Auf dieser Seite erfahren Sie, wie unsere Repositorys organisiert sind, wie Sie mit dem Bearbeiten des Codes und dem Erstellen Ihrer ersten Pull-Anfrage beginnen und einige allgemeine Verfahren für Pull-Anfragen in Jellyfin.

Woran solltest du arbeiten?

Es gibt viele Jellyfin-Organisationsprojekte auf Github, die überprüft und dazu beigetragen werden können. Zusammenfassend sind hier die beiden größten, eine für die Hintergrundentwicklungen und eine für die vorderen:

 Entwicklung Entwicklung
  • Jellyfin-Server - Der Back-End-Server der Jellyfin-Anwendung. Es wurde mit .NET Core 3.1 und C# erstellt.
  • Jellyfin Web - Die Hauptanwendung des Jellyfin-Clients. Entwickelt für das Web, aber auch in einigen unserer anderen Clients verwendet, die nur Wrapper dieses Webclients sind.

Beachten Sie, dass jedes der Repositorys auch eine eigene Dokumentation zu den ersten Schritten mit diesem Projekt enthält, die normalerweise im README-Repository enthalten ist. Sie können auch den Quellbaum der Organisation anzeigen, um zu sehen, wie einige der größeren Projekte strukturiert sind.

Der beste Weg, um mit der echten Entwicklung zu beginnen, besteht darin, die Liste der Probleme im zugehörigen Repository durchzugehen, ein Problem zu finden, an dem Sie arbeiten möchten, und mit dem Hacken zu beginnen! Probleme werden regelmäßig vom Managementteam überprüft und Beschriftungen zugewiesen, die Ihnen helfen sollen, Probleme innerhalb Ihrer Fähigkeiten zu finden. Wenn Sie mit der Arbeit an einem Problem beginnen, kommentieren Sie es bitte und geben Sie Ihre Absicht an, an dem Problem zu arbeiten, um unnötige Doppelarbeit zu vermeiden.

Hauptfragetypen

Eine Liste der Fragetypen finden Sie im Abschnitt Fragenrichtlinien.

Was ist, wenn es kein Problem gibt?

Wenn es noch kein Problem mit den Änderungen gibt, die Sie vornehmen möchten, erstellen Sie zunächst ein Problem, um es zu verfolgen, und stellen Sie dann sicher, dass Ihre Öffentlichkeitsarbeit auf das betreffende Problem verweist. Dies ist besonders nützlich für Fehler, die vom Autor gefunden und dann behoben werden, damit sowohl das ursprüngliche Problem als auch das Update detailliert dokumentiert und nachverfolgt werden können.

Wie soll ich die Änderungen vornehmen?

Sobald Sie etwas gefunden haben, an dem Sie arbeiten oder das Sie verbessern möchten, besteht der nächste Schritt darin, Ihre Codeänderungen vorzunehmen, sie zu testen und dann eine Pull-Anfrage (PR) auf GitHub zu senden.

Der Einfachheit halber wird in allen Beispielen davon ausgegangen, dass der Entwickler unter Linux mit SSH-Zugriff auf GitHub arbeitet. Die allgemeinen Ideen können jedoch auf HTTP-basierte GitHub-Schnittstellen angewendet und in Windows oder MacOS übersetzt werden.

Wenn Sie mit Git nicht vertraut sind, empfehlen wir die offizielle Dokumentation, um zu verstehen, wie dieses Versionskontrollsystem funktioniert und wie es verwendet wird.

Bereiten Sie Ihre Kopie des Repos vor

Der erste Schritt besteht darin, eine Kopie des Git-Repositorys des Projekts zu erstellen, zu dem Sie beitragen möchten. Jellyfin folgt einem "Gabel, Features und Public Relations" -Modell für Beiträge.

  1. "Fork" auf GitHub das Jellyfin-Repository, zu dem Sie beitragen möchten, über die Schaltfläche "Fork" des entsprechenden Repositorys in Ihr eigenes Benutzerkonto.
  2. Klonen Sie Ihre Gabel auf Ihrem lokalen Computer und geben Sie das Verzeichnis ein: git clone git@github.com: Ihr Benutzername / Projektname.gitcd Projektname /
  3. Fügen Sie die "Upstream" -Fernbedienung hinzu, mit der Sie Änderungen aus dem Hauptprojekt einfach herunterladen können: git remote Fügen Sie die Upstream-Fernbedienung git@github.com: jellyfin / projectname.git hinzu
  4. Initialisieren Sie die Git-Submodule. Die meisten Projekte haben mindestens ein Git-Submodul-Update - inNotNoteAvoid bearbeiten Dateien innerhalb von Submodulen. Dies kann zu unerwünschten Nebenwirkungen führen, einschließlich des Überschreibens Ihrer Arbeit. Ändern Sie das Submodul immer an einer anderen Stelle in seinem eigenen geklonten Repository.
  5. Damit das Jellyfin.Server-Projekt erfolgreich ausgeführt werden kann, werden sowohl der Server als auch das Webclient-Projekt überprüft.
  6. Erstellen Sie das Jellyfin-Webprojekt mit Yarn oder NPM und kopieren Sie den Speicherort des resultierenden dist-Ordners. Fügen Sie in Ihrem Jellyfin.Server-Projekt eine Umgebungsvariable mit dem Namen JELLYFIN_WEB_DIR hinzu, deren Wert auf den vollständigen Pfad Ihres dist-Ordners festgelegt ist.

Sie können jetzt mit dem Erstellen oder Ändern des Projekts beginnen.

Nehmen Sie Änderungen am Repo vor

Sobald Sie Ihre Anzahlung haben, können Sie an die Arbeit gehen.

  1. Leiten Sie Ihre lokalen Zweige an den Upstream-Master weiter, um mit den neuesten Änderungen zu arbeiten: git fetch –allgit rebase upstream / master
  2. Erstellen Sie einen lokalen Feature-Zweig des Masters, um Ihre Änderungen vorzunehmen: git checkout -b my-feature master
  3. Nehmen Sie Ihre Änderungen und Zusagen in diesem lokalen Feature-Zweig vor.
  4. Wiederholen Sie Schritt 1 in Ihrer Zweigstelle, nachdem Sie Ihre Arbeit beendet haben, um sicherzustellen, dass Sie keine Konflikte mit anderen Arbeiten haben, die seit Ihrer Deklaration ausgeführt wurden.
  5. Laden Sie den lokalen Feature-Zweig auf Ihre GitHub-Gabel hoch: git push –set-upstream origin my-feature
  6. Erstellen Sie auf GitHub ein neues RP für den Updraft-Master-Zweig, indem Sie den folgenden Hinweisen folgen.
  7. Stellen Sie nach dem Zusammenführen Ihres RP sicher, dass Ihre lokalen Niederlassungen auf dem neuesten Stand sind: git fetch –allgit checkout mastergit rebase upstream / mastergit push -u origin master
  8. Löschen Sie den Zweig Ihres lokalen Features, wenn Sie ihn nicht mehr benötigen: git branch -d my-feature

CONTRIBUTORS.md

Wenn Sie zum ersten Mal Code für ein bestimmtes Repository bereitstellen, fügen Sie ihn bitte der Datei CONTRIBUTORS.md am Ende des Abschnitts Jellyfin Contributors hinzu. Obwohl GitHub dem nachgeht, klärt das Schreiben des Dokuments die Dinge auf, wenn der Code GitHub verlässt, und ermöglicht es jedem, schnell zu sehen, wer an dem Projekt für Urheberrecht oder Lob gearbeitet hat!

Offizielle Niederlassungen

Feature-Zweige

Gelegentlich können große Projekte entstehen, die mehrere Öffentlichkeitsarbeit und Beiträge von mehreren Personen erfordern. Für diese Aufgaben müssen funktionsspezifische Feature-Zweige basierend auf dem Master erstellt werden. Dies ermöglicht es, die Arbeit fortzusetzen, ohne den Master für längere Zeit zu beschädigen, und ermöglicht denjenigen, die an diesem bestimmten Projekt interessiert sind, in ihrem eigenen Tempo zu arbeiten, anstatt sich zu beeilen, ein defektes Feature vor der nächsten Version zu reparieren. Um einen Feature-Zweig zu erstellen, wenden Sie sich bitte an ein Mitglied des Kernteams. Dies kann behoben werden.

Sobald das Feature, für das ein Feature-Zweig erstellt wurde, bereit ist, kann es zu einem Take auf dem Master und dem entfernten Feature-Zweig zusammengeführt werden. Alternativ können für sehr lange Lebensdauer bestimmte "stabile" Schnappschüsse nach Bedarf in den Master eingefügt werden.

Die Hauptniederlassung

Der Hauptzweig ist das Hauptgesicht des Projekts und der Hauptentwicklungszweig. Mit Ausnahme von Hotfixes für die Notfallfreigabe muss sich die gesamte Öffentlichkeitsarbeit an den Lehrer richten. In der Regel sollte kein RP den Master beschädigen und alle RP sollten vor dem Zusammenführen getestet werden, um sicherzustellen, dass dies nicht geschieht. Wir sind nur Menschen und dies wird wahrscheinlich passieren, aber im Allgemeinen sollte es sicher sein, vom Master zu bauen, wenn Sie die neueste und beste Version von Jellyfin wollen.

Testen einer Aufforderung zum Schießen

Um die Auszahlungsanforderung einer anderen Person zu testen, müssen Sie die Änderungen in Ihr lokales Repository importieren.

  1. Holen Sie sich die Änderungen in einer Pull-Anfrage und binden Sie sie an einen neuen lokalen Zweig: git fetch upstream pull / / head: my-testing-branchNote ist die Extraktionsanforderungsnummer auf GitHub.
  2. Überprüfen Sie den neuen lokalen Zweig: git überprüfen Sie meinen Testzweig
  3. Führen Sie alle zum Testen erforderlichen Tests oder Builds durch, kehren Sie dann zum Master zurück und löschen Sie den Zweig: git checkout mastergit branch -D my-testing-branch

Richtlinien für Extraktionsanforderungen

Gehen Sie beim Einreichen eines neuen RP wie folgt vor. Wenn Sie dies noch nicht getan haben, lesen Sie bitte Wie man eine Git-Verlobungsnachricht schreibt, da dies eine großartige Ressource zum Schreiben nützlicher Verlobungsnachrichten ist.

  • Vor dem Einreichen eines RP erklärt sich der Kürbis "Junk" damit einverstanden, die gesamte Geschichte sauber zu halten. Ein einzelnes Commit sollte eine einzelne signifikante Änderung abdecken: Vermeiden Sie es, alle Ihre Änderungen zu zerstören, insbesondere bei großen RPs, die viele Dateien berühren, aber lassen Sie auch keine "festen", "Whoops Tippfehler" -Commits in Ihrem Zweigverlauf, da dies ein ist unnötige Unordnung in der letzten Geschichte des Projekts.
  • Schreiben Sie einen guten Titel, der schnell beschreibt, was geändert wurde. Beispiel: "Hinzufügen von LDAP-Unterstützung zu Jellyfin." Verwenden Sie, wie unter Schreiben einer Git-Engagement-Nachricht erwähnt, immer die imperative Stimmung und halten Sie den Titel kurz, aber beschreibend. Der Titel wird eventuell ein Eintrag im Änderungsprotokoll sein. Versuchen Sie daher, die entsprechenden Großbuchstaben zu verwenden, jedoch keine Interpunktion. Bitte beachten Sie, dass das Kernteam die Titel möglicherweise ändern kann, um diesen Standard vor dem Zusammenführen besser zu bestätigen.
  • Befolgen Sie für alles andere als die trivialsten Änderungen, die im (kurzen) Titel vollständig beschrieben werden können, die PR-Vorlage und schreiben Sie einen PR-Text, um ihn so detailliert wie möglich zu beschreiben: Warum sind die Änderungen. Verweisen Sie nach Möglichkeit auf bestimmte Themen mit Schlüsselwörtern (Korrekturen, Abschlüsse, Adressen usw.). Wie das Thema behandelt wurde (falls zutreffend), und beschreiben Sie kurz die Änderungen, insbesondere für große RPs.
  • Wenn Ihre Auszahlungsanforderung noch nicht abgeschlossen ist, markieren Sie sie beim Öffnen als "Entwurf". Solange dieses Tag vorhanden ist, wird die Pull-Anforderung nicht zusammengeführt, und Revisionen sollten nur als Kommentare verbleiben. Wenn Sie mit dem endgültigen Status Ihres RP zufrieden sind, entfernen Sie dieses Tag. Wenn Sie es vergessen, wird Ihr RP möglicherweise unbeabsichtigt ignoriert, als ob es sich noch in der aktiven Entwicklung befindet! Inaktive WIPs können gelegentlich dazu führen, dass Team-Pings nach dem Status fragen. Sie werden geschlossen, wenn keine Antwort erfolgt.
  • Vermeiden Sie nach Möglichkeit ein Überschießen und Erzwingen großer oder komplexer Pull-Anforderungen, insbesondere nach Patches. Erzwingt unnötige Überprüfungen, um zu überprüfen, ob die Änderungen noch in Ordnung sind und ordnungsgemäß erstellt wurden.
  • Erwarten Sie eine Überprüfung und Diskussion. Wenn Sie Ihre Änderungen nicht mit einer guten Beschreibung und durch die Überprüfung sichern können, überlegen Sie bitte, ob dies überhaupt durchgeführt werden sollte. Für jede Öffentlichkeitsarbeit ist mindestens eine Genehmigungsprüfung durch ein Mitglied des Managementteams erforderlich. Wir begrüßen und empfehlen jedoch Überprüfungen durch jeden Mitwirkenden, insbesondere in einem Bereich, den Sie kennen. Mehr Augen sind immer besser.
  • Für jede Öffentlichkeitsarbeit müssen mindestens zwei Teammitglieder überprüft werden, bevor sie in den Master aufgenommen werden. Bewertungen von Mitwirkenden sind jedoch willkommen! Nach der Überprüfung durch das zweite Teammitglied kann die RP sofort zusammengeführt oder bei Bedarf weitere Überprüfungen oder Kommentare ausdrücklich von anderen Mitwirkenden angefordert werden.

Wir müssen alle Entwicklungsabhängigkeiten installieren und den Code aus dem Container holen, bevor wir kompilieren und ausführen können.

Hinweis

Setzen Sie jeden Befehl in eine separate Zeile. Der Container, in dem wir testen werden, heißt jftest. In Docker wird die Sitzung jedes Mal neu gestartet, wenn die ausführbare Einstiegspunktdatei beendet wird. Führen Sie sie daher erneut aus, um fortzufahren. Deshalb töten wir es auch explizit, um die neue Version neu zu laden.

Hauptzweig

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 / Quellen. 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 veröffentlichen Jellyfin. Server --configuration Debug --output = "/ jellyfin" - in sich geschlossen - Laufzeit Linux-x64cd / opt / jellyfin-web && Garninstallation && Garnaufbau && cp -r / opt / jellyfin-web / dist / jellyfin / jellyfin-webkill -15 $ (pidof jellyfin)

Bitte zu werfen

Führen Sie zunächst die vorherigen Schritte aus, um Ihren Container für die Erstellung des Hauptzweigs zu konfigurieren.

Hinweis

ist die Extraktionsanforderungsnummer auf GitHub.

docker exec -ti jftest bashcd / opt / jellyfingit Abrufursprung ziehen /  / head: my-testing-branchgit merge my-testing-branchdotnet zusammen Jellyfin.Server veröffentlichen --configuration Debug --output = "/ jellyfin" - in sich geschlossen --runtime linux-x64kill -15 $ (pidof jellyfin)

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