जैसा कि सिस्टम आर्किटेक्चर में कहा गया है, यह उन 4 स्क्रिप्ट्स में से पहली है जिन्हें मैंने लिखना शुरू किया था। उत्साहित महसूस हुआ! यह "विकी" अनुभव बनाने की दिशा में एक कदम था जिसे GitHub UI के साथ इंटरफेस किए बिना ओपन सोर्स में योगदान मिलता है?

ये स्क्रिप्ट क्या हैं?

ये जेएस फ़ाइलें हैं जिनमें कुछ संबंधित पुन: प्रयोज्य फ़ंक्शन हैं जो विशेष रूप से गिटहब एपीआई के साथ बातचीत करने के लिए उपयोग किए जाते हैं; उन्हें या तो एक ही स्क्रिप्ट के भीतर उपभोग किया जाता है या प्रोजेक्ट के भीतर कहीं और उनकी आधार कार्यक्षमता निष्पादित करने के लिए निर्यात किया जाता है। वे किसी उपयोगकर्ता के प्रमाणित ऑक्टोकिट इंस्टेंस को दूसरों से अलग पैरामीटर के रूप में स्वीकार करते हैं, इस इंस्टेंस का उपयोग प्रमाणित उपयोगकर्ता की ओर से GitHub API के माध्यम से क्रियाएं/कार्य करने के लिए किया जाता है।

GitHub UI के साथ इंटरफेस किए बिना ओपन सोर्स में योगदान का प्रवाह बनाने की आवश्यकता का मतलब है कि हमें कुछ प्रक्रिया को स्वचालित करना होगा - उपयोगकर्ता द्वारा GitHub UI के माध्यम से योगदान करने के लिए उठाए जाने वाले हर कदम का अनुकरण करना, चरण इस प्रकार हैं इस प्रकार है..

1. फोर्क प्रोजेक्ट रेपो
2. एक शाखा बनाएं
3. शाखा में परिवर्तन करें (नए शब्द के लिए src/pages/word/ निर्देशिका में नई mdx फ़ाइल जोड़ें या हमारे मामले में मौजूदा को संपादित करें)
4. एक पुल अनुरोध बनाएं (हमारे मामले में, शब्द परिवर्तन सबमिट करें)

बयान करने लायक एक सच्चाई

मैंने प्रारंभिक प्रतिबद्धता के तुरंत बाद इस स्क्रिप्ट को लिखना शुरू कर दिया था, यह वास्तव में पीआर #2 था, लेकिन लंबे महीने के ब्रेक के दौरान इसमें गिरावट आई? बेस डिक्शनरी फीचर पर काम पर वापस आने से पहले मैंने प्रोजेक्ट से लिया।

लिपि

यहाँ कार्य "द फोर्क स्क्रिप्ट" बनाना था - जिसका अंतिम लक्ष्य किसी उपयोगकर्ता के खाते से Jargons.dev रेपो का एक फोर्क बनाना/प्राप्त करना है। इसमें प्रत्येक फ़ंक्शन होना चाहिए जो निम्नलिखित कार्य करेगा।

• जांचें कि क्या उपयोगकर्ता के खाते पर Jargons.dev का फ़ोर्क पहले से मौजूद है
  • यदि कांटा मौजूद है
    • जांचें कि क्या फोर्क अपस्ट्रीम के साथ इन-सिंक है (यानी Jargons.dev रेपो मुख्य शाखा के साथ अप-टू-डेट); यदि नहीं - कांटा अद्यतन करें
  • यदि कोई कांटा नहीं मिलता है
    • कांटा बनाएं

असाइनमेंट को समझते हुए, मैं सीधे स्क्रिप्ट पर काम करने में "तल्लीन" हो गया।

हार्ट्स पर अपने रोजमर्रा के काम में लगातार उपयोग के कारण मैं पहले से ही GitHub API का आदी हो गया हूं ❤️... तो मेरे लिए GitHub का फोर्क डॉक्यूमेंटेशन एक ब्रॉस्की की तरह लग रहा था?...

सीढ़ी

• मैंने एक मुख्य forkRepository फ़ंक्शन बनाया जो कि fork कार्यक्षमता को निष्पादित करने के लिए मुख्य प्रवेश बिंदु था - यह हर जगह ले जाता है
• मैंने निम्नलिखित फ़ंक्शन जोड़े, जो अधिकतर स्पष्ट मुख्य forkRepository फ़ंक्शन के सहायक के रूप में कार्य करते थे
  • isRepositoryForked - यह फ़ंक्शन जाँचता है कि क्या Jargons.dev रिपॉजिटरी पहले से ही वर्तमान प्रमाणित उपयोगकर्ता के खाते में फोर्क की गई है
  • isRepositoryForkUpdated - यह जांचने के लिए कि क्या कांटा (यदि पाया गया है) (हेड रेपो के साथ सिंक में) मुख्य Jargons.dev रेपो के साथ अद्यतित है
  • updateRepositoryFork - मुख्य (हेड) Jargons.dev रिपॉजिटरी की स्थिति में (सिंक) रिपॉजिटरी को अपडेट करने के लिए उपयोग किया जाता है
  • getBranch - एक आधार उपयोगिता है (इस स्क्रिप्ट को लिखने के समय आवश्यक) जिसका उपयोग प्राथमिक कार्य करने के लिए isRepositoryForkUpdated हेल्पर में की गई तुलना में उपयोग करने के लिए Jargons.dev रेपो और उपयोगकर्ता के कांटे के लिए शाखा/रेफ विवरण लाने के लिए किया जाता है; यह GitHub संदर्भ समापन बिंदु का उपयोग करता है।

मेरी अजीब धारणा

मेरे दिमाग में चल रहा है? जब मैंने यह स्क्रिप्ट लिखी थी तो यह एक विचार था जिसे मैंने GitHub Fork दस्तावेज़ीकरण पर नीचे उद्धृत पैराग्राफ को पढ़ने के बाद कायम रखा था

नोट: रिपॉजिटरी को फोर्क करना अतुल्यकालिक रूप से होता है। गिट ऑब्जेक्ट तक पहुंचने से पहले आपको थोड़े समय तक इंतजार करना पड़ सकता है। यदि इसमें 5 मिनट से अधिक समय लगता है, तो GitHub समर्थन से संपर्क करना सुनिश्चित करें।

मैंने इसे गलत समझा और मान लिया कि हम केवल एक कांटा प्रक्रिया शुरू करने में सक्षम होंगे, आगे बढ़ेंगे और निश्चित रूप से एक प्रतिक्रिया वस्तु की प्रतीक्षा करने में सक्षम नहीं होंगे जो नए कांटा का विवरण लौटाएगा क्योंकि हम नहीं जानते हैं जब कांटा प्रक्रिया पूरी हो जाती है.

इस धारणा ने मुझे मुख्य forkRepositoryfunction से कोई भी डेटा वापस न करने के लिए मजबूर किया और मैं पहले से ही इस बिंदु पर सोचना शुरू कर रहा था - मैं योगदान प्रक्रिया के अगले चरण में संसाधित करने के लिए कांटा विवरण कैसे प्राप्त करूंगा!? हम्म, शायद मैं वेबहुक का उपयोग करूंगा?!?

यह पता चला कि मैं इसके बारे में बहुत अधिक सोच रहा था?, मुझे बाद में एहसास हुआ कि मुझे वास्तव में फोर्क के लिए एक प्रतिक्रिया विवरण मिलेगा और इसने मुझे खपत के लिए फोर्क प्रतिक्रिया ऑब्जेक्ट से आवश्यक डेटा वापस करने के लिए एक अनुवर्ती पीआर करने के लिए प्रेरित किया। योगदान प्रक्रिया.

पीआर

मुख्य:

करतब: `फोर्क` रिपॉजिटरी स्क्रिप्ट लागू करें #3

बकवास को दिसंबर 31, 2023 पर पोस्ट किया गया

यह पुल अनुरोध फोर्क स्क्रिप्ट को लागू करता है; इस स्क्रिप्ट का उपयोग मुख्य प्रोजेक्ट रेपो को उपयोगकर्ता खाते में प्रोग्रामेटिक रूप से फोर्क करने के लिए किया जाना है; इसमें एक मुख्य कार्य और अन्य सहायक कार्य शामिल हैं जिनका उपयोग यह एक कुशल रेपो फोर्क संचालन सुनिश्चित करने के लिए कुछ आवश्यक कार्य करने के लिए करता है।

परिवर्तन किए

• स्क्रिप्ट के भीतर मुख्य forkRepository फ़ंक्शन लागू किया गया; यह फ़ंक्शन मुख्य निर्यातित फ़ंक्शन है जो मुख्य कांटा ऑपरेशन करता है; यह एक यूजरऑक्टोकिट (उपयोगकर्ता की ओर से कार्य करने की अनुमति के साथ एक उपयोगकर्ता प्रमाणित ऑब्जेक्ट) उदाहरण और प्रोजेक्ट के रिपॉजिटरी विवरण यानी रेपोडिटेल्स ऑब्जेक्ट को स्वीकार करता है और यह निम्नलिखित कार्य करता है...
  • यह जाँचता है कि क्या प्रोजेक्ट रिपॉजिटरी को isRepositoryForked हेल्पर फ़ंक्शन का उपयोग करके उपयोगकर्ता के खाते में पहले ही फोर्क किया जा चुका है; यह शून्य का कांटा लौटाता है
    • यदि रेपो पहले ही फोर्क किया जा चुका है, तो हम isRepositoryForkUpdated हेल्पर फ़ंक्शन का उपयोग करके जांच करते हैं कि फोर्क मुख्य प्रोजेक्ट रेपो के साथ अप-टू-डेट/सिंक है या नहीं; यह अपडेटेडSHA और एक बूलियन isUpdated प्रॉपर्टी लौटाता है जो पुष्टि करता है कि फोर्क अद्यतित है या नहीं
      • यदि कांटा अद्यतन नहीं है; फिर हम updateRepositoryFork हेल्पर फ़ंक्शन का उपयोग करके इसे मुख्य प्रोजेक्ट रेपो के साथ सिंक करके अपडेट करते हैं
    • यदि रेपो अद्यतित है/मुख्य परियोजना रेपो के साथ समन्वयित है; हम शीघ्र वापसी के साथ इस बिंदु पर ऑपरेशन रद्द कर देते हैं;
  • यदि प्रोजेक्ट रिपॉजिटरी को उपयोगकर्ता के खाते में नहीं डाला गया है; फिर हम userOctokit इंस्टेंस का उपयोग करके "POST /repos/{owner}/{repo}/forks" एंडपॉइंट को कॉल करके एक फोर्क प्रक्रिया शुरू करने के लिए आगे बढ़ते हैं। (यह कांटा प्रक्रिया शुरू करता है, हमें नहीं पता कि प्रक्रिया कब पूरी होती है?)
• मुख्य फोर्करिपोजिटरी फ़ंक्शन के भीतर और अन्य सहायक कार्यों के भीतर भी निम्नलिखित सहायक कार्यों को लागू करें
  • updateRepositoryFork - मुख्य (हेड) रिपॉजिटरी की स्थिति में (सिंक) रिपॉजिटरी को अपडेट करने के लिए उपयोग किया जाता है
  • isRepositoryForkUpdated - यह जांचने के लिए उपयोग किया जाता है कि क्या एक कांटा (हेड रेपो के साथ सिंक में) मुख्य रेपो के साथ अद्यतित है
  • getBranch - शाखा/रेफरी विवरण लाने के लिए उपयोग किया जाता है
  • isRepositoryForked - उपयोगकर्ता की फोर्क रेपो सूची में एक विशिष्ट रेपो की उपस्थिति की जांच करने के लिए उपयोग किया जाता है
• getRepoParts को /lib/utils में जोड़ा गया; यह एक उपयोगिता फ़ंक्शन है जिसका उपयोग रिपॉजिटरी पूर्ण नाम से रेपोओनर और रेपोनाम को हल करने के लिए किया जाता है।

संबंधित समस्या

समाधान #2

स्क्रीनकास्ट/स्क्रीनशॉट

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

?

GitHub पर देखें

करतब: फोर्क स्क्रिप्ट में रेपो `पूरा नाम` लौटाएं #29

बकवास को अप्रैल 04, 2024 को पोस्ट किया गया

यह पीआर #3 पर फोर्क स्क्रिप्ट के प्रारंभिक कार्यान्वयन में छूटे हुए चरण का अनुवर्ती है; फ़ोर्क स्क्रिप्ट एक रेपो लौटाने में विफल रही जिसका उपयोग गणना के अगले चरण में किया जा सकता है। ऐसा प्रारंभिक कार्यान्वयन के दौरान मेरी एक अजीब धारणा के कारण था। ?मेरी धारणा नीचे देखें...

मेरा मानना ​​है कि "POST /repos/{owner}/{repo}/forks" एंडपॉइंट पर कॉल हमें किसी प्रतिक्रिया का आश्वासन दिए बिना केवल फोर्क प्रक्रिया शुरू करने का आश्वासन देती है। इसका मतलब है कि हमें कॉल के बाद वास्तव में कोई प्रतिक्रिया नहीं मिल सकती है।

...लेकिन यह सच नहीं था, मुझे पता चला कि एक प्रतिक्रिया डेटा वास्तव में आता है, लेकिन इसमें कुछ समय लग सकता है और केवल उन मामलों में जहां रेपो का कांटा बहुत बड़ा है.... और फिलहाल प्रोजेक्ट रेपो को फोर्क करना 5 सेकंड से भी कम समय में होता है।

परिवर्तन किए

• रिटर्न्ड फोर्क रेपो - यह एक रेपो फुलनेम वैल्यू है जो isRepositoryForked हेल्पर फ़ंक्शन से लौटाया गया है; मैं इसे forkRepository फ़ंक्शन निष्पादन से मुख्य लौटाए गए मान के रूप में उस स्थिति में लौटाता हूं जहां रेपो पहले से ही निष्पादित उपयोगकर्ता के खाते पर फोर्क किया गया है
• Returned recruitment.data.full_name - यह एक नव निर्मित फोर्क रेपो फुलनाम है; यह "POST /repos/{owner}/{repo}/forks" एंडपॉइंट कॉल की प्रतिक्रिया से प्राप्त मूल्य है; मैं इसे उन मामलों में forkRepository फ़ंक्शन निष्पादन से मुख्य पुन: ट्यून किए गए मान के रूप में लौटाता हूं जहां निष्पादन करने वाले उपयोगकर्ता के खाते पर पहले से ही कोई कांटा नहीं मिला था
• चेरी ने यहां उपयोग करने के लिए #25 से कुछ बदलाव चुने
  • f12f25f548a5c5836e9be7d601ed226c5269f5ee
  • 436ceea649b67812c0ec1164fde95d443ce556e0

?

GitHub पर देखें