GitHub रिपॉज़िटरी से प्रोजेक्ट भरें

एक एजेंट को किसी GitHub रिपॉज़िटरी की ओर मोड़िए और आपको काम करने लायक बोर्ड वापस मिलता है: हर issue एक स्टोरी के रूप में, उसी स्थिति में जो उसका इतिहास बताता है, चेकलिस्ट, लेबल और माइलस्टोन के साथ। फिर वही एजेंट एक स्टोरी उठाता है, उसे अपने नाम करता है, उसे स्टेट मशीन से आगे बढ़ाता है, और अपनी खोली हुई पुल रिक्वेस्ट को जोड़ देता है।

यह पृष्ठ उस पूरे चक्र को सिरे से सिरे तक बताता है। भरने के चरण के दो रास्ते हैं: GitHub-to-EAT, East Agile का ओपन-सोर्स इम्पोर्टर, इसे एक ही कमांड में कर देता है (चरण 3); इम्पोर्ट API वही काम कॉल-दर-कॉल करता है (चरण 4 और 5), और जब एजेंट को जॉब हैंडल चाहिए तो वह इसी को चलाता है। उसके बाद सब कुछ API पर चलता है, क्योंकि पूरी बात यही है कि बाकी काम एजेंट बिना निगरानी के कर सके।

यह कोई अलग «AI इम्पोर्ट» नहीं है। भरने का चरण वही GitHub इम्पोर्टर है जिसे आप प्रोजेक्ट सेटिंग्स → इम्पोर्ट / एक्सपोर्ट से हाथ से चला सकते हैं, जिसका वर्णन संचालन निर्देश → अन्य ट्रैकर से इम्पोर्ट में है। एजेंट उसी एंडपॉइंट को बुलाता है जिसे आप बुलाते। यह पृष्ठ जो जोड़ता है वह उसके आसपास की हर चीज़ है: कुंजी किसके पास है, लिखने से पहले इम्पोर्ट की जाँच कैसे करें, और बोर्ड बन जाने के बाद एजेंट उसका क्या करता है।

आपको क्या चाहिए

• एक प्रोजेक्ट — और उसे बनाने के लिए एक सत्र या ea_user_… कुंजी।
• एक एजेंट कुंजी — उस प्रोजेक्ट तक सीमित एक ea_agent_… कुंजी। उसे कौन-सी भूमिका चाहिए यह इस पर निर्भर है कि चक्र का कितना हिस्सा आप एजेंट से चलवाना चाहते हैं; चरण 2 देखें। यह भी देखें API गाइड → दो तरह की कुंजियाँ।
• एक GitHub पर्सनल एक्सेस टोकन — जिसे रिपॉज़िटरी के issues पढ़ने का अधिकार हो। हर इम्पोर्ट प्रमाणित होता है, क्योंकि फ़ेच GitHub के GraphQL API पर चलता है और GraphQL बिना टोकन वाले अनुरोध को अस्वीकार कर देता है। आप इसे केवल तभी छोड़ सकते हैं जब Tracker आपकी ओर से फ़ेच करे: एक सार्वजनिक रिपॉज़िटरी, ऐसी तैनाती पर जिसके पास साझा फ़ॉलबैक टोकन हो (होस्ट किया गया eastagiletracker.com एक रखता है; स्व-होस्ट की गई स्थापना के पास तब तक कोई नहीं जब तक उसका संचालक GITHUB_IMPORT_PAT सेट न करे), और GitHub-to-EAT के --engine direct के साथ कभी नहीं। देखें टोकन और दर सीमाएँ।
• Node.js 22+ — केवल चरण 3 के GitHub-to-EAT रास्ते के लिए। API रास्ते को curl के अलावा कुछ नहीं चाहिए।

1. प्रोजेक्ट बनाएँ

प्रोजेक्ट एजेंट कुंजी से पहले मौजूद होना चाहिए, और उसे किसी व्यक्ति द्वारा बनाया जाना चाहिए: एजेंट कुंजियाँ जारी होते समय एक ही प्रोजेक्ट से बँध जाती हैं और स्वयं प्रोजेक्ट नहीं बना सकतीं। इसे इंटरफ़ेस में बनाएँ, या अपनी ea_user_… कुंजी से:

curl -X POST https://eastagiletracker.com/api/v1/projects \
  -H "X-TrackerToken: $TRACKER_USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "hello-world", "iteration_length_weeks": 1}'

प्रतिक्रिया में वह project_id आता है जिसकी ज़रूरत नीचे के हर कॉल को है।

2. एक एजेंट कुंजी जारी करें

प्रोजेक्ट का मालिक प्रोजेक्ट सेटिंग्स → एजेंट में एजेंट कुंजियाँ बनाता है। आप जो भूमिका चुनते हैं वह तय करती है कि इस पृष्ठ का कितना हिस्सा एजेंट अकेले कर सकता है, और दो समझदार उत्तर हैं:

• owner — एक ही कुंजी पूरा चक्र चलाती है, इम्पोर्ट सहित। इम्पोर्ट केवल मालिक के लिए है, क्योंकि एक इम्पोर्ट प्रोजेक्ट के आकार को पूरा का पूरा फिर से लिख देता है। owner भूमिका वाला एजेंट जारी करने के लिए आपका स्वयं प्रोजेक्ट का मालिक होना ज़रूरी है: एजेंट की भूमिका उसके निर्माता की भूमिका से कभी अधिक नहीं हो सकती।
• member — न्यूनतम अधिकार। एजेंट स्टोरी लेता है, उन्हें बढ़ाता है, टिप्पणी करता है और पुल रिक्वेस्ट जोड़ता है, पर इम्पोर्ट नहीं कर सकता। इम्पोर्ट आप स्वयं अपनी कुंजी से चलाते हैं (चरण 5), फिर बोर्ड एजेंट को सौंप देते हैं।

चाहे जो हो, डिफ़ॉल्ट पर मत छोड़िए। नई एजेंट कुंजी तब तक viewer रहती है जब तक आप कुछ और न कहें, और viewer बोर्ड पढ़ सकता है पर स्टोरी न ले सकता है न बढ़ा सकता है — और यही इस चक्र का अधिकांश हिस्सा है।

एजेंट कुंजियाँ यहाँ पहुँच से परे एक कारण से मायने रखती हैं। एजेंट कुंजी एक ही प्रोजेक्ट में नामित प्रतिभागी की तरह काम करती है, इसलिए वह जो भी स्टोरी बनाती है, जो भी स्थिति बदलती है और जो भी टिप्पणी लिखती है, वह इतिहास में उसी एजेंट के नाम दर्ज होती है — आपके अपने काम से मिली-जुली नहीं, बल्कि अलग पहचानी जा सकने वाली।

export TRACKER_TOKEN="ea_agent_xxxxx"

बाकी सब से पहले एजेंट से /meta पढ़वाइए:

curl https://eastagiletracker.com/api/v1/meta \
  -H "X-TrackerToken: $TRACKER_TOKEN"

इससे उन दो सवालों के जवाब मिलते हैं जिनका एजेंट वरना अनुमान ही लगाता: कुंजी किस प्रोजेक्ट से बँधी है (auth.project_id), और हर स्टोरी प्रकार के लिए कौन-सी स्थिति-चालें वैध हैं (transitions)। एक feature unstarted → started → finished → delivered → accepted चलती है; एक chore केवल unstarted → started → accepted है। नक्शा पढ़ना उसे कोड में जड़ देने से बेहतर है।

3. GitHub-to-EAT से इम्पोर्ट करें

GitHub-to-EAT East Agile का अपना ओपन-सोर्स इम्पोर्टर है: MIT लाइसेंस वाला कमांड-लाइन उपकरण जो भरने का पूरा चरण — नीचे के चरण 4 और 5 — एक ही कमांड में कर देता है। जब कोई व्यक्ति टर्मिनल पर बैठा हो तो इसे उठाइए। जब एजेंट बिना निगरानी के चला रहा हो और उसे पूछताछ के लिए जॉब हैंडल चाहिए, तो इसके नीचे वाला API उठाइए।

इसे Node.js 22+ चाहिए और इसकी अपनी कोई रनटाइम निर्भरता नहीं है। यह अभी npm पर प्रकाशित नहीं है, इसलिए इसे रिपॉज़िटरी से इंस्टॉल करें:

git clone git@github.com:EastAgile/GitHub-to-EAT.git
cd GitHub-to-EAT
npm install --global .

फिर इसे चरण 2 में जारी की गई कुंजी और चरण 1 में बनाए गए प्रोजेक्ट की ओर मोड़ें:

export EAT_AGENT_KEY="ea_agent_xxxxx"
github-to-eat --project $PROJECT_ID --repo octocat/hello-world

यह पहले मैपिंग की व्याख्या छापता है — चुना गया हर प्रकार ठीक कैसे उतरेगा — और कुछ भी लिखने से पहले पुष्टि माँगता है। टर्मिनल के बाहर, किसी पाइप में, CI में या किसी एजेंट में वह संकेत दिखाने की जगह ही नहीं है, इसलिए जो चलन लिखेगा उसे --yes भेजना ही होगा; उसके बिना उपकरण आपका उत्तर अनुमान लगाने के बजाय 2 के साथ बाहर निकलता है और कुछ नहीं लिखता। दोबारा चलाना सुरक्षित है: जो पहले ही इम्पोर्ट हो चुका है वह छोड़ दिया जाता है, कभी दोहराया नहीं जाता।

फ़्लैग	यह क्या करता है
--dry-run	पहले जाँच, फिर वह योजना छापता है जिसे वह अंजाम देता — कितनी स्टोरी इम्पोर्ट करता, कितनी पहले से मौजूद मानकर छोड़ता — और कुछ नहीं लिखता। इसे --yes की ज़रूरत नहीं।
--include	कौन-से प्रकार इम्पोर्ट करने हैं, अल्पविराम से अलग: issues,prs,milestones,releases,deps। डिफ़ॉल्ट issues है, और हर चयन में यह होना ही चाहिए। ये वही विकल्प हैं जो चरण 6 की तालिका में हैं।
--token	आपका GitHub पर्सनल एक्सेस टोकन (परिवेश या .env का GITHUB_TOKEN भी गिना जाता है)। उस रिपॉज़िटरी पर इसे repo, या सूक्ष्म Issues: Read चाहिए। निजी रिपॉज़िटरी के लिए, बिना साझा फ़ॉलबैक टोकन वाले सर्वर के लिए, और --engine direct के लिए हमेशा आवश्यक। होस्टेड सेवा के डिफ़ॉल्ट इंजन पर इसे छोड़ दें तो Tracker अपना साझा बजट खर्च करता है — देखें टोकन और दर सीमाएँ।
--engine	डिफ़ॉल्ट server एक /import/json कॉल भेजता है और फ़ेच, मैप तथा लेखन Tracker पर छोड़ देता है। direct वही पाइपलाइन आपकी मशीन पर चलाता है और सार्वजनिक API के ज़रिए लिखता है — यानी वह GitHub स्वयं पढ़ता है और उसे हमेशा टोकन चाहिए, वरना 2 के साथ बाहर निकलता है।
--states, --milestones, --story-type, --no-comments, --no-tasks	एक बार के चलन के लिए मैपिंग को सीमित या अधिलिखित करते हैं; कुछ भी सहेजा नहीं जाता। इनमें से हर एक --engine direct का अर्थ रखता है।

EAT_API_BASE और EAT_APP_BASE सेट करके इसे स्व-होस्टेड या स्थानीय Tracker की ओर मोड़ें; दोनों डिफ़ॉल्ट रूप से होस्टेड सेवा की ओर हैं। README में फ़्लैग की पूरी संदर्भ-सूची, एग्ज़िट कोड और समस्या-निवारण है।

नीचे जो कुछ है वह वही इम्पोर्ट है, बस कॉल-दर-कॉल चलाया गया — और जब उसे कोई एजेंट चलाता है तो आपको यही चाहिए।

4. पहले सूखा चलन

इम्पोर्ट केवल मालिक के लिए है — owner भूमिका वाली एजेंट कुंजी लें, या अपनी कुंजी अगर आपने एजेंट को member पर छोड़ा है। कुछ भी लिखने देने से पहले इसे पहले dry_run के साथ चलाएँ:

curl -X POST https://eastagiletracker.com/api/v1/projects/$PROJECT_ID/import/json \
  -H "X-TrackerToken: $TRACKER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "source": "github",
        "owner": "octocat",
        "repo": "hello-world",
        "include_pull_requests": true,
        "include_milestones": true,
        "dry_run": true
      }'

सूखा चलन GitHub से फ़ेच करता है, हल करता है और डी-डुप करता है — बिलकुल असली की तरह — वही गिनतियाँ बताता है (imported, skipped, errors, unmatched), और फिर पूरे लेन-देन को वापस मोड़ देता है। कुछ भी टिकता नहीं और कोई «इम्पोर्ट पूर्ण» घटना आपके ऑडिट लॉग तक नहीं पहुँचती। यह जानने का सबसे सस्ता तरीका है कि आप दरअसल माइलस्टोन शामिल करना चाहते थे, या कि रिपॉज़िटरी आपके सोचे से बड़ी है — जब तक इसकी कोई कीमत नहीं चुकानी पड़ती।

/import/json की हर कॉल अतुल्यकालिक है, सूखा चलन भी: एंडपॉइंट परिणाम नहीं, बल्कि जॉब हैंडल के साथ 202 लौटाता है, और गिनतियाँ तब मिलती हैं जब आप जॉब को पूछते हैं (चरण 5)। सूखे चलन की जॉब भी असली की तरह done तक पहुँचती है; फ़र्क़ बस इतना है कि कुछ लिखा नहीं गया।

5. इम्पोर्ट चलाएँ

dry_run हटाइए और दोबारा भेजिए। पहले की तरह, एंडपॉइंट जॉब हैंडल के साथ 202 लौटाता है:

{ "import_id": "…", "status": "pending" }

जॉब को तब तक पूछते रहिए जब तक वह अंतिम स्थिति तक न पहुँचे:

curl https://eastagiletracker.com/api/v1/projects/$PROJECT_ID/imports/$IMPORT_ID \
  -H "X-TrackerToken: $TRACKER_TOKEN"

स्थिति pending → fetching → writing → done | failed चलती है। केवल अंतिम दो अंतिम हैं: done परिणाम की गिनतियाँ लाता है, failed त्रुटि संदेश और एक स्थिर मशीन कोड लाता है जिस पर आप शाखा बना सकते हैं। जब तक फ़ेच पृष्ठ-दर-पृष्ठ चल रहा है, progress_current और progress_total बताते हैं कि वह किस पृष्ठ पर है — यदि कोई व्यक्ति देख रहा हो तो दिखाने लायक।

टोकन। "token": "github_pat_…" भेजिए। इसे छोड़ दें तो सर्वर साझा प्लेटफ़ॉर्म टोकन लगा देता है, जो केवल सार्वजनिक रिपॉज़िटरी पढ़ता है और जिसका बजट तैनाती के हर कॉलर से कटता है — टोकन और दर सीमाएँ बताता है कि इसकी क्या कीमत है। जो भी टोकन इस्तेमाल हो, वह अपस्ट्रीम GitHub कॉल चलाता है और कुछ नहीं: वह कभी लॉग में नहीं जाता, कभी ऑडिट लॉग में नहीं जाता, कभी संग्रहीत नहीं होता, और किसी प्रतिक्रिया या त्रुटि में कभी वापस नहीं दिखता।

दोबारा चलाना सुरक्षित है। जो पंक्ति पहले ही इम्पोर्ट हो चुकी है वह अपने स्रोत id से पहचानी जाती है और छोड़ दी जाती है, दोहराई नहीं जाती। दूसरा इम्पोर्ट बोर्ड को उससे भर देता है जो पहले के बाद आया है।

6. बोर्ड पर क्या उतरता है

Issues डिफ़ॉल्ट रूप से इम्पोर्ट होते हैं। बाकी सब वैकल्पिक है, हर प्रकार के लिए एक फ़्लैग:

GitHub से	बनता है	फ़्लैग
Issue	एक स्टोरी। खुला → Backlog में unstarted। बंद → accepted, या rejected जब GitHub बताता है कि issue not_planned या duplicate के रूप में बंद हुआ (स्टोरी पर तब मेल खाता लेबल लगता है)।	डिफ़ॉल्ट
Issue के मुख्य भाग की चेकलिस्ट	कार्य — हर - [ ] / - [x] पंक्ति मुख्य भाग के क्रम में एक कार्य बनती है, और [x] पूर्ण अवस्था में पहुँचती है। चेकलिस्ट विवरण में भी बनी रहती है।	डिफ़ॉल्ट
लेबल	लेबल, ज्यों के त्यों ले जाए जाते हैं।	डिफ़ॉल्ट
पुल रिक्वेस्ट	pull-request लेबल वाली एक स्टोरी। खुली → started, मर्ज हुई → accepted, बिना मर्ज बंद → rejected।	include_pull_requests
माइलस्टोन	माइलस्टोन के नाम पर एक एपिक, शीर्षक से डी-डुप — एक ही माइलस्टोन साझा करने वाले दो issues एक ही एपिक में उतरते हैं। फ़्लैग बंद हो तो वह milestone:<शीर्षक> लेबल के रूप में साथ चलता है।	include_milestones
रिलीज़	एक रिलीज़ स्टोरी। प्रकाशित → accepted, ड्राफ़्ट → unstarted।	include_releases
Issue निर्भरता	स्टोरी पर एक ब्लॉकर। केवल issues, कभी पुल रिक्वेस्ट नहीं।	include_dependencies

स्टोरी का प्रकार तब अनुमानित होता है जब issue उसे नहीं बताता। bug, fix या defect वाला लेबल — या fix अथवा bug से शुरू होने वाला शीर्षक — उसे बग बनाता है; chore, maintenance, devops या infra उसे chore बनाते हैं; बाकी सब feature है। इम्पोर्ट से पहले यह जानना उपयोगी है, क्योंकि East Agile Tracker में केवल features पॉइंट रखते हैं और केवल features वेलोसिटी में जुड़ते हैं। देखें परिचय → स्टोरी।

7. एजेंट एक स्टोरी पर काम करता है

अब बोर्ड के पास इतिहास है और एजेंट के पास कुंजी। यहाँ से आगे चक्र चार कॉल का है।

कोई स्टोरी ढूँढ़िए, या एक लिखिए। उठाने लायक कुछ खोजने के लिए बोर्ड छानिए:

curl "https://eastagiletracker.com/api/v1/projects/$PROJECT_ID/stories?state=unstarted" \
  -H "X-TrackerToken: $TRACKER_TOKEN"

import_source=github उसे केवल उस तक सीमित कर देता है जो इम्पोर्ट लाया था। यदि एजेंट ने ऐसा काम खोज लिया जिसे रिपॉज़िटरी ने कभी दर्ज नहीं किया, तो वह स्टोरी स्वयं बना लेता है — देखें API गाइड → स्टोरी बनाएँ।

उसे अपने नाम कीजिए। एजेंट खाली बॉडी पोस्ट करके स्वयं को मालिक जोड़ता है:

curl -X POST https://eastagiletracker.com/api/v1/projects/$PROJECT_ID/stories/$STORY_ID/owners \
  -H "X-TrackerToken: $TRACKER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'

खाली बॉडी का अर्थ है कॉल करने वाला, इसलिए एजेंट को अपना id जानने की ज़रूरत नहीं। बोर्ड अब एजेंट को मालिक दिखाता है, और इसी से देख रहा व्यक्ति जान जाता है कि काम ले लिया गया है।

उसे शुरू कीजिए।

curl -X POST https://eastagiletracker.com/api/v1/projects/$PROJECT_ID/stories/$STORY_ID/transitions \
  -H "X-TrackerToken: $TRACKER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"to": "started"}'

फिर एजेंट जाकर काम करता है — रिपॉज़िटरी पढ़ता है, कोड लिखता है, पुल रिक्वेस्ट खोलता है। वह हिस्सा आपके कोडिंग उपकरण में होता है, यहाँ नहीं।

पुल रिक्वेस्ट जोड़िए।

curl -X POST https://eastagiletracker.com/api/v1/projects/$PROJECT_ID/stories/$STORY_ID/links \
  -H "X-TrackerToken: $TRACKER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://github.com/octocat/hello-world/pull/42"}'

GitHub पुल रिक्वेस्ट का URL स्वयं पहचान लिया जाता है — आपको बताना नहीं पड़ता। स्टोरी और उसे बंद करने वाला कोड अब दोनों दिशाओं में एक क्लिक की दूरी पर हैं।

उसे पूरा कीजिए। finished पर ले जाइए और वहीं रुक जाइए। एक feature के आगे अब भी delivered और accepted हैं, और वही समीक्षा के द्वार हैं: काम सही है या नहीं, यह एजेंट के अलावा कोई और तय करता है। एक chore के पास ऐसा द्वार नहीं है — started → accepted ही उसका बचा हुआ पूरा रास्ता है।

टोकन और दर सीमाएँ

हर इम्पोर्ट प्रमाणित होता है। issue, टिप्पणी और पुल रिक्वेस्ट का फ़ेच GitHub के GraphQL API पर चलता है, और GraphQL बिना टोकन वाले अनुरोध को अस्वीकार कर देता है — सार्वजनिक रिपॉज़िटरी पर हो या निजी पर, कोई अनाम स्तर है ही नहीं। सवाल कभी यह नहीं होता कि GitHub तक टोकन जाएगा या नहीं, केवल यह कि किसका।

आपका अपना टोकन

इम्पोर्ट कॉल में token भेजिए, या GitHub-to-EAT को --token। रिपॉज़िटरी के issues पढ़ने के अधिकार वाला एक सूक्ष्म पर्सनल एक्सेस टोकन पर्याप्त है। वह अपस्ट्रीम GitHub कॉल चलाता है और कुछ नहीं: वह कभी लॉग में नहीं जाता, कभी ऑडिट लॉग में नहीं जाता, कभी संग्रहीत नहीं होता, और किसी प्रतिक्रिया या त्रुटि में कभी वापस नहीं दिखता।

प्रदर्शन से आगे किसी भी काम के लिए अपना टोकन लाइए। तब आप ऐसा बजट खर्च करते हैं जिसे कोई और नहीं छूता, और किसी और के इम्पोर्ट के कारण कोई पूर्व-जाँच आपको मना नहीं कर सकती।

--engine direct आपको कोई विकल्प नहीं देता। वह इंजन GitHub को Tracker के बजाय आपकी मशीन से पढ़ता है, इसलिए सर्वर का टोकन पहुँच से बाहर है; बिना टोकन वाला चलन कुछ भी फ़ेच या लिखने से पहले उपयोग-त्रुटि के साथ 2 पर बाहर निकल जाता है। आपके परिवेश या .env का GITHUB_TOKEN भी --token की तरह ही गिना जाता है।

टोकन की माँग issues की यात्रा करती है, पूरा इंजन नहीं। direct issues, टिप्पणियाँ और pull requests GraphQL पर पढ़ता है, जिसमें कोई अनाम मोड नहीं है; वह REST को केवल releases की सूची और मुफ़्त /rate_limit जाँच के लिए छूता है। उपकरण अब भी एक पुराना अनाम REST फ़ेचर रखता है जो सार्वजनिक रिपॉज़िटरी का इम्पोर्ट 60 प्रति घंटा के बजट में चला लेता था, पर CLI का कोई रास्ता अब उस तक नहीं पहुँचता और उसे हटाया जाना है — इसलिए direct के लिए --token को अनिवार्य मानें।

तैनाती का साझा टोकन

कोई token न भेजें और सर्वर वह प्लेटफ़ॉर्म टोकन लगा देता है जिसे उसके संचालक ने कॉन्फ़िगर किया है (GITHUB_IMPORT_PAT)। इसके साथ तीन सीमाएँ चलती हैं:

• यह वैकल्पिक कॉन्फ़िगरेशन है। होस्ट किया गया eastagiletracker.com एक प्रदान करता है, इसलिए वहाँ बिना टोकन वाला सार्वजनिक रिपॉज़िटरी इम्पोर्ट काम करता है। स्व-होस्ट की गई स्थापना — डाउनलोड की गई बाइनरी — के पास तब तक कोई नहीं जब तक उसका संचालक परिवेश में GITHUB_IMPORT_PAT सेट न करे, और तब तक वह हर बिना टोकन वाले इम्पोर्ट को 400 import_github_no_token से अस्वीकार कर देती है।
• यह केवल सार्वजनिक रिपॉज़िटरी पढ़ता है। होस्टेड सेवा इसे सार्वजनिक रिपॉज़िटरी पर केवल-पढ़ने के लिए जारी करती है, इसलिए निजी रिपॉज़िटरी को हमेशा आपका अपना टोकन चाहिए।
• तैनाती के सभी कॉलर एक ही बजट साझा करते हैं। बिना टोकन वाला इम्पोर्ट चलने से पहले, सर्वर साझा टोकन के बचे हुए GraphQL अंक पढ़ता है और 500 से नीचे होने पर 400 import_github_shared_quota_low से मना कर देता है। इम्पोर्ट के बीच में बजट खत्म होने पर जॉब import_github_rate_limited_platform के साथ विफल हो जाता है। दोनों संदेश एक ही उपाय बताते हैं: अपना टोकन दीजिए।

टोकन से क्या मिलता है

GitHub अपने दोनों API अलग-अलग नापता है, और बिना प्रमाणीकरण वाली सीमा दो कोटि नीचे है।

GitHub API	किसके लिए	टोकन के साथ	टोकन के बिना
GraphQL	Issues, टिप्पणियाँ, पुल रिक्वेस्ट, उप-issues, निर्भरताएँ	प्रति घंटा 5,000 अंक, क्वेरी द्वारा लौटाए गए नोड्स पर आँके गए	अस्वीकृत — GraphQL में अनाम स्तर है ही नहीं
REST	रिलीज़ (include_releases), और /rate_limit पूर्व-जाँच	प्रति घंटा 5,000 अनुरोध	प्रति घंटा 60 अनुरोध, हर IP पते पर गिने जाते हैं और उसके पीछे के सब लोगों में बँटते हैं

कोई इम्पोर्ट कभी उस 60-प्रति-घंटा वाले स्तर पर नहीं गिरता: भेजने को टोकन ही न हो तो अनुरोध अनाम रूप से दोहराने के बजाय पहले ही अस्वीकार कर दिया जाता है। यह संख्या इसलिए मायने रखती है कि आप इम्पोर्ट के आसपास क्या करते हैं — GitHub को सीधे पढ़ने वाली स्क्रिप्ट, या अन्य क्लाइंट के साथ एक ही नेटवर्क में बैठा शेल, 60 अनुरोध सेकंडों में चुका देता है।

अपना बचा हुआ बजट कभी भी पढ़िए; GET /rate_limit दोनों सीमाओं से मुक्त है, इसलिए इस जाँच की कोई कीमत नहीं:

curl -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/rate_limit

GraphQL अंक अनुरोध नहीं हैं। GitHub किसी क्वेरी को उसके लौटाए नोड्स पर आँकता है, इसलिए 100 issues का एक पृष्ठ उनकी टिप्पणियों और असाइनी सहित बहुत अंक खर्च करता है, और बड़ी रिपॉज़िटरी घंटे भर का बजट REST-युग के आँकड़ों के सुझाव से कहीं कम कॉल में चुका देती है। --dry-run (चरण 3) और dry_run (चरण 4) दोनों असली फ़ेच जितने ही अंक खर्च करते हैं — इसी से उनकी गिनतियाँ भरोसेमंद होती हैं — इसलिए बड़े इम्पोर्ट की पूर्व-जाँच करते समय दो चक्करों का बजट रखिए।

आगे कहाँ जाएँ

• API गाइड — खोज व्याकरण, घटना धारा, थोक ट्रांज़िशन, आइडेम्पोटेंट लेखन, और बाकी सतह।
• संचालन निर्देश — वही संक्रियाएँ इंटरफ़ेस से, और बाकी दस इम्पोर्टर।
• परिचय — स्टेट मशीन और चार स्टोरी प्रकार इसी आकार के क्यों हैं।
• GitHub-to-EAT — इम्पोर्टर की अपनी रिपॉज़िटरी: हर फ़्लैग, दोनों इंजन, और उसमें योगदान कैसे करें।