Desenvolvimento

Esta página detalha como nossos repositórios estão organizados, como começar a editar o código e criar sua primeira solicitação de recebimento e alguns procedimentos gerais sobre solicitações de recebimento no Jellyfin.

No que você deve trabalhar?

Existem muitos projetos de organização Jellyfin no Github para revisar e contribuir. Em resumo, aqui estão os dois maiores, um para os desenvolvimentos anteriores e outro para os anteriores:

• Servidor Jellyfin - O servidor back-end do aplicativo Jellyfin. Ele é criado usando o .NET Core 3.1 e o C#.
• Jellyfin Web - O principal aplicativo cliente do Jellyfin. Criado para a web, mas também usado em alguns de nossos outros clientes que são apenas invólucros desse cliente da web.

Observe que cada um dos repositórios também possui sua própria documentação sobre como iniciar esse projeto, que geralmente é encontrado no repositório README. Você também pode visualizar a árvore de origem da organização para ver como alguns dos projetos maiores estão estruturados.

A melhor maneira de iniciar um desenvolvimento real é percorrer a lista de problemas no repositório associado, encontrar um problema que você gostaria de trabalhar e começar a invadir! Os problemas são revisados regularmente pela equipe de gerenciamento e são atribuídos rótulos que devem ajudá-lo a encontrar problemas em seu conjunto de habilidades. Depois de começar a trabalhar em um problema, comente-o indicando sua intenção de trabalhar no problema, para evitar duplicação desnecessária de trabalho.

Principais tipos de perguntas

Uma lista de tipos de perguntas pode ser encontrada na seção Diretrizes de Perguntas.

E se não houver um problema?

Se ainda não houver um problema relacionado às alterações que você deseja fazer, crie um problema para acompanhá-lo primeiro e verifique se suas relações públicas fazem referência ao problema em questão. Isso é especialmente útil para erros encontrados e corrigidos pelo autor, para que o problema original e a correção possam ser documentados e rastreados em detalhes.

Como devo fazer as alterações?

Depois de encontrar algo em que você deseja trabalhar ou aprimorar, o próximo passo é fazer as alterações no seu código, testá-las e enviar uma solicitação de recebimento (PR) no GitHub.

Para simplificar, todos os exemplos assumem que o desenvolvedor está operando no Linux com acesso SSH ao GitHub, no entanto, as idéias gerais podem ser aplicadas às interfaces do GitHub baseadas em HTTP e traduzidas para Windows ou MacOS.

Se você não conhece o Git, recomendamos a documentação oficial para entender como esse sistema de controle de versão funciona e como usá-lo.

Prepare sua cópia do repositório

A primeira etapa é criar uma cópia do repositório Git do projeto no qual você deseja contribuir. Jellyfin segue um modelo de "garfo, recursos e relações públicas" para contribuições.

1. No GitHub, "Garfo" o repositório Jellyfin para o qual você deseja contribuir, para sua própria conta de usuário usando o botão "Garfo" do repositório correspondente.
2. Clone seu fork na máquina local e digite o diretório: git clone git@github.com: nome_do_usuário / nome_do_projeto.gitcd nome_do_projeto /
3. Adicione o controle remoto "upstream", que permite baixar facilmente as alterações do projeto principal: git remote adicione upstream git@github.com: jellyfin / projectname.git
4. Inicialize os submódulos do Git; a maioria dos projetos tem pelo menos uma atualização do sub-módulo Git - noNoteNoteEvite a edição de arquivos nos sub-módulos. Fazer isso pode resultar em efeitos colaterais indesejados, incluindo a substituição do seu trabalho. Sempre modifique o submódulo em seu próprio repositório clonado em outro local.
5. Para que o projeto Jellyfin.Server seja executado com êxito, ele verifica o projeto do servidor e do web client.
6. Crie o projeto Jellyfin Web com Yarn ou NPM e copie o local da pasta dist resultante. No seu projeto Jellyfin.Server, adicione uma variável de ambiente chamada JELLYFIN_WEB_DIR com o valor definido para o caminho completo da sua pasta dist.

Agora você está pronto para começar a criar ou modificar o projeto.

Faça alterações no repositório

Depois de ter seu depósito, você pode começar a trabalhar.

1. Retransmitir suas ramificações locais contra o mestre upstream para trabalhar com as alterações mais recentes: git fetch - allgit rebase upstream / master
2. Crie uma ramificação de recurso local do mestre para fazer suas alterações: git checkout -b my-feature master
3. Faça suas alterações e compromissos neste ramo de recursos local.
4. Repita a etapa 1 na filial local depois de concluir o trabalho, para garantir que você não tenha conflitos com outros trabalhos realizados desde que você declarou.
5. Faça o upload da ramificação do recurso local para seu fork do GitHub: git push –set-upstream origin my-feature
6. No GitHub, crie um novo RP no ramo mestre de atualização seguindo as recomendações abaixo.
7. Depois que o RP for mesclado, mantenha suas ramificações locais atualizadas: git fetch - allgit checkout mastergit rebase upstream / mastergit push -u origin master
8. Exclua a ramificação do seu recurso local se você não precisar mais dele: git branch -d my-feature

CONTRIBUTORS.md

Se esta é a primeira vez que você contribui com código para um repositório específico, adicione-o ao arquivo CONTRIBUTORS.md no final da seção Contribuintes do Jellyfin. Embora o GitHub continue com isso, ter o documento escrito esclarece tudo se o código sair do GitHub e permite que todos vejam rapidamente quem trabalhou no projeto por direitos autorais ou elogios!

Agências oficiais

Ramos de recursos

Ocasionalmente, podem surgir grandes projetos que requerem múltiplas relações públicas e contribuições de várias pessoas. Para essas tarefas, as ramificações de recurso específicas do recurso devem ser criadas com base no mestre. Isso ajuda a permitir que o trabalho continue sem interromper o mestre por longos períodos e permite que os interessados nesse projeto em particular possam trabalhar no seu próprio ritmo, em vez de se apressarem em corrigir um recurso quebrado antes do próximo lançamento. Para criar uma ramificação de recursos, entre em contato com um membro da equipe Principal e isso pode ser corrigido.

Quando o recurso para o qual uma ramificação de recurso foi criada estiver pronto, ele poderá ser mesclado em uma tomada na mestre e na ramificação de recurso removida. Como alternativa, para características de vida útil muito longa, determinados instantâneos "estáveis" podem ser mesclados no mestre, conforme necessário.

O ramo principal

O ramo principal é a face principal do projeto e o principal ramo de desenvolvimento. Exceto nos hotfixes de liberação de emergência, todas as relações públicas devem ter como alvo o professor. Como regra geral, nenhum RP deve quebrar o mestre e todo o RP deve ser testado antes da mesclagem para garantir que isso não aconteça. Somos apenas humanos e é provável que isso aconteça, mas em geral deve ser seguro construir com o mestre, se você quiser a versão mais recente e melhor do Jellyfin.

Testando uma solicitação para fotografar

Para testar a solicitação de retirada de outra pessoa, você deve importar as alterações no seu repositório local.

1. Obtenha as alterações em uma solicitação pull e vincule-as a uma nova ramificação local: git fetch upstream pull / / head: my-testing-branchNote é o número da solicitação de extração no GitHub.
2. Verifique o novo ramo local: git, verifique o meu ramo de testes
3. Execute todos os testes ou construções necessários para o teste e, em seguida, volte para o mestre e exclua a ramificação: git checkout mastergit branch -D my-testing-branch

Diretrizes para solicitação de extração

Ao enviar um novo RP, faça o seguinte. Se você ainda não o fez, leia Como escrever uma mensagem de compromisso do Git, pois é um ótimo recurso para escrever mensagens úteis de compromisso.

• Antes de registrar um RP, o "lixo" da abóbora concorda em manter a história geral limpa. Um único commit deve cobrir uma única mudança significativa: evite esmagar todas as suas alterações, especialmente para RPs grandes que tocam muitos arquivos, mas também não deixam 'fixos', 'erros de digitação' confirmam no histórico de suas ramificações, pois é um confusão desnecessária na história final do projeto.
• Escreva um bom título que descreva rapidamente o que foi alterado. Por exemplo, "Adicionar suporte LDAP ao Jellyfin". Conforme mencionado em Como escrever uma mensagem de compromisso do Git, sempre use o humor imperativo e mantenha o título curto, mas descritivo. O título eventualmente será uma entrada no changelog; portanto, tente usar as letras maiúsculas apropriadas, mas sem pontuação; Observe que a equipe principal pode alterar os títulos para confirmar melhor esse padrão antes da fusão.
• Para qualquer coisa, exceto as mudanças mais triviais que podem ser totalmente descritas no título (curto), siga o modelo de relações públicas e escreva um órgão de relações públicas para descrever, com o máximo de detalhes possível: Por que o mudanças. Faça referência a tópicos específicos com palavras-chave (correções, fechamentos, endereços etc.), se possível.Como o tópico foi abordado (se aplicável) e descreva brevemente as alterações, especialmente para grandes RPs.
• Se o seu pedido de retirada ainda não tiver sido concluído, marque-o como "rascunho" quando você o abrir. Enquanto essa tag estiver em vigor, a solicitação de recebimento não será mesclada e as revisões deverão permanecer apenas como comentários. Quando estiver satisfeito com o status final do seu RP, remova esta tag; Esquecer isso pode resultar em seu RP ser acidentalmente ignorado como se ainda estivesse em desenvolvimento ativo! WIPs inativos podem ocasionalmente fazer com que os pings da equipe solicitem status e são fechados se não houver resposta.
• Evite ultrapassar e forçar solicitações de recebimento grandes ou complexas, se possível, e principalmente após as correções. Força revisões desnecessárias para verificar se as alterações ainda estão corretas e foram criadas corretamente.
• Espere uma revisão e discussão. Se você não conseguir fazer o backup de suas alterações com uma boa descrição e com a revisão, reconsidere se isso deve ser feito. Todas as relações públicas exigem pelo menos uma revisão de aprovação por um membro da equipe de gerenciamento. No entanto, agradecemos e incentivamos as revisões de qualquer colaborador, especialmente se estiver em uma área que você conhece. Mais olhos são sempre melhores.
• Todas as relações públicas exigem a revisão de pelo menos dois membros da equipe antes de serem incorporadas ao mestre, embora as revisões de qualquer colaborador sejam bem-vindas! Após a revisão do segundo membro da equipe, o PR pode ser mesclado imediatamente, ou mais revisões ou comentários solicitados explicitamente a outros colaboradores, se necessário.

Precisamos instalar todas as dependências de desenvolvimento e retirar o código do contêiner antes que possamos compilar e executar.

Nota

Coloque cada comando em uma linha separada. O contêiner no qual testaremos é chamado jftest. Dentro do Docker, toda vez que o executável do ponto de entrada é finalizado, a sessão é reiniciada; basta executá-lo novamente para continuar. Por isso, também o matamos explicitamente para recarregar a nova versão.

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

Pedido para jogar

Primeiro, conclua as etapas anteriores para configurar seu contêiner para criar a ramificação principal.

Nota

é o número da solicitação de extração no GitHub.

docker exec -ti jftest bashcd / opt / jellyfingit buscar origem pull /  / head: my-testing-branchgit mescla my-testing-branchdotnet publica Jellyfin.Server --configuration Debug --output = "/ jellyfin" - independente - tempo de execução linux-x64kill -15 $ (pidof jellyfin)