التنمية

تعرض هذه الصفحة تفاصيل كيفية تنظيم مستودعاتنا ، وكيفية البدء في تحرير الرمز وإنشاء طلب السحب الأول ، وبعض الإجراءات العامة المتعلقة بطلبات السحب في Jellyfin.

ما الذي يجب أن تعمل عليه؟

هناك الكثير من مشاريع منظمة Jellyfin على Github لمراجعتها والمساهمة فيها. تلخيص ، فيما يلي أكبر اثنين ، واحد للتطورات الخلفية والآخر للواجهة الأمامية:

• Jellyfin Server - الخادم الخلفي لتطبيق Jellyfin. تم تصميمه باستخدام .NET Core 3.1 و C#.
• Jellyfin Web - تطبيق العميل Jellyfin الرئيسي. مصمم للويب ، ولكنه يستخدم أيضًا في بعض عملائنا الآخرين الذين هم مجرد أغلفة لعميل الويب هذا.

لاحظ أن كل مستودعات لديها أيضًا وثائقها الخاصة حول كيفية البدء في هذا المشروع ، والتي توجد عادةً في مستودع README. يمكنك أيضًا عرض شجرة مصادر المؤسسة لمعرفة كيفية هيكلة بعض المشاريع الكبيرة.

أفضل طريقة لبدء التطوير الحقيقي هي من خلال مراجعة قائمة المشاكل في المستودع المرتبط ، والعثور على مشكلة ترغب في العمل عليها ، وبدء القرصنة! تتم مراجعة المشاكل بانتظام من قبل فريق الإدارة ، ويتم تعيين العلامات التي يجب أن تساعدك في العثور على المشاكل في مجموعة المهارات الخاصة بك. بمجرد البدء في العمل على مشكلة ما ، يرجى التعليق عليها للإشارة إلى نيتك العمل على حل المشكلة ، لتجنب الازدواجية غير الضرورية في العمل.

أنواع الأسئلة الرئيسية

يمكن العثور على قائمة بأنواع الأسئلة في قسم إرشادات السؤال.

ماذا لو لم تكن هناك مشكلة؟

إذا لم تكن هناك بالفعل مشكلة تتعلق بالتغييرات التي تريد إجراؤها ، فالرجاء إنشاء مشكلة لتتبعها أولاً ، ثم تأكد من أن علاقاتك العامة تشير إلى المشكلة المعنية. هذا مفيد بشكل خاص للأخطاء التي تم العثور عليها ثم إصلاحها من قبل المؤلف ، بحيث يمكن توثيق كل من المشكلة الأصلية والإصلاح وتتبعها بالتفصيل.

كيف يمكنني إجراء التغييرات؟

بمجرد العثور على شيء تريد العمل عليه أو تحسينه ، فإن الخطوة التالية هي إجراء تغييرات على التعليمات البرمجية واختبارها ، ثم إرسال طلب سحب (PR) على GitHub.

من أجل البساطة ، تفترض جميع الأمثلة أن المطور يعمل على Linux مع وصول SSH إلى GitHub ، ولكن يمكن تطبيق الأفكار العامة على واجهات GitHub القائمة على HTTP ، ويمكن ترجمتها إلى Windows أو MacOS.

إذا لم تكن على دراية بـ Git ، فنحن نوصي بالوثائق الرسمية لفهم كيفية عمل نظام التحكم في الإصدار وكيفية استخدامه.

جهز نسختك من الريبو

الخطوة الأولى هي إنشاء نسخة من مستودع Git للمشروع الذي تريد المساهمة فيه. يتبع Jellyfin نموذج "الشوكة والميزات والعلاقات العامة" للمساهمات.

1. على GitHub ، "Fork" ، مستودع Jellyfin الذي ترغب في المساهمة فيه ، لحساب المستخدم الخاص بك باستخدام زر "Fork" في المستودع المقابل.
2. انسخ شوكة على جهازك المحلي وأدخل الدليل: git clone git@github.com: yourusername / projectname.gitcd projectname /
3. أضف جهاز التحكم عن بُعد "upstream" ، والذي يتيح لك تنزيل التغييرات بسهولة من المشروع الرئيسي: git remote أضف upstream git@github.com: jellyfin / projectname.git
4. تهيئة الوحدات الفرعية Git ؛ تحتوي معظم المشاريع على تحديث واحد على الأقل لوحدة Git الفرعية –initNoteAvoid تحرير الملفات داخل الوحدات الفرعية. يمكن أن يؤدي القيام بذلك إلى آثار جانبية غير مرغوب فيها ، بما في ذلك استبدال عملك. قم دائمًا بتعديل الوحدة الفرعية في مستودعها المستنسخ في مكان آخر.
5. لتشغيل مشروع Jellyfin.Server بنجاح ، فإنه يتحقق من كل من الخادم ومشروع عميل الويب.
6. أنشئ مشروع Jellyfin Web باستخدام 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 –state upstream origin my-feature
6. على GitHub ، قم بإنشاء RP جديد مقابل الفرع الرئيسي ل Updraft باتباع النصائح أدناه.
7. بمجرد دمج RP الخاص بك ، تأكد من إبقاء الفروع المحلية الخاصة بك محدثة: git fetch –allgit checkout mastergit rebase upstream / mastergit push -u master origin
8. احذف فرع الميزة المحلية إذا لم تعد بحاجة إليها: git branch -d my-feature

المساهمون md

إذا كانت هذه هي المرة الأولى التي تساهم فيها برمز إلى مستودع معين ، يرجى إضافته إلى الملف CONTRIBUTORS.md في نهاية قسم المساهمين في Jellyfin. على الرغم من أن GitHub يتابع هذا الأمر ، فإن كتابة الوثيقة توضح الأمور إذا تركت الشفرة GitHub وتسمح للجميع بمعرفة من عمل في المشروع من أجل حقوق النشر أو الثناء!

الفروع الرسمية

فروع مميزة

في بعض الأحيان ، قد تظهر مشاريع كبيرة تتطلب علاقات عامة متعددة ومساهمات من عدة أشخاص. بالنسبة لهذه المهام ، يجب إنشاء فروع ميزات خاصة بالميزة استنادًا إلى الشريحة الرئيسية. هذا يساعد على السماح للعمل بالمضي قدما دون كسر الماجستير لفترات طويلة ، ويسمح للمهتمين في هذا المشروع بالقدرة على العمل بالسرعة التي تناسبهم بدلاً من الاندفاع لإصلاح ميزة مكسورة قبل الإصدار التالي. لإنشاء فرع للميزات ، يرجى الاتصال بأحد أعضاء فريق Core ويمكن إصلاح ذلك.

بمجرد أن تصبح الميزة التي تم إنشاء فرع الميزة لها جاهزة ، يمكن دمجها في لقطة واحدة على الفرع الرئيسي وفرع الميزة الذي تمت إزالته. بدلاً من ذلك ، بالنسبة لخصائص الحياة الطويلة جدًا ، يمكن دمج بعض اللقطات "المستقرة" في الرئيسية كما هو مطلوب.

الفرع الرئيسي

الفرع الرئيسي هو الوجه الرئيسي للمشروع وفرع التطوير الرئيسي. باستثناء الإصلاحات العاجلة لإصدار الطوارئ ، يجب أن تستهدف جميع العلاقات العامة المعلم. كقاعدة عامة ، يجب ألا يكسر RP الرئيسي ويجب اختبار جميع RP قبل الدمج لضمان عدم حدوث ذلك. نحن بشر فقط وهذا من المحتمل أن يحدث ، ولكن بشكل عام يجب أن يكون آمنًا للبناء من المعلم إذا كنت تريد أحدث وأكبر نسخة من Jellyfin.

اختبار طلب لاطلاق النار

لاختبار طلب سحب شخص آخر ، يجب عليك استيراد التغييرات إلى المستودع المحلي الخاص بك.

1. احصل على التغييرات في طلب سحب واربطها بفرع محلي جديد: git fetch upstream pull / / head: my-testing-branchNote هو رقم طلب الاستخراج على جيثب.
2. تحقق من فرع محلي جديد: git تحقق من فرع الاختبار الخاص بي
3. قم بإجراء أي اختبارات أو تراكيب لازمة للاختبار ، ثم ارجع إلى الرئيسي وحذف الفرع: git checkoutفرع mastergit -D my-testing-branch

إرشادات طلب الاستخراج

عند إرسال RP جديد ، يرجى التأكد مما يلي. إذا لم تكن قد فعلت ذلك بالفعل ، فالرجاء قراءة كيفية كتابة رسالة مشاركة Git لأنها مصدر رائع لكتابة رسائل مشاركة مفيدة.

• قبل تقديم RP ، يوافق "القرع" على إبقاء القصة العامة نظيفة. يجب أن يغطي تنفيذ واحد تغييرًا هامًا واحدًا: تجنب سحق جميع التغييرات ، خاصة بالنسبة لبرامج RPs الكبيرة التي تمس الكثير من الملفات ، ولكن أيضًا لا تترك "ثابتًا" ، "whoops typo" يرتكب في تاريخ الفرع الخاص بك لأن هذا فوضى لا لزوم لها في القصة النهائية للمشروع.
• اكتب عنوانًا جيدًا يصف بسرعة ما تم تغييره. على سبيل المثال ، "أضف دعم LDAP إلى Jellyfin". كما هو مذكور في كيفية كتابة رسالة مشاركة Git ، استخدم دائمًا الحالة الحتمية ، واجعل العنوان قصيرًا ولكن وصفيًا. سيكون العنوان في النهاية إدخالًا في سجل التغيير ، لذا يرجى محاولة استخدام العواصم المناسبة ولكن دون علامات ترقيم ؛ يرجى ملاحظة أن الفريق الأساسي قد يغير العناوين لتأكيد هذا المعيار بشكل أفضل قبل الدمج.
• للحصول على أي شيء ما عدا أكثر التغييرات تافهة التي يمكن وصفها بالكامل في العنوان (القصير) ، اتبع نموذج العلاقات العامة واكتب هيئة علاقات عامة لوصف ، بأكبر قدر ممكن من التفاصيل: لماذا التغييرات. قم بالإشارة إلى مواضيع محددة باستخدام كلمات رئيسية (إصلاحات ، وإغلاق ، وعناوين ، وما إلى ذلك) إن أمكن. كيف تمت معالجة الموضوع (إن أمكن) ووصف التغييرات بإيجاز ، خاصةً بالنسبة لبرامج RPs الكبيرة.
• إذا لم يكتمل طلب السحب بعد ، يرجى وضع علامة عليه على أنه "مسودة" عند فتحه. طالما أن هذه العلامة موجودة ، فلن يتم دمج طلب السحب ، ويجب أن تظل المراجعات كتعليقات فقط. بمجرد أن تكون راضيًا عن الحالة النهائية لـ RP الخاص بك ، يرجى إزالة هذه العلامة ؛ قد يؤدي نسيانها إلى تجاهل RP الخاص بك عن غير قصد كما لو كان لا يزال قيد التطوير النشط! يمكن أن تؤدي WIPs غير النشطة في بعض الأحيان إلى أن يطلب فريق ping طلبًا بالحالة ، ويتم إغلاقه إذا لم يكن هناك رد.
• تجنب الإفراط في التجاوز وإجبار طلبات السحب الكبيرة أو المعقدة إن أمكن ، وخاصة بعد التصحيحات. يفرض مراجعات غير ضرورية للتحقق من أن التغييرات لا تزال جيدة ومبنية بشكل صحيح.
• توقع مراجعة ومناقشة. إذا لم تتمكن من إجراء نسخ احتياطي للتغييرات مع وصف جيد ومن خلال المراجعة ، فيرجى إعادة النظر في ما إذا كان يجب القيام به على الإطلاق. تتطلب جميع العلاقات العامة مراجعة موافقة واحدة على الأقل من قبل أحد أعضاء فريق الإدارة ، ولكننا نرحب بالمراجعات ونشجعها من قبل أي مساهم ، خاصة إذا كان في منطقة تعرفها. المزيد من العيون دائمًا أفضل.
• تتطلب جميع العلاقات العامة مراجعة ما لا يقل عن اثنين من أعضاء الفريق قبل دمجها في الماجستير ، على الرغم من أن المراجعات من أي مساهم مرحب بها! بعد مراجعة عضو الفريق الثاني ، قد يتم دمج البرنامج العادي على الفور ، أو طلب المزيد من المراجعات أو التعليقات بشكل صريح من المساهمين الآخرين إذا لزم الأمر.

نحتاج إلى تثبيت جميع تبعيات التطوير وإخراج الكود من الحاوية قبل أن نتمكن من تجميعها وتشغيلها.

ملاحظة

ضع كل أمر على سطر منفصل. تسمى الحاوية التي سنقوم باختبارها 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 - && echo "deb https://dl.yarnpkg.com/debian/able main" | تي / الخ / شقة / مصادر. 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. الخادم - تصحيح أخطاء التكوين - output = "/ jellyfin" - محتوي على نفسه - وقت التشغيل linux-x64cd / opt / jellyfin-web && yarn install && yarn build && cp -r / opt / jellyfin-web / dist / jellyfin / jellyfin-webkill -15 $ (pidof jellyfin)

طلب رمي

أولاً ، أكمل الخطوات السابقة لتكوين الحاوية الخاصة بك لبناء الفرع الرئيسي.

ملاحظة

هو رقم طلب الاستخراج على جيثب.

docker exec -ti jftest bashcd / opt / jellyfingit fetch origin pull pull /  / head: my-testing-branchgit دمج my-testing-branchdotnet نشر Jellyfin.Server - تصحيح الأخطاء - output = "/ jellyfin" - self-الواردة --runtime linux-x64kill -15 $ (pidof jellyfin)