перейти к содержанию

развитие

На этой странице подробно рассказывается о том, как организованы наши репозитории, как начать редактирование кода и создание вашего первого пул-запроса, а также некоторые общие процедуры по пул-запросам в Jellyfin.

Над чем работать?

На Github есть множество проектов организации Jellyfin, которые можно рассмотреть и внести свой вклад. Подводя итог, вот два самых больших, один для фоновых разработок и один для передовых:

<figcaption class=развитие"width =" 832 "height =" 451 "/>развитие
  • Jellyfin Server - Внутренний сервер приложения Jellyfin. Он построен с использованием .NET Core 3.1 и C#.
  • Jellyfin Web - основное клиентское приложение Jellyfin. Создан для Интернета, но также используется в некоторых других наших клиентах, которые являются просто оболочками этого веб-клиента.

Обратите внимание, что каждый из репозиториев также имеет свою собственную документацию о том, как начать работу с этим проектом, которая обычно находится в репозитории README. Вы также можете просмотреть исходное дерево организации, чтобы увидеть, как структурированы некоторые крупные проекты.

Лучший способ начать реальную разработку - это просмотреть список проблем в соответствующем репозитории, найти проблему, над которой вы хотели бы поработать, и начать взламывать! Проблемы регулярно рассматриваются командой управления, и присваиваются метки, которые должны помочь вам найти проблемы в вашем наборе навыков. Как только вы начнете работать над проблемой, пожалуйста, прокомментируйте ее, указав свое намерение работать над проблемой, чтобы избежать ненужного дублирования работы.

Основные типы вопросов

Список типов вопросов можно найти в разделе «Рекомендации по вопросам».

Что делать, если нет проблемы?

Если проблема, связанная с изменениями, которые вы хотите внести, еще не возникла, сначала создайте проблему, чтобы отследить ее, а затем убедитесь, что ваши пиар-службы ссылаются на данную проблему. Это особенно полезно для ошибок, которые были найдены и затем исправлены автором, так что исходная проблема и исправление могут быть задокументированы и детально отслежены.

Как мне внести изменения?

После того, как вы нашли что-то, над чем хотите поработать или улучшить, следующий шаг - внести изменения в код, протестировать их, а затем отправить запрос на загрузку (PR) на GitHub.

Для простоты во всех примерах предполагается, что разработчик работает в Linux с SSH-доступом к GitHub, однако общие идеи могут быть применены к интерфейсам GitHub на основе HTTP и могут быть переведены в Windows или MacOS.

Если вы не знакомы с Git, мы рекомендуем официальную документацию, чтобы понять, как работает эта система контроля версий и как ее использовать.

Подготовьте свою копию репо

Первым шагом является создание копии Git-репозитория проекта, в который вы хотите внести свой вклад. Джеллифин следует модели «вилка, функции и связи с общественностью» для взносов.

  1. На GitHub, «Fork», репозиторий Jellyfin, в который вы хотите добавить свою учетную запись пользователя, используя кнопку «Fork» соответствующего репозитория.
  2. Клонируйте ваш форк на локальном компьютере и введите каталог: git clone git@github.com: имя пользователя / имя_проекта.gitcd имя_проекта /
  3. Добавьте удаленный «upstream», который позволяет вам легко загружать изменения из основного проекта: git remote add upstream git@github.com: jellyfin / projectname.git
  4. Инициализировать подмодули Git; В большинстве проектов есть хотя бы одно обновление подмодуля Git - initNoteAvoid, редактирующее файлы внутри подмодулей. Это может привести к нежелательным побочным эффектам, включая перезапись вашей работы. Всегда изменяйте подмодуль в своем собственном клонированном репозитории в другом месте.
  5. Для успешного выполнения проекта Jellyfin.Server проверяются как сервер, так и проект веб-клиента.
  6. Создайте веб-проект Jellyfin с помощью Yarn или NPM и скопируйте расположение получившейся папки dist. В вашем проекте Jellyfin.Server добавьте переменную среды с именем JELLYFIN_WEB_DIR со значением, указанным для полного пути к вашей папке dist.

Теперь вы готовы начать сборку или изменение проекта.

Внести изменения в репо

Как только вы получите депозит, вы можете приступить к работе.

  1. Переведите ваши локальные ветки на ведущий модуль для работы с последними изменениями: git fetch –allgit rebase upstream / master
  2. Создайте локальную ветвь функций мастера для внесения изменений: git checkout -b my-feature master
  3. Внесите свои изменения и обязательства в этой локальной ветви функций.
  4. Повторите шаг 1 в своем местном филиале после того, как вы закончите свою работу, чтобы убедиться, что у вас нет конфликтов с другой работой, выполненной с момента вашего объявления.
  5. Загрузите локальную ветвь функций на свою ветвь GitHub: git push –set-upstream origin my-feature
  6. На GitHub создайте новый RP для основной ветки updraft, следуя приведенным ниже советам.
  7. После слияния RP обязательно обновляйте локальные ветки: git fetch –allgit checkout mastergit rebase upstream / mastergit push -u origin master
  8. Удалите ветку вашей локальной функции, если она вам больше не нужна: git branch -d my-feature

CONTRIBUIDORES.md

Если вы впервые вносите код в конкретный репозиторий, добавьте его в файл CONTRIBUTORS.md в конце раздела Jellyfin Contributors. Хотя GitHub следит за этим, написанный документ проясняет ситуацию, если код покидает GitHub, и позволяет всем быстро увидеть, кто работал над проектом, за авторские права или похвалу!

Официальные филиалы

Особые ветки

Иногда могут появляться крупные проекты, которые требуют многочисленных связей с общественностью и участия множества людей. Для этих задач должны быть созданы ветви функций для конкретных функций на основе мастера. Это позволяет продолжить работу, не ломая мастера в течение длительных периодов, и дает возможность тем, кто заинтересован в этом конкретном проекте, возможность работать в своем собственном темпе, вместо того чтобы спешить исправлять нарушенную функцию перед следующим выпуском. Чтобы создать функциональную ветку, пожалуйста, свяжитесь с членом основной группы, и это можно исправить.

Как только объект, для которого была создана ветвь объекта, готов, его можно объединить в один дубль главной ветки и удаленной ветви объекта. В качестве альтернативы, для характеристик с очень долгим сроком службы определенные «стабильные» снимки могут быть объединены в мастер по мере необходимости.

Мастер Филиал

Мастер ветвь является основным лицом проекта и основной ветвью развития. За исключением исправлений аварийного выпуска, все связи с общественностью должны быть направлены на учителя. Как правило, ни один RP не должен нарушать мастер, и все RP должны быть проверены перед объединением, чтобы убедиться, что этого не произойдет. Мы всего лишь люди, и это, скорее всего, произойдет, но в целом его можно безопасно строить из мастера, если вы хотите самую последнюю и лучшую версию Jellyfin.

Тестирование запроса на съемку

Чтобы проверить чей-либо запрос на вывод средств, вы должны импортировать изменения в свой локальный репозиторий.

  1. Получите изменения в запросе pull и привяжите их к новой локальной ветке: git fetch upstream pull / / head: my-testing-branchNote номер запроса на извлечение на GitHub.
  2. Проверьте новую локальную ветку: git проверьте мою ветку тестирования
  3. Выполните любые тесты или сборки, необходимые для тестирования, затем вернитесь к мастеру и удалите ветку: git checkout mastergit branch -D my-testing-branch

Рекомендации по извлечению

При отправке нового RP обязательно сделайте следующее. Если вы еще этого не сделали, прочитайте, как написать сообщение об участии в Git, так как это отличный ресурс для написания полезных сообщений о взаимодействии.

  • Перед подачей RP тыквенный «мусор» соглашается сохранить общую историю чистой. Одна фиксация должна охватывать одно существенное изменение: избегать дробления всех ваших изменений, особенно для больших RP, которые затрагивают много файлов, но также не оставляют «фиксированные», коммиты «опечатка» в истории веток, так как это ненужный беспорядок в финальной истории проекта.
  • Напишите хороший заголовок, который быстро описывает, что было изменено. Например, «Добавить поддержку LDAP в Jellyfin». Как упомянуто в «Как написать сообщение об участии в Git», всегда используйте императивное настроение и держите заголовок коротким, но описательным. Заголовок в конце концов станет записью в журнале изменений, поэтому, пожалуйста, попробуйте использовать соответствующие заглавные буквы, но без знаков препинания; Обратите внимание, что основная команда может изменить названия, чтобы лучше подтвердить этот стандарт перед объединением.
  • Для всего, кроме самых тривиальных изменений, которые могут быть полностью описаны в (коротком) заголовке, следуйте шаблону PR и напишите тело PR, чтобы описать как можно более подробно: Почему меняется. Если возможно, укажите ссылки на конкретные темы с ключевыми словами (исправления, закрытия, адреса и т. Д.) Как эта тема была рассмотрена (если применимо), и кратко опишите изменения, особенно для больших RP.
  • Если ваш запрос на снятие еще не завершен, пожалуйста, пометьте его как «черновик» при его открытии. Пока этот тег установлен, запрос на извлечение не будет объединен, и редакции должны оставаться только комментариями. Если вы удовлетворены окончательным статусом вашей RP, пожалуйста, удалите этот тег; Если вы забудете об этом, ваш RP будет непреднамеренно проигнорирован, как если бы он все еще находился в активной разработке! Неактивные WIP могут иногда вызывать команды команды для запроса статуса и закрываются, если нет ответа.
  • Избегайте превышения и форсирования больших или сложных запросов по запросу, если это возможно, особенно после исправлений. Вызывает ненужные проверки, чтобы убедиться, что изменения все еще в порядке и правильно построены.
  • Ожидайте обзора и обсуждения. Если вы не можете подтвердить свои изменения хорошим описанием и обзором, пожалуйста, пересмотрите, следует ли это делать вообще. Все связи с общественностью требуют как минимум одного одобрения со стороны члена управленческой команды, однако мы приветствуем и поощряем отзывы со стороны любого участника, особенно если он находится в той области, которую вы знаете. Больше глаз всегда лучше.
  • Все связи с общественностью требуют проверки как минимум двух членов команды, прежде чем они будут объединены с мастером, хотя отзывы от любого участника приветствуются! После рассмотрения вторым членом команды RP может быть немедленно объединен, или, если необходимо, дополнительные обзоры или комментарии явно запрашиваются у других участников.

Нам нужно установить все зависимости разработки и извлечь код из контейнера, прежде чем мы сможем скомпилировать и запустить.

примечание

Поместите каждую команду в отдельной строке. Контейнер, в котором мы будем тестировать, называется jftest. Внутри Docker каждый раз, когда исполняемый файл точки входа завершается, сеанс перезапускается, поэтому просто запустите его снова, чтобы продолжить. Таким образом, мы также явно убиваем его, чтобы перезагрузить новую версию.

Мастер Филиал

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" | тройник / 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 опубликовать Jellyfin. Сервер --configuration Debug --output = "/ jellyfin" - Самостоятельно --runtime linux-x64cd / opt / jellyfin-web && yarn install && сборка пряжи && cp -r / opt / jellyfin-web / dist / jellyfin / jellyfin-webkill -15 $ (пидоф желефин)

Просьба скинуть

Сначала выполните предыдущие шаги, чтобы сконфигурировать ваш контейнер для построения главной ветки.

примечание

номер запроса на извлечение на GitHub.

docker exec -ti jftest bashcd / opt / jellyfingit извлечение происхождения  / head: my-testing-branchgit merge my-testing-branchdotnet опубликовать Jellyfin.Server --configuration Debug --output = "/ jellyfin" - самодостаточный --runtime linux-x64kill -15 $ (pidof jellyfin)

ru_RUРусский