sviluppo

Questa pagina descrive in dettaglio come sono organizzati i nostri repository, come iniziare a modificare il codice e creare la tua prima richiesta pull e alcune procedure generali sulle richieste pull in Jellyfin.

Su cosa dovresti lavorare?

Ci sono molti progetti di organizzazione Jellyfin su Github da rivedere e contribuire. Riassumendo, ecco i due più grandi, uno per gli sviluppi in background e uno per quelli anteriori:

• Jellyfin Server: il server back-end dell'applicazione Jellyfin. È costruito utilizzando .NET Core 3.1 e C#.
• Jellyfin Web - La principale applicazione client Jellyfin. Costruito per il Web, ma utilizzato anche in alcuni dei nostri altri client che sono solo wrapper di questo client Web.

Si noti che ciascuno dei repository ha anche la propria documentazione su come iniziare con quel progetto, che di solito si trova nel repository README. Puoi anche visualizzare l'albero dei sorgenti dell'organizzazione per vedere come sono strutturati alcuni dei progetti più grandi.

Il modo migliore per iniziare lo sviluppo reale è quello di esaminare l'elenco dei problemi nel repository associato, trovare un problema su cui ti piacerebbe lavorare e iniziare l'hacking! I problemi vengono esaminati regolarmente dal team di gestione e vengono assegnate etichette che dovrebbero aiutarti a trovare problemi all'interno del tuo set di abilità. Una volta che inizi a lavorare su un problema, commentalo indicando la tua intenzione di lavorare sul problema, per evitare inutili duplicazioni di lavoro.

Principali tipi di domande

Un elenco di tipi di domande è disponibile nella sezione Linee guida per le domande.

E se non ci fosse un problema?

Se non c'è già un problema relativo alle modifiche che desideri apportare, crea un problema per rintracciarlo prima, quindi assicurati che le tue pubbliche relazioni facciano riferimento al problema in questione. Ciò è particolarmente utile per gli errori rilevati e quindi corretti dall'autore, in modo che sia il problema originale sia la correzione possano essere documentati e monitorati in dettaglio.

Come devo apportare le modifiche?

Una volta trovato qualcosa su cui vuoi lavorare o migliorare, il passaggio successivo è apportare modifiche al codice, testarle e quindi inviare una richiesta pull (PR) su GitHub.

Per semplicità, tutti gli esempi presuppongono che lo sviluppatore stia operando su Linux con accesso SSH a GitHub, tuttavia le idee generali possono essere applicate alle interfacce GitHub basate su HTTP e possono essere tradotte in Windows o MacOS.

Se non hai familiarità con Git, ti consigliamo la documentazione ufficiale per capire come funziona questo sistema di controllo della versione e come usarlo.

Prepara la tua copia del repository

Il primo passo è creare una copia del repository Git del progetto a cui vuoi contribuire. Jellyfin segue un modello "fork, caratteristiche e pubbliche relazioni" per i contributi.

1. Su GitHub, "Fork" il repository Jellyfin a cui si desidera contribuire, al proprio account utente utilizzando il pulsante "Fork" del repository corrispondente.
2. Clona il tuo fork sul tuo computer locale ed inserisci la directory: git clone git@github.com: nome utente / nome progetto.gitcd nome progetto /
3. Aggiungi il telecomando "upstream", che ti consente di scaricare facilmente le principali modifiche del tuo progetto: git remote aggiungi upstream git@github.com: jellyfin / projectname.git
4. Inizializza i sottomoduli Git; la maggior parte dei progetti ha almeno un aggiornamento del sottomodulo Git –initNoteEvita la modifica dei file all'interno dei sottomoduli. Ciò può provocare effetti collaterali indesiderati, inclusa la sovrascrittura del lavoro. Modificare sempre il sottomodulo nel proprio repository clonato altrove.
5. Affinché il progetto Jellyfin.Server venga eseguito correttamente, controlla sia il progetto server che il client Web.
6. Costruisci il progetto Jellyfin Web con Yarn o NPM e copia il percorso della cartella dist risultante. Nel tuo progetto Jellyfin.Server aggiungi una variabile d'ambiente chiamata JELLYFIN_WEB_DIR con il valore impostato sul percorso completo della cartella dist.

Ora sei pronto per iniziare a costruire o modificare il progetto.

Apporta modifiche al repository

Una volta che hai il tuo deposito, puoi metterti al lavoro.

1. Inoltra le tue filiali locali al master upstream per lavorare con le ultime modifiche: git fetch –allgit rebase upstream / master
2. Crea un ramo di funzionalità locale del master per apportare le modifiche: git checkout -b my-feature master
3. Apporta le tue modifiche e impegni in questo ramo di funzionalità locale.
4. Ripeti il passaggio 1 presso la tua filiale locale dopo aver terminato il tuo lavoro, per assicurarti di non avere conflitti con altri lavori svolti da quando hai dichiarato.
5. Carica il ramo di funzionalità locale sul tuo fork di GitHub: git push –set-upstream origin my-feature
6. Su GitHub, crea un nuovo RP sul ramo master di updraft seguendo i consigli di seguito.
7. Una volta che il tuo RP si unisce, assicurati di mantenere aggiornati i tuoi rami locali: git fetch –allgit checkout mastergit rebase upstream / mastergit push -u origin master
8. Elimina il ramo della tua funzione locale se non ti serve più: git branch -d my-feature

CONTRIBUIDORES.md

Se è la prima volta che contribuisci con il codice a un determinato repository, aggiungilo al file CONTRIBUTORS.md alla fine della sezione Jellyfin Contributors. Sebbene GitHub dia seguito a questo, avere il documento scritto chiarisce se il codice lascia GitHub e consente a tutti di vedere rapidamente chi ha lavorato al progetto per copyright o elogi!

Filiali ufficiali

Rami delle caratteristiche

Occasionalmente, possono emergere grandi progetti che richiedono più relazioni pubbliche e contributi da più persone. Per queste attività, i rami delle caratteristiche specifici delle funzioni devono essere creati in base al master. Ciò consente al lavoro di procedere senza interrompere il master per lunghi periodi e consente a coloro che sono interessati a quel particolare progetto la capacità di lavorare al proprio ritmo anziché affrettarsi a riparare una funzionalità interrotta prima della prossima versione. Per creare un ramo di funzionalità, si prega di contattare un membro del team Core e che può essere risolto.

Una volta che la funzione per la quale è stato creato un ramo di funzionalità è pronta, può essere unita in un take sul master e sul ramo di funzionalità rimosso. In alternativa, per caratteristiche di durata molto lunga, alcune istantanee "stabili" possono essere unite nel master come richiesto.

The Master Branch

Il ramo principale è la faccia principale del progetto e il ramo di sviluppo principale. Ad eccezione degli hotfix di rilascio di emergenza, tutte le pubbliche relazioni devono essere indirizzate all'insegnante. Come regola generale, nessun RP dovrebbe rompere il master e tutti i RP dovrebbero essere testati prima della fusione per assicurarsi che ciò non accada. Siamo solo umani e questo probabilmente accadrà, ma in generale dovrebbe essere sicuro costruire dal master se si desidera l'ultima e la più grande versione di Jellyfin.

Test di una richiesta per sparare

Per testare la richiesta di prelievo di qualcun altro, è necessario importare le modifiche nel proprio repository locale.

1. Ottieni le modifiche in una richiesta pull e associale a un nuovo ramo locale: git fetch upstream pull / / head: my-testing-branchNote è il numero della richiesta di estrazione su GitHub.
2. Controlla la nuova filiale locale: controlla il mio ramo di prova
3. Esegui tutti i test o le build necessarie per testare, quindi torna al master ed elimina il ramo: git checkout mastergit branch -D my-testing-branch

Linee guida per le richieste di estrazione

Quando invii un nuovo RP, assicurati di fare quanto segue. Se non lo hai già fatto, leggi Come scrivere un messaggio di coinvolgimento di Git poiché è un'ottima risorsa per scrivere utili messaggi di coinvolgimento.

• Prima di presentare un RP, la "spazzatura" di zucca si impegna a mantenere pulita la storia generale. Un singolo commit dovrebbe coprire un singolo cambiamento significativo: evita di schiacciare tutte le tue modifiche, specialmente per RP di grandi dimensioni che toccano molti file, ma non lasciano 'fixed', 'whoops typo' commette nella cronologia delle filiali in quanto questo è un disordine inutile nella storia finale del progetto.
• Scrivi un buon titolo che descriva rapidamente ciò che è stato modificato. Ad esempio, "Aggiungi il supporto LDAP a Jellyfin". Come menzionato in Come scrivere un messaggio di coinvolgimento di Git, usa sempre l'umore imperativo e mantieni il titolo breve ma descrittivo. Il titolo alla fine sarà una voce nel registro delle modifiche, quindi prova a utilizzare le maiuscole appropriate ma nessuna punteggiatura; Si noti che il team principale può modificare i titoli per confermare meglio questo standard prima della fusione.
• Per tutto tranne i cambiamenti più banali che possono essere completamente descritti nel (breve) titolo, seguire il modello di pubbliche relazioni e scrivere un organismo di pubbliche relazioni per descrivere, nel modo più dettagliato possibile: perché cambia. Se possibile, fai riferimento ad argomenti specifici con parole chiave (correzioni, chiusure, indirizzi, ecc.) Come l'argomento è stato affrontato (se applicabile) e descrivi brevemente le modifiche, specialmente per i grandi RP.
• Se la tua richiesta di prelievo non è ancora terminata, contrassegnala come "bozza" quando la apri. Finché questo tag è attivo, la richiesta pull non verrà unita e le revisioni dovrebbero rimanere solo come commenti. Una volta che sei soddisfatto dello stato finale del tuo RP, rimuovi questo tag; Dimenticarlo potrebbe far sì che il tuo RP venga ignorato involontariamente come se fosse ancora in fase di sviluppo attivo! I WIP inattivi possono occasionalmente far sì che i ping del team richiedano lo stato e vengono chiusi in caso di mancata risposta.
• Se possibile, evita il superamento e la forzatura di richieste pull estese o complesse, soprattutto dopo le patch. Forza revisioni non necessarie per verificare che le modifiche siano ancora valide e che siano state costruite correttamente.
• Aspettati una recensione e una discussione. Se non è possibile eseguire il backup delle modifiche con una buona descrizione e tramite la revisione, si prega di riconsiderare se dovrebbe essere fatto affatto. Tutte le pubbliche relazioni richiedono almeno una revisione di approvazione da parte di un membro del team di gestione, tuttavia accogliamo e incoraggiamo le revisioni da parte di qualsiasi collaboratore, soprattutto se si trova in un'area che conosci. Più occhi sono sempre migliori.
• Tutte le pubbliche relazioni richiedono la revisione di almeno due membri del team prima di essere incorporate nel master, anche se le recensioni di qualsiasi collaboratore sono benvenute! Dopo la revisione del secondo membro del team, l'RP può essere unito immediatamente o, se necessario, ulteriori recensioni o commenti esplicitamente richiesti da altri collaboratori.

Dobbiamo installare tutte le dipendenze di sviluppo ed estrarre il codice dal contenitore prima di poterlo compilare ed eseguire.

nota

Metti ciascun comando su una riga separata. Il contenitore in cui testeremo si chiama jftest. All'interno di Docker, ogni volta che termina l'eseguibile del punto di ingresso, la sessione si riavvia, quindi esegui nuovamente per continuare. Quindi lo uccidiamo esplicitamente per ricaricare la nuova versione.

Master Branch

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

Richiesta di lancio

Innanzitutto, completa i passaggi precedenti per configurare il contenitore per creare il ramo principale.

nota

è il numero della richiesta di estrazione su GitHub.

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