هذا هو الأول من بين النصوص الأربعة التي شرعت في كتابتها كما هو مذكور في بنية النظام. شعرت بالضخ! لقد كانت خطوة في اتجاه إنشاء تجربة "wiki" التي تحصل على مساهمة في المصدر المفتوح دون التفاعل مع واجهة مستخدم GitHub؟.

ما هي هذه البرامج النصية؟

هذه هي ملفات js التي تحتوي على بعض الوظائف ذات الصلة القابلة لإعادة الاستخدام والتي يُقصد منها بشكل خاص استخدامها للتفاعل مع واجهات برمجة تطبيقات GitHub؛ يتم استهلاكها ضمن نفس البرنامج النصي أو تصديرها لاستخدامها في أداء وظائفها الأساسية في مكان آخر داخل المشروع. إنهم يقبلون مثيل Octokit المصادق عليه للمستخدم كمعلمات من بين الآخرين، ويتم استخدام هذا المثيل لتنفيذ الإجراءات/الوظائف من خلال واجهات برمجة تطبيقات GitHub نيابة عن المستخدم المصادق عليه.

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

1. ريبو مشروع الشوكة
2. إنشاء فرع
3. إجراء تغييرات على الفرع (أضف ملف mdx جديدًا في دليل src/pages/word/ للكلمة الجديدة أو قم بتحرير الملفات الموجودة، في حالتنا)
4. إنشاء طلب سحب (أرسل تغييرات الكلمات، في حالتنا)

حقيقة تستحق الذكر

لقد بدأت في كتابة هذا البرنامج النصي مباشرة بعد الالتزام الأولي، وكان هذا في الواقع هو PR # 2، لكنه تلقى نجاحًا كبيرًا خلال فترة الاستراحة الطويلة لمدة شهر؟ لقد أخذت من المشروع قبل العودة إلى العمل على ميزة القاموس الأساسي.

البرنامج النصي

كانت المهمة هنا هي إنشاء "The Fork Script" - هدفه النهائي هو إنشاء/الحصول على تفرع من مستودع jargons.dev على/من حساب المستخدم. يجب أن يضم كل وظيفة ستقوم بما يلي.

• تحقق مما إذا كان Fork الخاص بـ jargons.dev موجودًا بالفعل في حساب المستخدم
  • إذا كان الشوكة موجودة
    • تحقق مما إذا كانت Fork متزامنة مع المنبع (أي محدثة مع فرع jargons.dev repo الرئيسي)؛ إذا لم يكن الأمر كذلك - قم بتحديث الشوكة
  • إذا لم يتم العثور على شوكة
    • إنشاء الشوكة

فهمت المهمة، لقد "تعمقت" مباشرة في العمل على النص.

لقد اعتدت بالفعل على واجهات برمجة تطبيقات GitHub نظرًا لاستهلاكي المتكرر في عملي اليومي على Hearts ❤️... لذا، كانت وثائق GitHub's Fork Documentation تبدو وكأنها بروسكي بالنسبة لي؟...

الخطوات

• لقد قمت بإنشاء وظيفة forkRepository الرئيسية والتي كانت نقطة الدخول الرئيسية لتنفيذ وظيفة fork - فهي تؤدي إلى كل مكان آخر
• أضفت الوظائف التالية، والتي كانت في الغالب بمثابة مساعد لوظيفة forkRepository الرئيسية الواضحة
  • isRepositoryForked - تتحقق هذه الوظيفة مما إذا كان مستودع jargons.dev متفرعًا بالفعل إلى حساب المستخدم الحالي المصادق عليه
  • isRepositoryForkUpdated - للتحقق مما إذا كانت الشوكة (إن وجدت) (متزامنة مع مستودع الرأس) محدثة مع مستودع jargons.dev الرئيسي
  • updateRepositoryFork - يستخدم لتحديث مستودع (Sync) إلى حالة مستودع jargons.dev الرئيسي (الرئيسي)
  • getBranch - هي أداة مساعدة أساسية (مطلوبة عند كتابة هذا البرنامج النصي) تُستخدم لجلب تفاصيل الفرع/المرجع لمستودع jargons.dev وشوكة المستخدم لاستخدامها في المقارنة التي يتم إجراؤها في المساعد isRepositoryForkUpdated لأداء وظيفتها الأساسية؛ يستخدم نقطة نهاية مراجع GitHub.

افتراضى الغريب

يدور في ذهني؟ عندما كتبت هذا البرنامج النصي كان فكرة تمسكت بها بعد قراءة الفقرة المقتبسة أدناه في GitHub Fork Documentation

ملاحظة: يحدث تفرع المستودع بشكل غير متزامن. قد تضطر إلى الانتظار لفترة قصيرة من الوقت قبل أن تتمكن من الوصول إلى كائنات git. إذا استغرق ذلك أكثر من 5 دقائق، فتأكد من الاتصال بدعم GitHub.

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

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

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

العلاقات العامة

رئيسي:

الفذ: تنفيذ البرنامج النصي لمستودع "شوكة". #3

com.babblebey تم النشر بتاريخ 31 ديسمبر 2023

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

التغييرات التي تم إجراؤها

• تم تنفيذ وظيفة forkRepository الرئيسية داخل البرنامج النصي؛ هذه الوظيفة هي الوظيفة الرئيسية المصدرة التي تقوم بعملية الشوكة الرئيسية؛ فهو يقبل مثيل userOctokit (كائن تمت مصادقته من قبل المستخدم ولديه إذن بالتصرف نيابة عن المستخدم) وتفاصيل مستودع المشروع، أي كائن repoDetails ويقوم بما يلي...
  • يتحقق مما إذا كان مستودع المشروع قد تم بالفعل تشعبه إلى حساب المستخدم باستخدام وظيفة المساعد isRepositoryForked؛ يؤدي هذا إلى إرجاع شوكة فارغة
    • إذا كان الريبو قد تم تفرعه بالفعل، فإننا نقوم بإجراء فحص ما إذا كان التفرع محدثًا/متزامنًا مع ريبو المشروع الرئيسي باستخدام وظيفة المساعد isRepositoryForkUpdated؛ يؤدي هذا إلى إرجاع UpdateSHA وخاصية isUpdated المنطقية التي تؤكد ما إذا كان الشوكة محدثة
      • إذا لم تكن الشوكة محدثة؛ ثم نقوم بإجراء التحديث من خلال جعله متزامنًا مع مستودع المشروع الرئيسي باستخدام وظيفة المساعد updateRepositoryFork
    • إذا كان الريبو محدثًا/متزامنًا مع الريبو الرئيسي للمشروع؛ نقوم بإلغاء العملية في هذه المرحلة مع العودة المبكرة؛
  • إذا لم يتم تشعب مستودع المشروع على حساب المستخدم؛ ثم ننتقل إلى بدء عملية تفرع عن طريق استدعاء نقطة النهاية "POST /repos/{owner}/{repo}/forks" باستخدام مثيل userOctokit. (يبدأ هذا عملية الشوكة، لا نعرف بالضبط متى تكتمل العملية؟)
• قم بتنفيذ الوظائف المساعدة التالية المستهلكة داخل وظيفة forkRepository الرئيسية وضمن الوظائف المساعدة الأخرى أيضًا
  • updateRepositoryFork - يستخدم لتحديث مستودع (Sync) إلى حالة المستودع الرئيسي (الرئيسي)
  • isRepositoryForkUpdated - يستخدم للتحقق مما إذا كانت الشوكة (متزامنة مع الريبو الرئيسي) محدثة مع الريبو الرئيسي
  • getBranch - يُستخدم لجلب تفاصيل الفرع/المرجع
  • isRepositoryForked - يستخدم للتحقق من وجود مستودع معين في قائمة مستودعات الشوكة الخاصة بالمستخدم
• تمت إضافة getRepoParts إلى /lib/utils؛ إنها وظيفة مساعدة تُستخدم لحل repoOwner وrepoName من الاسم الكامل للمستودع.

مشكلة ذات صلة

القرار رقم 2

تسجيل الشاشة/لقطة الشاشة

https://github.com/babblebey/jargons.dev/assets/25631971/16221b7e-3c28-4c6c-a1f3-24d583ce7e3a

؟

عرض على جيثب

الفذ: إرجاع الريبو `الاسم الكامل` في البرنامج النصي للشوكة رقم 29

com.babblebey تم النشر بتاريخ 04 أبريل 2024

يعد هذا العلاقات العامة بمثابة متابعة لخطوة مفقودة في التنفيذ الأولي للبرنامج النصي للشوكة في رقم 3؛ فشل البرنامج النصي للشوكة في إرجاع الريبو الذي يمكن استخدامه في الخطوة التالية من الحساب. كان هذا بسبب الافتراض الغريب الذي كان لدي أثناء التنفيذ الأولي. ?انظر افتراضاتي أدناه...

أفترض أن الاتصال بنقطة النهاية "POST /repos/{owner}/{repo}/forks" يضمن فقط بدء عملية شوكة دون أن يؤكد لنا الرد على الإطلاق. وهذا يعني أننا قد لا نحصل بالضبط على استجابة. البيانات بعد المكالمة

...ولكن هذا لم يكن صحيحًا، فقد اكتشفت أن بيانات الاستجابة تأتي بالفعل، ولكن قد يستغرق الأمر بعض الوقت وفقط في الحالات التي يكون فيها الريبو الذي يتم تشعبه ضخمًا.... وفي الوقت الحالي يحدث تفرع ريبو المشروع في أقل من 5 ثوانٍ.

التغييرات التي تم إجراؤها

• تم إرجاع repo fork - هذه هي قيمة repo fullname التي تم إرجاعها من وظيفة المساعد isRepositoryForked؛ أقوم بموجب هذا بإعادتها كقيمة رئيسية تم إرجاعها من تنفيذ وظيفة forkRepository في الحالة التي يكون فيها الريبو متشعبًا بالفعل على حساب المستخدم المنفذ
• تم إرجاع Response.data.full_name - هذا هو الاسم الكامل لمستودع الشوكة الذي تم إنشاؤه حديثًا؛ إنها قيمة من الاستجابة لاستدعاء نقطة النهاية "POST /repos/{owner}/{repo}/forks"؛ أقوم بموجب هذا بإعادتها كقيمة رئيسية تم إعادة ضبطها من تنفيذ وظيفة forkRepository في الحالات التي لا يوجد فيها شوكة موجودة بالفعل في حساب المستخدم المنفذ
• اختار Cherry بعض التغييرات من رقم 25 لاستخدامها هنا
  • f12f25f548a5c5836e9be7d601ed226c5269f5ee
  • 436ceea649b67812c0ec1164fde95d443ce556e0

؟

عرض على جيثب