GitHub களஞ்சியத்திலிருந்து ஒரு திட்டத்தை நிரப்புதல்

ஒரு ஏஜென்டை ஒரு GitHub களஞ்சியத்தை நோக்கித் திருப்புங்கள்; வேலை செய்யக்கூடிய ஒரு பலகை திரும்பக் கிடைக்கும்: ஒவ்வொரு issue-ம் ஒரு ஸ்டோரியாக, அதன் வரலாறு சொல்லும் நிலையிலேயே, சரிபார்ப்புப் பட்டியல்கள், லேபிள்கள், மைல்கற்கள் உடன் வர. பிறகு அதே ஏஜென்ட் ஒரு ஸ்டோரியை எடுத்து, தன்னுடையதாக்கி, நிலை இயந்திரத்தின் வழியே நகர்த்தி, தான் திறந்த புல் ரிக்வெஸ்டை இணைக்கிறது.

இந்தப் பக்கம் அந்த வளையத்தை முனை முதல் முனை வரை விவரிக்கிறது. நிரப்பும் படிக்கு இரண்டு வழிகள் உண்டு: East Agile-இன் திறந்த மூல இறக்குமதிக் கருவியான GitHub-to-EAT ஒரே கட்டளையில் முடிக்கிறது (படி 3); இறக்குமதி API அதே வேலையை அழைப்பு வாரியாகச் செய்கிறது (படிகள் 4 மற்றும் 5) — வேலைப் பிடிமானம் வேண்டும் என்றால் ஏஜென்ட் இயக்குவது இதைத்தான். அதற்குப் பிறகான அனைத்தும் API மீது இயங்குகின்றன, ஏனெனில் மீதியை ஏஜென்ட் கண்காணிப்பின்றிச் செய்ய முடிவதே இதன் நோக்கம்.

இது தனியான «AI இறக்குமதி» அல்ல. நிரப்பும் படி என்பது திட்ட அமைப்புகள் → இறக்குமதி / ஏற்றுமதி வழியாக நீங்களே கையால் இயக்கக்கூடிய அதே GitHub இறக்குமதிக் கருவிதான்; செயல்பாட்டு வழிமுறைகள் → பிற trackers-இலிருந்து இறக்குமதி அதை விவரிக்கிறது. நீங்கள் அழைக்கும் அதே எண்ட்பாயிண்டைத்தான் ஏஜென்டும் அழைக்கிறது. இந்தப் பக்கம் சேர்ப்பது அதைச் சுற்றியுள்ள அனைத்தும்: சாவியை யார் வைத்திருக்கிறார்கள், எழுதுவதற்கு முன் இறக்குமதியை எப்படிச் சரிபார்ப்பது, பலகை உருவான பின் ஏஜென்ட் அதை என்ன செய்கிறது.

உங்களுக்குத் தேவையானவை

• ஒரு திட்டம் — மற்றும் அதை உருவாக்க ஒரு அமர்வு அல்லது 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 திருப்பித் தருகிறது; நீங்கள் வேலையை poll செய்யும்போது எண்ணிக்கைகள் அதில் வந்து சேரும் (படி 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_…" அனுப்புங்கள். விட்டுவிட்டால் சேவையகம் பகிரப்பட்ட தள டோக்கனை இடுகிறது; அது பொது களஞ்சியங்களை மட்டுமே படிக்கும், அதன் நிதி அந்த நிறுவலின் ஒவ்வொரு அழைப்பாளரிடமிருந்தும் கழிக்கப்படும் — டோக்கன்களும் வீத வரம்புகளும் அதன் விலையைச் சொல்கிறது. எந்த டோக்கன் இயங்கினாலும், அது upstream GitHub அழைப்புகளை மட்டுமே இயக்குகிறது: அது ஒருபோதும் பதிவேட்டில் எழுதப்படுவதில்லை, தணிக்கைப் பதிவேட்டில் வருவதில்லை, சேமிக்கப்படுவதில்லை, பதிலிலோ பிழையிலோ திருப்பி எதிரொலிக்கப்படுவதில்லை.

மீண்டும் இயக்குவது பாதுகாப்பானது. ஏற்கனவே இறக்குமதி ஆன வரிசை அதன் மூல id வழியே பொருத்தப்பட்டுத் தவிர்க்கப்படும், நகலாகாது. இரண்டாவது இறக்குமதி முதலுக்குப் பிறகு தோன்றியவற்றால் பலகையை நிரப்புகிறது.

6. பலகையில் என்ன இறங்குகிறது

Issues இயல்பாகவே இறக்குமதியாகின்றன. மற்ற அனைத்தும் விருப்பத் தேர்வு, ஒரு வகைக்கு ஒரு கொடி:

GitHub-இலிருந்து	ஆவது	கொடி
Issue	ஒரு ஸ்டோரி. திறந்திருந்தால் → Backlog-இல் unstarted. மூடியிருந்தால் → accepted; GitHub அந்த issue not_planned அல்லது duplicate எனச் சொன்னால் → rejected (ஸ்டோரி அதற்கேற்ற லேபிளைச் சுமக்கும்).	இயல்பு
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 மட்டுமே points சுமக்கின்றன, features மட்டுமே velocity-க்கு உணவளிக்கின்றன. அறிமுகம் → ஸ்டோரிகள் பார்க்கவும்.

7. ஏஜென்ட் ஒரு ஸ்டோரியில் வேலை செய்கிறது

இப்போது பலகைக்கு வரலாறு உண்டு, ஏஜென்டுக்குச் சாவி உண்டு. இங்கிருந்து வளையம் நான்கு அழைப்புகள்.

ஒரு ஸ்டோரியைக் கண்டுபிடியுங்கள், அல்லது ஒன்றை எழுதுங்கள். எடுக்கத்தக்க ஏதோ ஒன்றுக்காகப் பலகையை வடிகட்டுங்கள்:

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

import_source=github அதை இறக்குமதி கொண்டுவந்தவற்றுக்குக் குறுக்குகிறது. களஞ்சியம் ஒருபோதும் பதிவு செய்யாத வேலையை ஏஜென்ட் கண்டுபிடித்தால், அது ஸ்டோரியையே உருவாக்கிக்கொள்கிறது — API வழிகாட்டி → ஒரு ஸ்டோரியை உருவாக்குதல் பார்க்கவும்.

அதை உரிமை கொள்ளுங்கள். ஏஜென்ட் காலியான உடலை POST செய்து தன்னை உரிமையாளராகச் சேர்த்துக்கொள்கிறது:

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-ஐப் படிக்கும் உரிமையுள்ள ஒரு நுண்ணிய தனிப்பட்ட அணுகல் டோக்கன் போதும். அது upstream GitHub அழைப்புகளை மட்டுமே இயக்குகிறது: ஒருபோதும் பதிவேட்டில் எழுதப்படுவதில்லை, தணிக்கைப் பதிவேட்டில் வருவதில்லை, சேமிக்கப்படுவதில்லை, பதிலிலோ பிழையிலோ திருப்பி எதிரொலிக்கப்படுவதில்லை.

ஒரு காட்சி விளக்கத்தைத் தாண்டிய எதற்கும் உங்கள் சொந்த டோக்கனைக் கொண்டு வாருங்கள். அப்போது வேறு யாரும் தொடாத நிதியைச் செலவழிக்கிறீர்கள்; வேறொருவரின் இறக்குமதிக்காக எந்த முன்சோதனையும் உங்களை மறுக்க முடியாது.

--engine direct உங்களுக்குத் தேர்வையே விடுவதில்லை. அந்த எஞ்சின் GitHub-ஐ Tracker வழியாக அல்லாமல் உங்கள் இயந்திரத்திலிருந்தே படிக்கிறது; எனவே சேவையகத்தின் டோக்கன் எட்டாத தொலைவில். டோக்கன் இல்லாத ஓட்டம் எதையும் எடுப்பதற்கோ எழுதுவதற்கோ முன்பே பயன்பாட்டுப் பிழையுடன் 2 இல் வெளியேறும். உங்கள் சூழலிலோ .env இலோ உள்ள GITHUB_TOKEN-ம் --token போலவே கணக்கில் வரும்.

டோக்கனை கட்டாயமாக்குவது issues வழிநடை, முழு எஞ்சின் அல்ல. direct issues, கருத்துகள், pull requests ஆகியவற்றை GraphQL வழியாகப் படிக்கிறது; 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 வழிகாட்டி — தேடல் இலக்கணம், நிகழ்வுத் தாரை, மொத்த நிலைமாற்றங்கள், idempotent எழுத்துகள், மீதிப் பரப்பு.
• செயல்பாட்டு வழிமுறைகள் — அதே செயல்கள் இடைமுகத்திலிருந்து, மற்றும் மற்ற பத்து இறக்குமதிக் கருவிகள்.
• அறிமுகம் — நிலை இயந்திரமும் நான்கு ஸ்டோரி வகைகளும் ஏன் இந்த வடிவில் உள்ளன.
• GitHub-to-EAT — இறக்குமதிக் கருவியின் சொந்தக் களஞ்சியம்: ஒவ்வொரு கொடி, இரு எஞ்சின்கள், அதற்கு எப்படிப் பங்களிப்பது.