ข้ามไปยังเนื้อหา
Dee Wan 1.0 ยังอยู่ระหว่างพัฒนาและยังไม่เปิดตัว (pre-MVP) — ดู ขอบเขตผลิตภัณฑ์ 1.0

การส่งมอบผ่าน GitHub

เลือกข้อมูลรับรองตามงานที่เรียกใช้ กลไกยืนยันตัวตนของแต่ละขั้นตอนไม่สามารถใช้แทนกันได้ ตารางนี้อธิบายพฤติกรรมในรีโพซิทอรี ไม่ใช่บริการ GitHub App ที่ Dee Wan โฮสต์ให้

ขั้นตอน การยืนยันตัวตนและสิ่งที่ต้องมี สิ่งที่คงอยู่
การเข้าสู่ระบบหน้าผู้ดูแลและการรับสิทธิ์ผู้ดูแลคนแรก GitHub OAuth App ที่ผู้ดูแลระบบตั้งค่า แบ็กเอนด์ต้องมี GITHUB_CLIENT_ID และ secret GITHUB_CLIENT_SECRET Callback คือ BACKEND_URL + /api/auth/callback/github GitHub ต้องส่ง email ที่ตรงกันทุกตัวอักษร เป็น primary และยืนยันแล้ว โดยตรงกับบัญชีเดิมหรือที่อยู่ผู้ดูแลคนแรกที่ผูกไว้ GitHub account id เชื่อมกับบัญชี CMS เดียวที่มี email หลัง normalize ตรงกัน ระบบไม่เก็บ access token, refresh token หรือ ID token ของ provider
หน้าผู้ดูแล การตั้งค่า → ซอร์สโค้ดและการเผยแพร่ GitHub App ที่ผู้ดูแลระบบตั้งค่า แบ็กเอนด์ต้องมี GITHUB_APP_ID, GITHUB_APP_SLUG, GITHUB_APP_CLIENT_ID, GITHUB_APP_CLIENT_SECRET, GITHUB_APP_PRIVATE_KEY รวมถึง BACKEND_URL และ FRONTEND_URL ที่ถูกต้อง Callback ของ App คือ BACKEND_URL + /api/source/github/callback ผู้ใช้ที่เข้าสู่ระบบต้องมี site:infra และสิทธิ์อ่านโมเดล บันทึกการเชื่อมโยง installation กับรีโพซิทอรี โทเคน installation จำกัดเฉพาะรีโพซิทอรี มีอายุสั้น และถูกเพิกถอนหลังใช้ อย่าใช้ personal token แทนขั้นตอนนี้
npm run wire:github GitHub OAuth device flow ผ่าน DEEWAN_GITHUB_CLIENT_ID การตั้งค่า Cloudflare ต้องมี CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID และ DEE_WAN_URL ต้องระบุ --project และจะเข้ารหัส secrets หลังอ่านคอมมิตที่แน่นอนจากปลายทางเท่านั้น CLI ที่ได้รับอนุญาตเขียน secrets และ variables ของรีโพซิทอรี ข้อมูลรับรอง device flow อยู่ในโปรเซส ส่วนการตั้งค่าเว็บฮุกจะแสดงเป็นข้อความ ไม่ได้บันทึกลง CMS โดยอัตโนมัติ
npm run backend:deliver Device flow ผ่าน DEEWAN_GITHUB_CLIENT_ID ไม่ใช่ App ของหน้าผู้ดูแล ต้องมีรีโพซิทอรีปลายทาง ฐานข้อมูลต้นทางและเส้นทางผลลัพธ์ บัญชีและโทเคน Cloudflare, API_BEARER_TOKEN และ PUBLIC_HOSTNAME เมื่อเลือกย้ายสื่อ ต้องมีข้อมูลรับรองต้นทางและปลายทางของสื่อเพิ่ม รีโพซิทอรีที่สร้างและระบบที่ดีพลอยยังคงอยู่ ข้อมูลรับรอง device flow ไม่ถูกเขียนลงค่ากำหนด git หรือบันทึก CMS เมื่อยืนยันสำเร็จ ระบบเสนอแผนแยกออก แต่ไม่แยกโดยอัตโนมัติ
การเชื่อม GitHub เสริมในตัวติดตั้ง DEEWAN_GITHUB_APP_SLUG เพียงเปิดลิงก์ติดตั้ง App ไม่ใช่การตั้งค่า App แบ็กเอนด์ด้วยตัวแปรทั้งห้า และไม่แทน device flow ของ CLI ทั้งสอง

GitHub OAuth App สำหรับเข้าสู่ระบบ CMS แยกจาก GitHub App สำหรับ ซอร์สโค้ดและการเผยแพร่ และแยกจากแอป device flow ของ CLI ค่า client id และ secret นี้ไม่ได้ให้สิทธิ์ส่งซอร์สไปยังรีโพซิทอรี

โทเคน source ของหน้าผู้ดูแลต้องมีสิทธิ์รีโพซิทอรี contents:write, workflows:write, metadata:read การดีพลอยต้องเพิ่ม actions:write, secrets:write, variables:write ระบบตรวจการเลือกกับรีโพซิทอรีที่ติดตั้ง App หากการตั้งค่า App ของแบ็กเอนด์ขาด ระบบตอบ github_app_not_configured หน้าจอนี้ไม่มีการใช้ device flow แทนโดยอัตโนมัติ

ข้อมูลรับรอง build webhook ที่ wire:github แสดงเป็น fine-grained token สำหรับรีโพซิทอรีนั้นโดยมี Contents: read และ Actions: write อย่าใช้ device token เป็นความลับเว็บฮุกที่จัดเก็บ ตรวจและบันทึกค่าที่แสดงใน ซอร์สโค้ดและการเผยแพร่ → ขั้นสูง — build webhook และการ deploy ด้วยเซสชัน CMS ที่มีสิทธิ์

สร้างเว็บไซต์ Astro และแบ็กเอนด์ในเครื่องก่อน การสร้างผ่าน CMS ที่โฮสต์ยังคงปฏิเสธด้วย source_build_runtime_unavailable เชื่อม GitHub App สำหรับซอร์สกับรีโพซิทอรีส่วนตัวของผู้รับที่ต้องการ แล้วรัน:

Terminal window
npm run wire:github -- --repo owner/site-source --project ./generated/site --managed --operation delivery-20260920-1

ใช้รหัสการดำเนินการใหม่ที่คงเดิมตลอดการส่งมอบแต่ละครั้ง ผู้ที่ลงชื่อเข้าใช้ต้องมี site:infra, site:deploy และสิทธิ์อ่านทุกโมเดลที่สร้าง ระบุ DEE_WAN_SESSION_COOKIE ใน environment ของ CLI และตั้ง DEE_WAN_SESSION_ORIGIN เป็น origin ของหน้า CMS ส่วน DEE_WAN_URL เป็น origin ของแบ็กเอนด์ CLI ส่งเซสชันไปยัง CMS นี้เท่านั้น ค่าดังกล่าวไม่ถูกเขียนในโปรเจกต์ที่สร้าง

ก่อนเปลี่ยนรีโพซิทอรี ให้เตรียม CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_API_TOKEN, API_BEARER_TOKEN, DEE_WAN_HOSTNAME (ชื่อโฮสต์ของแบ็กเอนด์ที่ deploy), ASTRO_ORIGIN (public HTTPS origin ของ Astro ที่คาดไว้) และข้อมูลรับรองของวิธีลงชื่อเข้าใช้อาร์ติแฟกต์ที่เลือกตามด้านล่าง สิทธิ์ GitHub ไม่ใช่สิทธิ์ Cloudflare ตั้งค่าการเชื่อมต่อ preview ของเว็บไซต์กับ public API ของ CMS ที่ถูกต้องก่อนสร้างคอมมิต

CLI สร้างและ push คอมมิตผ่าน Git อ่านคอมมิตแบบเต็มจากปลายทางและตรวจ manifest ก่อนเข้ารหัส secrets ลงในรีโพซิทอรีของผู้รับ CMS บันทึกไซต์ การดำเนินการ ความพยายาม deploy เวอร์ชันซอร์ส และคอมมิตที่แน่นอน โดยเก็บเพียงตัวระบุและ HMAC ของ build token ข้อมูลรับรอง Cloudflare ไม่เข้าสู่คำขอ CMS บัญชีบันทึก manifest หรือไฟล์ที่สร้าง การ dispatch ระบุคอมมิตที่แน่นอน และ workflow checkout พร้อมตรวจคอมมิตนั้นก่อนเรียกสคริปต์ deploy

เก็บรหัสการดำเนินการไว้หากงานหยุดกลางทาง เพิ่ม --resume หลังจากกระบวนการ CLI เดิมหยุดแล้วเท่านั้น และขณะที่ยังเตรียม secrets อยู่ ระบบจะเปลี่ยนและเพิกถอน build token เดิมก่อนทำต่อ เมื่อเริ่ม dispatch แล้ว ให้ใช้ --reconcile กับรหัสเดิม การตรวจสอบนี้อ่าน run ที่ตรงกันใน GitHub โดยไม่ dispatch อีก หากไม่พบ พบซ้ำ หรืออ่าน run ไม่ได้ งานจะยังล็อกอยู่ในสถานะไม่ทราบผล อย่าสร้างการดำเนินการใหม่เพื่อข้ามล็อก ความสำเร็จของ CLI หมายถึง GitHub ยืนยัน run แล้ว ไม่ได้หมายถึง deploy หรือเปิดใช้ preview เสร็จแล้ว

เฉพาะ managed workflow เท่านั้นที่รายงาน completion ด้วย build token เดิม พร้อมการดำเนินการ ความพยายาม คอมมิต และ origin Astro ที่ deploy ซึ่งผูกกันไว้ workflow ที่ deploy จากรีโพซิทอรีอย่างเดียวไม่มี callback ไป CMS Origin เริ่มเป็นสถานะยังไม่ยืนยัน การส่ง completion ซ้ำที่ขัดแย้งกันถูกปฏิเสธ ส่วนข้อความซ้ำที่ตรงกันอาจได้รับผลเดิม ใน ซอร์สโค้ดและการเผยแพร่ ผู้ที่ลงชื่อเข้าใช้และมี site:settings เลือกรายการที่บันทึกและมีสิทธิ์อ่านเพื่อรันการตรวจ preview การกระทำนี้เปิดใช้ได้เฉพาะ origin ที่รายงานไว้ หาก completion หรือการพิสูจน์ล้มเหลว เป้าหมาย renderer เดิมยังคงทำงาน

การยืนยันสิทธิ์ installation และ callback ของ GitHub จริง การรับรีโพซิทอรีส่วนตัว การเข้ารหัส secrets และเพิกถอน token การตรวจ Actions การ deploy Cloudflare, DNS, callback และการพิสูจน์ preview บนระบบที่ deploy ยังคงเป็นขั้นตอนตรวจรับภายนอก

ซอร์สอ้างอิงคือ backend/src/api/source-delivery.ts, backend/src/lib/github/credentials.ts, scripts/github-start.ts, scripts/github.ts, scripts/exit-start.ts และ scripts/install-web.ts ก่อนใช้ CLI ให้อ่านวิธีใช้ที่คำสั่งแสดงจริง หน้านี้ไม่ได้ให้หรือสร้างข้อมูลรับรอง ดำเนินการต่อที่ การติดตั้ง หรือ การแยกระบบ

เลือก ความปลอดภัยของบัญชี จากเมนูตัวตนเพื่อตรวจสอบและยกเลิกการเชื่อมต่อ GitHub ของตนเอง หน้ายืนยันระบุชื่อ GitHub และเตือนว่า session CMS ทั้งหมดจะสิ้นสุด รวมถึง session ปัจจุบัน operation นี้เป็น atomic และปฏิเสธการลบหากจะทำให้ไม่มี active superadmin เหลือวิธีเข้าสู่ระบบที่เปิดใช้ ตั้งค่าครบ และใช้งานได้ มันไม่เปลี่ยน GitHub App installation สำหรับ ซอร์สโค้ดและการเผยแพร่ หรือ credential ของ CLI ซึ่งเป็นคนละส่วน

ดูความปลอดภัยของบัญชี และขั้นตอน acceptance ด้วย provider จริง ที่ lead เป็นเจ้าของ fixture ในเครื่องไม่ใช่หลักฐานว่า callback ของ GitHub สำเร็จ

Better Auth แบบเลือกเปิดในแบ็กเอนด์ที่สร้างเป็นระบบตัวตนแยกกัน GitHub OAuth application ของอาร์ติแฟกต์ใช้ <ARTIFACT_ORIGIN>/api/auth/callback/github แยกจาก OAuth ของ CMS, GitHub App สำหรับ delivery และ device authorization ของ CLI เลือกวิธีในส่วน ซอร์สโค้ดและการเผยแพร่ โดยต้องระบุข้อมูลรับรองสำหรับเป้าหมายอย่างชัดเจน เฉพาะของผู้ให้บริการที่เลือกเท่านั้น Actions secret มีคำนำหน้า ARTIFACT_ รวมถึง ARTIFACT_GITHUB_CLIENT_ID และ ARTIFACT_GITHUB_CLIENT_SECRET Delivery สร้าง auth secret ใหม่ เข้ารหัสด้วย public key เป้าหมาย และรักษา secret เดิมโดยไม่หมุนค่า ไม่คัดลอกตัวตน รหัสผ่าน หรือข้อมูลผู้ให้บริการของ CMS


ยังไม่เปิดตัว (pre-MVP) และยังไม่มีเวอร์ชันเสถียร
คอมมิตซอร์สโค้ด: fe23db481c422b40e317b92fc98116b4c0c26a87 (มีการแก้ไขที่ยังไม่คอมมิต)
วันที่สร้างเอกสาร (UTC): 2026-10-18T09:22:34.630Z
คอมมิตสำหรับอัปเกรด: ระบุไม่ได้: มีการแก้ไขที่ยังไม่คอมมิต. บันทึกการเปลี่ยนแปลง