สร้างโปรเจกต์จากรีโพ GitHub

ชี้เอเจนต์ไปที่รีโพซิทอรี GitHub แล้วคุณจะได้บอร์ดที่พร้อมทำงานกลับมา ทุก issue กลายเป็น story อยู่ในสถานะที่ประวัติของมันบอกไว้ พร้อมเช็กลิสต์ ป้ายกำกับ และไมล์สโตนที่ถูกนำติดมาด้วย จากนั้นเอเจนต์ตัวเดียวกันก็หยิบ story ขึ้นมา รับเป็นเจ้าของ เลื่อนมันผ่านเครื่องสถานะ และแนบพูลรีเควสต์ที่มันเปิดไว้

หน้านี้ว่าด้วยลูปนั้นตั้งแต่ต้นจนจบ ขั้นตอนการเติมข้อมูลมีสองเส้นทาง: GitHub-to-EAT ซึ่งเป็นตัวนำเข้าโอเพนซอร์สของ East Agile ทำได้ในคำสั่งเดียว (ขั้นที่ 3) ส่วน API นำเข้าทำงานเดียวกันทีละการเรียก (ขั้นที่ 4 และ 5) ซึ่งเป็นสิ่งที่เอเจนต์ขับเมื่อมันต้องการตัวจับงาน ทุกอย่างหลังจากนั้นทำงานบน API เพราะประเด็นคือเอเจนต์ต้องทำส่วนที่เหลือได้เองโดยไม่ต้องมีคนดูแล

นี่ไม่ใช่ «การนำเข้าด้วย AI» ที่แยกต่างหาก ขั้นตอนการเติมข้อมูลคือตัวนำเข้า GitHub ตัวเดียวกับที่คุณรันเองได้จาก ตั้งค่าโปรเจกต์ → นำเข้า / ส่งออก อธิบายไว้ใน คำแนะนำการใช้งาน → นำเข้าจาก tracker อื่น เอเจนต์เรียก endpoint เดียวกับที่คุณจะเรียก สิ่งที่หน้านี้เพิ่มเข้ามาคือทุกอย่างรอบ ๆ มัน: ใครถือกุญแจ ตรวจสอบการนำเข้าก่อนที่มันจะเขียนอย่างไร และเอเจนต์ทำอะไรกับบอร์ดเมื่อบอร์ดมีอยู่แล้ว

สิ่งที่คุณต้องมี

• โปรเจกต์หนึ่ง — และเซสชันหรือคีย์ ea_user_… ไว้สร้างมัน
• คีย์เอเจนต์หนึ่งอัน — คีย์ ea_agent_… ที่จำกัดขอบเขตอยู่กับโปรเจกต์นั้น มันต้องการบทบาทใดขึ้นอยู่กับว่าคุณอยากให้เอเจนต์รันลูปนี้มากแค่ไหน ดูขั้นที่ 2 ดูเพิ่มที่ คู่มือ API → คีย์สองชนิด
• โทเคนเข้าถึงส่วนบุคคลของ GitHub — ที่มีสิทธิ์อ่าน issue ของรีโพซิทอรี ทุกการนำเข้าจะยืนยันตัวตน เพราะการดึงข้อมูลวิ่งบน GraphQL API ของ GitHub และ GraphQL ปฏิเสธคำขอที่ไม่มีโทเคน คุณละมันได้เฉพาะเมื่อ Tracker ดึงแทนคุณเท่านั้น: รีโพสาธารณะ บนดีพลอยเมนต์ที่มีโทเคนสำรองแบบใช้ร่วม (บริการโฮสต์ eastagiletracker.com มีอยู่หนึ่ง ส่วนการติดตั้งแบบโฮสต์เองจะไม่มีจนกว่าผู้ดูแลจะตั้งค่า GITHUB_IMPORT_PAT) และไม่ใช่กับ --engine direct ของ GitHub-to-EAT ดู โทเคนและขีดจำกัดอัตรา
• Node.js 22+ — เฉพาะเส้นทาง GitHub-to-EAT ในขั้นที่ 3 เส้นทาง 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 — สิทธิ์น้อยที่สุด เอเจนต์รับ story ย้าย story แสดงความคิดเห็น และแนบพูลรีเควสต์ได้ แต่นำเข้าไม่ได้ คุณรันการนำเข้าเองด้วยคีย์ของคุณ (ขั้นที่ 5) แล้วส่งบอร์ดต่อให้เอเจนต์

ไม่ว่าทางไหน อย่าปล่อยไว้ที่ค่าเริ่มต้น คีย์เอเจนต์ใหม่จะเป็น viewer จนกว่าคุณจะระบุเป็นอย่างอื่น และ viewer อ่านบอร์ดได้แต่รับหรือย้าย story ไม่ได้ — ซึ่งเป็นเนื้อหาส่วนใหญ่ของลูปนี้

คีย์เอเจนต์สำคัญตรงนี้ด้วยเหตุผลที่เกินกว่าเรื่องสิทธิ์เข้าถึง คีย์เอเจนต์ทำหน้าที่เป็น ผู้ร่วมงานที่มีชื่อในโปรเจกต์เดียว ดังนั้นทุก story ที่มันสร้าง ทุกการเปลี่ยนสถานะที่มันทำ และทุกความคิดเห็นที่มันเขียน จะถูกบันทึกให้เอเจนต์ตัวนั้นในประวัติ — แยกแยะออกจากงานของคุณเองได้ แทนที่จะปนกันไปหมด

export TRACKER_TOKEN="ea_agent_xxxxx"

ให้เอเจนต์อ่าน /meta ก่อนอย่างอื่นทั้งหมด:

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

นั่นตอบคำถามสองข้อที่ไม่อย่างนั้นเอเจนต์ก็ต้องเดาเอา: คีย์ผูกกับโปรเจกต์ไหน (auth.project_id) และการย้ายสถานะแบบใดถูกต้องสำหรับ story แต่ละชนิด (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	ตรวจล่วงหน้า แล้วพิมพ์แผนที่มันจะทำ — จะนำเข้า story กี่รายการ จะข้ามกี่รายการเพราะมีอยู่แล้ว — และไม่เขียนอะไรเลย ไม่ต้องใช้ --yes
--include	จะนำเข้าชนิดใดบ้าง คั่นด้วยจุลภาค: issues,prs,milestones,releases,deps ค่าเริ่มต้นคือ issues และทุกการเลือกต้องมีมันอยู่ด้วย นี่คือตัวเลือกชุดเดียวกับตารางในขั้นที่ 6
--token	โทเคนเข้าถึงส่วนบุคคล GitHub ของคุณ (GITHUB_TOKEN ในสภาพแวดล้อมหรือใน .env ก็นับ) มันต้องมี repo หรือสิทธิ์แบบละเอียด Issues: Read บนรีโพนั้น จำเป็นสำหรับรีโพส่วนตัว สำหรับเซิร์ฟเวอร์ที่ไม่มี token สำรองแบบใช้ร่วม และเสมอสำหรับ --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 เป็นแบบอะซิงโครนัส รวมถึงการลองแบบไม่เขียนจริงด้วย: endpoint คืน 202 พร้อมตัวจับงาน ไม่ใช่ผลลัพธ์ และจำนวนต่าง ๆ จะมาอยู่บนงานเมื่อคุณสำรวจสถานะของมัน (ขั้นที่ 5) งานของการลองแบบไม่เขียนจริงจะไปถึงสถานะ done เหมือนของจริง ต่างกันตรงที่ไม่มีอะไรถูกเขียนลงไป

5. รันการนำเข้า

เอา dry_run ออกแล้วส่งอีกครั้ง เช่นเดิม endpoint คืน 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_…" ถ้าละไว้ เซิร์ฟเวอร์จะแทนที่ด้วย token แพลตฟอร์มที่ใช้ร่วมกัน ซึ่งอ่านได้เฉพาะรีโพสาธารณะและถูกหักรวมกับผู้เรียกทุกรายบนดีพลอยเมนต์ — โทเคนและขีดจำกัดอัตรา อธิบายว่ามันทำให้คุณเสียอะไร ไม่ว่าจะใช้โทเคนใด มันขับเฉพาะการเรียก GitHub ต้นทางเท่านั้น ไม่ถูกบันทึกลงล็อก ไม่เข้าบันทึกตรวจสอบ ไม่ถูกเก็บ และไม่ถูกส่งกลับในการตอบหรือในข้อผิดพลาด

การรันซ้ำปลอดภัย แถวที่ถูกนำเข้าไปแล้วจะถูกจับคู่ด้วย id ต้นทางแล้วข้ามไป ไม่ถูกสร้างซ้ำ การนำเข้าครั้งที่สองเติมบอร์ดด้วยสิ่งที่ปรากฏขึ้นหลังครั้งแรก

6. อะไรบ้างที่ลงมาบนบอร์ด

issue ถูกนำเข้าโดยค่าเริ่มต้น ที่เหลือเป็นแบบเลือกเข้าร่วม หนึ่งแฟล็กต่อหนึ่งชนิด:

จาก GitHub	กลายเป็น	แฟล็ก
Issue	หนึ่ง story เปิดอยู่ → unstarted ใน Backlog ปิดแล้ว → accepted หรือ rejected เมื่อ GitHub ระบุว่า issue ถูกปิดแบบ not_planned หรือ duplicate (story จะได้ป้ายกำกับที่ตรงกัน)	ค่าเริ่มต้น
เช็กลิสต์ในเนื้อหา issue	งาน — แต่ละบรรทัด - [ ] / - [x] กลายเป็นหนึ่งงานตามลำดับในเนื้อหา และ [x] มาถึงในสถานะเสร็จแล้ว เช็กลิสต์ยังคงอยู่ในคำอธิบายด้วย	ค่าเริ่มต้น
ป้ายกำกับ	ป้ายกำกับ ยกมาตามเดิม	ค่าเริ่มต้น
พูลรีเควสต์	หนึ่ง story ที่มีป้ายกำกับ pull-request เปิดอยู่ → started, ผสานแล้ว → accepted, ปิดโดยไม่ผสาน → rejected	include_pull_requests
ไมล์สโตน	หนึ่ง epic ตั้งชื่อตามไมล์สโตน ตัดซ้ำด้วยหัวข้อ — issue สองรายการที่ใช้ไมล์สโตนเดียวกันจะลงใน epic เดียว ถ้าปิดแฟล็ก มันจะติดมาเป็นป้ายกำกับ milestone:<หัวข้อ> แทน	include_milestones
รีลีส	หนึ่ง release story เผยแพร่แล้ว → accepted, ฉบับร่าง → unstarted	include_releases
การพึ่งพาระหว่าง issue	หนึ่ง blocker บน story เฉพาะ issue เท่านั้น ไม่ใช่พูลรีเควสต์	include_dependencies

ชนิดของ story ถูกอนุมานเมื่อ issue ไม่ได้ระบุ ป้ายกำกับที่มี bug, fix หรือ defect — หรือหัวข้อที่ขึ้นต้นด้วย fix หรือ bug — ทำให้มันเป็นบั๊ก ส่วน chore, maintenance, devops หรือ infra ทำให้เป็น chore นอกนั้นเป็น feature เรื่องนี้ควรรู้ก่อนนำเข้า เพราะใน East Agile Tracker มีเพียง feature เท่านั้นที่มี point และมีเพียง feature เท่านั้นที่ป้อนค่าความเร็ว ดู บทนำ → Story

7. เอเจนต์ทำงานกับ story

ตอนนี้บอร์ดมีประวัติแล้ว และเอเจนต์ก็มีกุญแจ ลูปจากตรงนี้ไปคือสี่การเรียก

หา story สักอัน หรือเขียนขึ้นมาเอง กรองบอร์ดหาอะไรสักอย่างที่จะหยิบขึ้นมาทำ:

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

import_source=github จำกัดให้เหลือเฉพาะสิ่งที่การนำเข้าพามาเท่านั้น ถ้าเอเจนต์เจองานที่รีโพไม่เคยบันทึกไว้ มันจะสร้าง story ขึ้นมาเองแทน — ดู คู่มือ API → สร้าง story

รับเป็นของตัวเอง เอเจนต์เพิ่มตัวเองเป็นเจ้าของโดยส่ง 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"}'

URL พูลรีเควสต์ของ GitHub ถูกจดจำได้เอง — คุณไม่ต้องบอก story กับโค้ดที่ปิดมันตอนนี้อยู่ห่างกันเพียงคลิกเดียว ทั้งสองทิศทาง

จบมัน เปลี่ยนสถานะเป็น finished แล้วหยุดตรงนั้น feature ยังมี delivered และ accepted รออยู่ข้างหน้า และนั่นคือด่านตรวจทาน: คนอื่นที่ไม่ใช่เอเจนต์เป็นผู้ตัดสินว่างานถูกต้อง ส่วน chore ไม่มีด่านแบบนั้น — started → accepted คือเส้นทางที่เหลือทั้งหมดของมัน

โทเคนและขีดจำกัดอัตรา

ทุกการนำเข้าจะยืนยันตัวตน การดึง issue ความคิดเห็น และพูลรีเควสต์วิ่งบน GraphQL API ของ GitHub และ GraphQL ปฏิเสธคำขอที่ไม่มีโทเคน — ไม่มีชั้นแบบไม่ระบุตัวตน ไม่ว่าจะบนรีโพสาธารณะหรือส่วนตัว คำถามไม่เคยอยู่ที่ว่า จะมี โทเคนไปถึง GitHub หรือไม่ แต่อยู่ที่ว่าเป็นโทเคน ของใคร เท่านั้น

โทเคนของคุณเอง

ส่ง token ในการเรียกนำเข้า หรือ --token ให้ GitHub-to-EAT โทเคนเข้าถึงส่วนบุคคลแบบละเอียดที่มีสิทธิ์อ่าน issue ของรีโพซิทอรีก็พอแล้ว มันขับเฉพาะการเรียก GitHub ต้นทางเท่านั้น ไม่ถูกบันทึกลงล็อก ไม่เข้าบันทึกตรวจสอบ ไม่ถูกเก็บ และไม่ถูกส่งกลับในการตอบหรือในข้อผิดพลาด

เอาโทเคนของคุณเองมาใช้กับอะไรก็ตามที่เกินระดับการสาธิต แล้วคุณจะใช้งบประมาณที่ไม่มีใครอื่นแตะ และไม่มีการตรวจล่วงหน้าใดปฏิเสธคุณเพราะการนำเข้าของคนอื่น

--engine direct ไม่เหลือทางเลือกให้คุณ เอนจินนั้นอ่าน GitHub จากเครื่องของคุณแทนที่จะผ่าน Tracker ดังนั้น token ของเซิร์ฟเวอร์จึงเอื้อมไม่ถึง การรันที่ไม่มีโทเคนจะออกด้วยรหัส 2 พร้อมข้อผิดพลาดการใช้งาน ก่อนที่มันจะดึงหรือเขียนอะไรทั้งสิ้น GITHUB_TOKEN ในสภาพแวดล้อมหรือใน .env ของคุณก็นับ เช่นเดียวกับ --token

สิ่งที่บังคับให้ต้องมีโทเคนคือการไล่อ่าน issue ไม่ใช่ทั้งเอนจิน direct อ่าน issue ความคิดเห็น และ pull request ผ่าน GraphQL ซึ่งไม่มีโหมดนิรนาม มันแตะ REST เฉพาะรายการ releases และการตรวจ /rate_limit ที่ไม่มีค่าใช้จ่ายเท่านั้น เครื่องมือนี้ยังแถมตัวดึงข้อมูล REST แบบนิรนามรุ่นเก่าที่เคยนำเข้ารีโพสาธารณะได้ภายในงบ 60 ต่อชั่วโมง แต่ไม่มีเส้นทางใดใน CLI ที่ไปถึงมันอีกแล้วและมีกำหนดจะถูกลบ ดังนั้นให้ถือว่า --token จำเป็นสำหรับ direct

token ที่ใช้ร่วมกันของดีพลอยเมนต์

อย่าส่ง token ใด ๆ แล้วเซิร์ฟเวอร์จะแทนที่ด้วย token แพลตฟอร์มที่ผู้ดูแลตั้งค่าไว้ (GITHUB_IMPORT_PAT) มีข้อจำกัดสามข้อติดมาด้วย:

• มันเป็นการตั้งค่าแบบเลือกได้ บริการโฮสต์ eastagiletracker.com จัดเตรียมไว้ให้หนึ่งอัน การนำเข้ารีโพสาธารณะแบบไม่มีโทเคนจึงทำงานได้ที่นั่น ส่วนการติดตั้งแบบโฮสต์เอง — ไบนารีที่ดาวน์โหลดมา — จะไม่มีจนกว่าผู้ดูแลจะตั้งค่า GITHUB_IMPORT_PAT ในสภาพแวดล้อม และจนกว่าจะถึงตอนนั้นมันจะปฏิเสธทุกการนำเข้าแบบไม่มีโทเคนด้วย 400 import_github_no_token
• มันอ่านได้เฉพาะรีโพสาธารณะ บริการโฮสต์สร้างมันแบบอ่านอย่างเดียวบนรีโพสาธารณะ ดังนั้นรีโพส่วนตัวจึงต้องใช้โทเคนของคุณเองเสมอ
• ผู้เรียกทุกรายบนดีพลอยเมนต์แบ่งงบประมาณก้อนเดียวกัน ก่อนที่การนำเข้าแบบไม่มีโทเคนจะรัน เซิร์ฟเวอร์จะอ่านพอยต์ GraphQL ที่เหลือของ token ร่วม แล้วปฏิเสธด้วย 400 import_github_shared_quota_low เมื่อต่ำกว่า 500 งบประมาณที่หมดกลางคันจะทำให้งานล้มเหลวด้วย import_github_rate_limited_platform ทั้งสองข้อความชี้ทางแก้เดียวกัน: ใช้โทเคนของคุณเอง

โทเคนซื้ออะไรให้คุณ

GitHub วัดสอง API ของมันแยกกัน และเพดานตอนไม่ยืนยันตัวตนต่ำกว่าถึงสองระดับขนาด

GitHub API	ใช้กับ	มีโทเคน	ไม่มีโทเคน
GraphQL	issue, ความคิดเห็น, พูลรีเควสต์, issue ย่อย, การพึ่งพา	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 issue พร้อมความคิดเห็นและผู้รับผิดชอบก็กินพอยต์ไปมาก และรีโพขนาดใหญ่ใช้งบประมาณรายชั่วโมงหมดในจำนวนการเรียกที่น้อยกว่าตัวเลขยุค REST บอกไว้มาก ทั้ง --dry-run (ขั้นที่ 3) และ dry_run (ขั้นที่ 4) ต่างใช้พอยต์เท่ากับการดึงจริง — นั่นแหละที่ทำให้จำนวนของมันเชื่อถือได้ — ดังนั้นเวลาตรวจล่วงหน้าการนำเข้าก้อนใหญ่ ให้กันงบไว้สองรอบ

ไปที่ไหนต่อ

• คู่มือ API — ไวยากรณ์การค้นหา สตรีมเหตุการณ์ การเปลี่ยนสถานะเป็นกลุ่ม การเขียนแบบ idempotent และส่วนที่เหลือของพื้นผิว
• คำแนะนำการใช้งาน — การทำงานชุดเดียวกันจากหน้าจอ และตัวนำเข้าอีกสิบตัว
• บทนำ — ทำไมเครื่องสถานะและ story ทั้งสี่ชนิดจึงมีรูปทรงแบบนี้
• GitHub-to-EAT — รีโพซิทอรีของตัวนำเข้าเอง: ทุกแฟล็ก ทั้งสองเอนจิน และวิธีร่วมพัฒนา