จัดการและดีบักเวิร์กโฟลว์ในการดําเนินการ GitHub
โปรดทราบว่าเป้าหมายของคุณคือการทําให้กระบวนการสร้างและเผยแพร่โค้ดเป็นแบบอัตโนมัติเพื่อให้คุณลักษณะได้รับการอัปเดตทุกครั้งที่นักพัฒนาเพิ่มการเปลี่ยนแปลงไปยังฐานโค้ด
หากต้องการใช้กระบวนการนี้ คุณจะเรียนรู้วิธีการ:
- ระบุเหตุการณ์ที่ทริกเกอร์เวิร์กโฟลว์
- ใช้บันทึกเวิร์กโฟลว์การดําเนินการ GitHub
- บันทึกและเข้าถึงวัตถุที่สร้างขึ้น
- เพิ่มป้ายกํากับลงในคําขอดึงข้อมูลโดยอัตโนมัติหลังจากการตรวจสอบ
ระบุเหตุการณ์ที่ทริกเกอร์เวิร์กโฟลว์
การทําความเข้าใจสิ่งที่ทําให้เวิร์กโฟลว์การดําเนินการ GitHub มีความสําคัญสําหรับการดีบัก การตรวจสอบ และการปรับปรุงไปป์ไลน์ CI/CD ชนิดของทริกเกอร์รวมถึงการส่งไปยังสาขา คําขอดึงข้อมูลที่สร้างหรืออัปเดต งานตามกําหนดเวลา หรือการจัดส่งด้วยตนเอง คุณสามารถระบุเหตุการณ์ทริกเกอร์ได้โดยตรวจสอบการเรียกใช้เวิร์กโฟลว์ การเปลี่ยนแปลงที่เก็บ และปัญหา GitHub หรือคําขอดึงข้อมูลที่เกี่ยวข้อง
ทริกเกอร์เวิร์กโฟลว์คืออะไร
ทริกเกอร์เวิร์กโฟลว์คือ เหตุการณ์ที่ทําให้เวิร์กโฟลว์ทํางาน GitHub สนับสนุนทริกเกอร์ชนิดต่าง ๆ รวมถึง:
-
pushหรือpull_request(ขึ้นอยู่กับการเปลี่ยนแปลงรหัส) -
workflow_dispatch(ทริกเกอร์ด้วยตนเอง) -
schedule(งาน cron) -
repository_dispatch(ระบบภายนอก) - ปัญหา การสนทนา และเหตุการณ์คําขอดึงข้อมูล (ตัวอย่างเช่น
issues.opened)pull_request.closed
ระบุเหตุการณ์ทริกเกอร์
คุณสามารถระบุเหตุการณ์ทริกเกอร์เวิร์กโฟลว์ได้หลายวิธี:
ใช้ UI การดําเนินการ GitHub:
- ในที่เก็บของคุณ ให้เลือกแท็บ การดําเนินการ
- เลือกการเรียกใช้เวิร์กโฟลว์
ชนิดเหตุการณ์ เช่น
push,pull_requestหรือworkflow_dispatchจะปรากฏที่ด้านบนของสรุปการเรียกใช้เวิร์กโฟลว์ใช้
github.event_nameในบันทึกหรือในเวิร์กโฟลว์GitHub เปิดเผยข้อมูลบริบทในระหว่างการเรียกใช้เวิร์กโฟลว์ ตัวแปร
github.event_nameบอกให้คุณทราบว่าเหตุการณ์ใดที่ทริกเกอร์เวิร์กโฟลว์คุณสามารถพิมพ์ข้อมูลในขั้นตอนสําหรับการดีบัก:
-name: Show event trigger run: echo "Triggered by ${{ github.event_name }}"
ใช้รายละเอียดการเรียกใช้เวิร์กโฟลว์:
- ถ้าคุณตรวจสอบการเรียกใช้เวิร์กโฟลว์ทางโปรแกรม เช่นโดยใช้ API วัตถุการเรียกใช้จะ
eventมีคุณสมบัติที่ระบุทริกเกอร์ - คุณสามารถค้นหาบันทึก Secure Hash Algorithm (SHA), actor และ timestamp เพื่อติดตามสิ่งที่เป็นสาเหตุให้ทริกเกอร์
- ถ้าคุณตรวจสอบการเรียกใช้เวิร์กโฟลว์ทางโปรแกรม เช่นโดยใช้ API วัตถุการเรียกใช้จะ
อนุมานทริกเกอร์จากผลกระทบของที่เก็บข้อมูล
คุณอาจไม่มีการเข้าถึงโดยตรงไปยังการเรียกใช้เวิร์กโฟลว์ แต่คุณยังคงต้องการอนุมานสิ่งที่ทําให้เวิร์กโฟลว์ทํางานตามกิจกรรมของที่เก็บ:
| พฤติกรรมที่สังเกตได้ | เหตุการณ์ทริกเกอร์ |
|---|---|
การยอมรับใหม่ถูก main ส่งไปยัง และเรียกใช้เวิร์กโฟลว์ |
push เหตุการณ์ |
| คําขอดึงข้อมูลถูกเปิดหรืออัปเดต |
pull_request เหตุการณ์ |
| ผู้สนับสนุนเรียกใช้เวิร์กโฟลว์ด้วยตนเอง | workflow_dispatch |
| เวิร์กโฟลว์จะทํางานทุกวันในเวลาที่กําหนด |
schedule (ครอน) |
| เวิร์กโฟลว์เรียกใช้หลังจากการเรียกบริการภายนอก | repository_dispatch |
| เวิร์กโฟลว์เรียกใช้เมื่อมีการเพิ่มป้ายชื่อหรือข้อคิดเห็นลงในประเด็น |
issues.* เหตุการณ์ |
เมื่อตรวจทานการประทับเวลา กิจกรรมการดึงคําขอ และประวัติการยอมรับ คุณมักจะสามารถระบุสิ่งที่การดําเนินการที่ทําให้เวิร์กโฟลว์ทํางานได้
เพื่อสรุปวิธีการระบุสิ่งที่ทริกเกอร์เวิร์กโฟลว์:
- ตรวจสอบสรุปการเรียกใช้เวิร์กโฟลว์บนแท็บ การดําเนินการ
- พิมพ์หรือเข้าสู่ระบบ
github.event_nameภายในเวิร์กโฟลว์สําหรับการมองเห็น - เปรียบเทียบการประทับเวลาและกิจกรรมที่เก็บข้อมูล (ยืนยัน คําขอดึงข้อมูล ปัญหา) เพื่ออนุมานทริกเกอร์
- ใช้บริบทแบบเต็ม
eventสําหรับการตรวจสอบอย่างลึกซึ้งขึ้น
แนวทางปฏิบัติเหล่านี้ช่วยให้คุณแก้จุดบกพร่อง การตรวจสอบ และปรับปรุงความน่าเชื่อถือของเวิร์กโฟลว์ในไปป์ไลน์การพัฒนาและการปรับใช้ของคุณ
ทําความเข้าใจเกี่ยวกับผลของเวิร์กโฟลว์โดยการอ่านไฟล์การกําหนดค่า
เมื่อต้องการทําความเข้าใจผลกระทบของเวิร์กโฟลว์จากการอ่านไฟล์การกําหนดค่า ให้วิเคราะห์โครงสร้างและเนื้อหาของไฟล์ที่.ymlจัดเก็บไว้ใน.github/workflows/
ไฟล์การกําหนดค่าเวิร์กโฟลว์จะระบุข้อมูลต่อไปนี้เกี่ยวกับเวิร์กโฟลว์:
- เมื่อเรียกใช้งาน (ในส่วน)
on - สิ่งที่ทํา (ใน
jobsและsteps) - ตําแหน่งที่เรียกใช้ (
runs-onส่วน) - ทําไมจึงทํางาน (วัตถุประสงค์ เช่น การทดสอบ การปรับใช้ หรือการวางซับใน)
- วิธีการทํางานของเงื่อนไขเฉพาะ (สภาพแวดล้อม ตัวกรอง ตรรกะ)
ตีความเอฟเฟ็กต์เวิร์กโฟลว์
ระบุทริกเกอร์
หากต้องการระบุการดําเนินการที่เริ่มต้นเวิร์กโฟลว์ ให้ดู
onส่วนของเวิร์กโฟลว์เช่น:
on: push: branches: [main] pull_request: types: [opened, synchronize] workflow_dispatch:เวิร์กโฟลว์ตัวอย่างนี้:
- เรียกใช้โดยอัตโนมัติเมื่อรหัสถูกส่งไปยังสาขาหลัก (
push) - เรียกใช้เมื่อสร้างหรืออัปเดตคําขอดึงข้อมูล (
pull_request) - สามารถทริกเกอร์ด้วยตนเองโดยผู้ใช้ (
workflow_dispatch)
- เรียกใช้โดยอัตโนมัติเมื่อรหัสถูกส่งไปยังสาขาหลัก (
ระบุงานเวิร์กโฟลว์และขั้นตอน
เมื่อต้องกําหนดสิ่งที่เวิร์กโฟลว์ทํา ให้ดู
jobsส่วน และstepsของเวิร์กโฟลว์เช่น:
jobs: test: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Install dependencies run: npm install - name: Run tests run: npm testเวิร์กโฟลว์ตัวอย่างนี้:
- ใช้สภาพแวดล้อมเสมือน Linux (
runs-on) - ตรวจสอบรหัสของที่เก็บ (
steps>name) - ติดตั้งการขึ้นต่อกันของโครงการ (
steps>name) - เรียกใช้การทดสอบอัตโนมัติ (
steps>name)
- ใช้สภาพแวดล้อมเสมือน Linux (
ประเมินวัตถุประสงค์และผลลัพธ์ของเวิร์กโฟลว์
โดยการอ่านไฟล์การกําหนดค่า คุณสามารถอธิบายผลลัพธ์ที่ตั้งใจไว้ของเวิร์กโฟลว์:
"เวิร์กโฟลว์นี้เป็นไปป์ไลน์การรวมอย่างต่อเนื่อง (CI) ตรวจสอบให้แน่ใจว่าโค้ดใหม่ใด ๆ ที่ส่งไปยังที่เก็บหรือส่งผ่านคําขอดึงข้อมูลจะได้รับการทดสอบโดยอัตโนมัติ ถ้าการทดสอบล้มเหลว UI เวิร์กโฟลว์ GitHub จะแสดงผลลัพธ์นี้เพื่อช่วยรักษาคุณภาพโค้ด"
ระบุหรือตั้งค่าคุณลักษณะทางเลือกที่มีผลต่อการเรียกใช้เวิร์กโฟลว์:
-
envตั้งค่าตัวแปรสภาพแวดล้อม -
ifเพิ่มตรรกะแบบมีเงื่อนไขเพื่อเรียกใช้ขั้นตอนเฉพาะเมื่อเป็นไปตามเกณฑ์เท่านั้น -
timeout-minutesหรือcontinue-on-errorตั้งค่าการดําเนินการเวิร์กโฟลว์และการจัดการข้อผิดพลาด
-
วินิจฉัยการเรียกใช้เวิร์กโฟลว์ที่ล้มเหลว
ในที่เก็บของคุณ ให้ไปที่แท็บการดําเนินการ
ค้นหาการวิ่งที่ล้มเหลว (โดยทั่วไปจะแสดงด้วย X สีแดง)
เลือกเวิร์กโฟลว์ที่ล้มเหลวเพื่อเปิดสรุปการเรียกใช้
ในบันทึกเวิร์กโฟลว์ ตรวจทานข้อผิดพลาด
ในสรุปการเรียกใช้ ให้ขยายแต่ละงานและขั้นตอนจนกว่าคุณจะพบงานที่ระบุความล้มเหลว
เลือกงานหรือขั้นตอนเพื่อดูบันทึก
ค้นหา:
- ข้อความแสดงข้อผิดพลาด
- การติดตามกองซ้อน
- รหัสออก
ตัวอย่างเช่น การทดสอบที่ล้มเหลวอาจแสดง
npm ERR! Test failedหรือexit code 1ตรวจสอบไฟล์การกําหนดค่าเวิร์กโฟลว์
ใช้
.ymlไฟล์เพื่อกําหนด:- แต่ละขั้นตอนพยายามทําอะไร
- ถ้ามีตัวแปรสภาพแวดล้อม (
env) หรือเงื่อนไข (if) ที่มีผลต่อการดําเนินการ - ถ้าความล้มเหลวเกิดจากการขึ้นต่อกัน ที่หายไป ข้อผิดพลาดทางไวยากรณ์ หรือขั้นตอนที่กําหนดค่าไม่ถูกต้อง
ถ้าขั้นตอนล้มเหลว ตรวจสอบสาเหตุต่อไปนี้:
- มีการติดตั้งการขึ้นต่อกันสําเร็จแล้วในขั้นตอนก่อนหน้าหรือไม่
- มีไฟล์ทดสอบอยู่และส่งผ่านภายในเครื่องหรือไม่
สถานการณ์ความล้มเหลวทั่วไป
ตารางต่อไปนี้อธิบายสถานการณ์ความล้มเหลวของเวิร์กโฟลว์ทั่วไป:
| Symptom | สาเหตุที่น่าจะเป็นไปได้ |
|---|---|
ขั้นตอนล้มเหลวและแสดง command not foundl |
การขึ้นต่อกันที่ขาดหายไปหรือการตั้งค่าไม่ถูกต้อง |
npm install ล้ม เหลว |
ไฟล์เสียหาย package-lock.json หรือปัญหาเครือข่าย |
| ขั้นตอนการทดสอบล้มเหลว | ปัญหาการทดสอบหน่วย ไฟล์การกําหนดค่าที่ขาดหายไป หรือไวยากรณ์การทดสอบไม่ถูกต้อง |
Permission denied ปรากฏ ขึ้น |
สิทธิ์ของไฟล์ไม่ถูกต้องหรือข้อมูลลับหายไป |
ระบุวิธีการเข้าถึงบันทึกเวิร์กโฟลว์ใน GitHub
ในที่เก็บของคุณ ให้ไปที่แท็บการดําเนินการ
ในรายการของเวิร์กโฟลว์ ให้เลือกเวิร์กโฟลว์ที่เกี่ยวข้อง
ตัวอย่างเช่น ถ้าแฟ้มของคุณ
.ymlมีรหัสต่อไปนี้ ลิงก์ชื่อ CI Workflow จะปรากฏในรายการ:name: CI Workflowเลือกการเรียกใช้ที่เฉพาะเจาะจง
ในรายการการทํางานที่แสดงสถานะ ให้เลือกการประทับเวลาหรือยอมรับข้อความของการเรียกใช้เฉพาะที่คุณต้องการตรวจสอบ
ขยายแต่ละงานและขั้นตอน
หน้าสรุปการเรียกใช้แสดงงานตามที่กําหนดไว้ในไฟล์เวิร์กโฟลว์ เช่น การสร้างหรือการทดสอบ:
- เลือกงานที่จะขยาย
- ภายในงาน ขยายแต่ละขั้นตอน เช่น "ติดตั้งการขึ้นต่อกัน" หรือ "เรียกใช้การทดสอบ"
ดูรายการบันทึกเอาต์พุต
หากต้องการดูผลลัพธ์บันทึกแบบเต็ม รวมถึงบันทึกคอนโซล ข้อความข้อผิดพลาด และข้อมูลดีบัก ให้เลือกขั้นตอนเวิร์กโฟลว์ คุณสามารถคัดลอก ค้นหา และดาวน์โหลดบันทึก
ตารางต่อไปนี้สรุปขั้นตอนที่คุณใช้เพื่อเข้าถึงบันทึกเวิร์กโฟลว์:
| Action | Purpose |
|---|---|
| แท็บการดําเนินการ | ดูการเรียกใช้เวิร์กโฟลว์ทั้งหมด |
| เลือกชื่อเวิร์กโฟลว์ | ตัวกรองทํางานตามเวิร์กโฟลว์ |
| เลือกการเรียกใช้ | ดูผลลัพธ์ของงานและขั้นตอนที่เฉพาะเจาะจง |
| ขยายขั้นตอน | ดูล็อกโดยละเอียด |
| ดาวน์โหลดบันทึก | ดาวน์โหลดบันทึกสําหรับการแก้ไขปัญหาแบบออฟไลน์หรือทีม |
รายการบันทึกการดําเนินการสําหรับรุ่น
เมื่อเวิร์กโฟลว์ทํางาน เวิร์กโฟลว์จะสร้างบันทึกที่มีรายละเอียดของสิ่งที่เกิดขึ้น และข้อผิดพลาดหรือความล้มเหลวในการทดสอบ
ถ้าข้อผิดพลาดเกิดขึ้นหรือถ้าการทดสอบล้มเหลว X สีแดงแทนที่จะเป็นเครื่องหมายถูกสีเขียวจะปรากฏขึ้นในบันทึก คุณสามารถตรวจสอบรายละเอียดของข้อผิดพลาดหรือความล้มเหลวในการตรวจสอบสิ่งที่เกิดขึ้นได้
ทํางานกับวัตถุ
เมื่อเวิร์กโฟลว์สร้างสิ่งอื่นที่ไม่ใช่รายการบันทึก ผลิตภัณฑ์จะเรียกว่าสิ่งประดิษฐ์ ตัวอย่างเช่น รุ่น Node.js จะสร้างคอนเทนเนอร์ Docker ที่สามารถปรับใช้ได้ คอนเทนเนอร์เป็นสิ่งประดิษฐ์ที่คุณสามารถอัปโหลดไปยังพื้นที่จัดเก็บได้โดยใช้การดําเนินการ actions/upload-artifact คุณสามารถดาวน์โหลดสิ่งประดิษฐ์จากที่เก็บข้อมูลได้ในภายหลังโดยใช้ actions/download-artifact
การจัดเก็บสิ่งประดิษฐ์จะเก็บรักษาไว้ระหว่างงาน แต่ละงานใช้อินสแตนซ์ใหม่ของ VM ดังนั้นคุณไม่สามารถนําอาร์ติแฟกท์กลับมาใช้ใหม่โดยการบันทึกบน VM ถ้าคุณต้องการวัตถุของคุณในงานอื่น คุณสามารถอัปโหลดวัตถุไปยังที่เก็บข้อมูลในงานเดียวและดาวน์โหลดสําหรับงานอื่นได้
ที่เก็บสิ่งประดิษฐ์
อาร์ติแฟกต์จะถูกเก็บไว้ในพื้นที่เก็บข้อมูลบน GitHub พื้นที่เก็บข้อมูลสาธารณะฟรีและพื้นที่เก็บข้อมูลบางส่วนฟรีสําหรับพื้นที่เก็บข้อมูลส่วนตัวขึ้นอยู่กับบัญชี GitHub จัดเก็บวัตถุของคุณเป็นเวลา 90 วัน
ในส่วนย่อยของเวิร์กโฟลว์ต่อไปนี้ ให้สังเกตว่าในการดําเนินการ actions/upload-artifact@main มีแอตทริบิวต์ path ค่าของแอตทริบิวต์นี้คือเส้นทางเพื่อจัดเก็บอาร์ติแฟกต์ ในตัวอย่างนี้ คุณระบุ public/ เพื่ออัปโหลดทุกอย่างไปยังไดเรกทอรี หากคุณต้องการอัปโหลดไฟล์เดียว ให้ใช้ไฟล์ public/mytext.txt
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@main
with:
name: webpack artifacts
path: public/
เมื่อต้องการดาวน์โหลดวัตถุสําหรับการทดสอบ รุ่นต้องเสร็จสมบูรณ์ และอัปโหลดวัตถุ ในโค้ดต่อไปนี้ คุณระบุว่างานทดสอบขึ้นอยู่กับงานการสร้าง
test:
needs: build
runs-on: ubuntu-latest
ในส่วนย่อยของเวิร์กโฟลว์ต่อไปนี้ คุณดาวน์โหลดอาร์ติแฟกต์ ตอนนี้งานทดสอบสามารถใช้สิ่งประดิษฐ์สําหรับการทดสอบได้
steps:
- uses: actions/checkout@v3
- uses: actions/download-artifact@main
with:
name: webpack artifacts
path: public
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้วัตถุในเวิร์กโฟลว์ ให้ดู การจัดเก็บข้อมูลเวิร์กโฟลว์เป็นวัตถุ
การตรวจทานใน GitHub โดยอัตโนมัติโดยใช้เวิร์กโฟลว์
นอกเหนือจากการเริ่มต้นเวิร์กโฟลว์ผ่านเหตุการณ์ GitHub เช่น push และ pull-requestคุณสามารถเรียกใช้เวิร์กโฟลว์ตามกําหนดการหรือหลังจากเหตุการณ์บางอย่างภายนอก GitHub ได้
คุณอาจต้องการให้เวิร์กโฟลว์ทํางานเฉพาะหลังจากที่ผู้ใช้ดําเนินการตามที่กําหนดเสร็จสิ้นเท่านั้น เช่น หลังจากผู้ตรวจสอบอนุมัติคําขอดึงข้อมูล สําหรับสถานการณ์สมมตินี้ คุณสามารถทริกเกอร์บนpull-request-review
การดําเนินการอื่นที่คุณสามารถทําได้คือการเพิ่มป้ายชื่อลงในคําขอดึงข้อมูล ในกรณีนี้ ให้ใช้การดําเนินการ pullreminders/label-when-approved-action
เช่น:
steps:
- name: Label when approved
uses: pullreminders/label-when-approved-action@main
env:
APPROVALS: "1"
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ADD_LABEL: "approved"
ใน env บล็อก คุณตั้งค่าตัวแปรสภาพแวดล้อมสําหรับการดําเนินการ ตัวอย่างเช่น คุณสามารถตั้งค่าจํานวนผู้อนุมัติที่จําเป็นในการเรียกใช้เวิร์กโฟลว์ ในตัวอย่างนี้ นี่คือหนึ่ง จําเป็นต้องมีตัวแปรการรับรองความถูกต้อง secrets.GITHUB_TOKEN เนื่องจากการดําเนินการต้องทําการเปลี่ยนแปลงที่เก็บข้อมูลของคุณโดยการเพิ่มป้ายชื่อ สุดท้าย คุณใส่ชื่อของป้ายชื่อที่จะเพิ่ม
การเพิ่มป้ายชื่ออาจเป็นเหตุการณ์ที่เริ่มต้นเวิร์กโฟลว์อื่น เช่น การผสาน เราครอบคลุมเหตุการณ์นี้ในโมดูลถัดไป ซึ่งอธิบายโดยใช้การจัดส่งแบบต่อเนื่องในการดําเนินการ GitHub