จัดการและดีบักเวิร์กโฟลว์ในการดําเนินการ GitHub

โปรดทราบว่าเป้าหมายของคุณคือการทําให้กระบวนการสร้างและเผยแพร่โค้ดเป็นแบบอัตโนมัติเพื่อให้คุณลักษณะได้รับการอัปเดตทุกครั้งที่นักพัฒนาเพิ่มการเปลี่ยนแปลงไปยังฐานโค้ด

หากต้องการใช้กระบวนการนี้ คุณจะเรียนรู้วิธีการ:

• ระบุเหตุการณ์ที่ทริกเกอร์เวิร์กโฟลว์
• ใช้บันทึกเวิร์กโฟลว์การดําเนินการ GitHub
• บันทึกและเข้าถึงวัตถุที่สร้างขึ้น
• เพิ่มป้ายกํากับลงในคําขอดึงข้อมูลโดยอัตโนมัติหลังจากการตรวจสอบ

ระบุเหตุการณ์ที่ทริกเกอร์เวิร์กโฟลว์

การทําความเข้าใจสิ่งที่ทําให้เวิร์กโฟลว์การดําเนินการ GitHub มีความสําคัญสําหรับการดีบัก การตรวจสอบ และการปรับปรุงไปป์ไลน์ CI/CD ชนิดของทริกเกอร์รวมถึงการส่งไปยังสาขา คําขอดึงข้อมูลที่สร้างหรืออัปเดต งานตามกําหนดเวลา หรือการจัดส่งด้วยตนเอง คุณสามารถระบุเหตุการณ์ทริกเกอร์ได้โดยตรวจสอบการเรียกใช้เวิร์กโฟลว์ การเปลี่ยนแปลงที่เก็บ และปัญหา GitHub หรือคําขอดึงข้อมูลที่เกี่ยวข้อง

ทริกเกอร์เวิร์กโฟลว์คืออะไร

ทริกเกอร์เวิร์กโฟลว์คือ เหตุการณ์ที่ทําให้เวิร์กโฟลว์ทํางาน GitHub สนับสนุนทริกเกอร์ชนิดต่าง ๆ รวมถึง:

• push หรือ pull_request (ขึ้นอยู่กับการเปลี่ยนแปลงรหัส)
• workflow_dispatch (ทริกเกอร์ด้วยตนเอง)
• schedule (งาน cron)
• repository_dispatch (ระบบภายนอก)
• ปัญหา การสนทนา และเหตุการณ์คําขอดึงข้อมูล (ตัวอย่างเช่น issues.opened) pull_request.closed

ระบุเหตุการณ์ทริกเกอร์

คุณสามารถระบุเหตุการณ์ทริกเกอร์เวิร์กโฟลว์ได้หลายวิธี:

• ใช้ UI การดําเนินการ GitHub:

  1. ในที่เก็บของคุณ ให้เลือกแท็บ การดําเนินการ
  2. เลือกการเรียกใช้เวิร์กโฟลว์

  ชนิดเหตุการณ์ เช่น 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 เพื่อติดตามสิ่งที่เป็นสาเหตุให้ทริกเกอร์

อนุมานทริกเกอร์จากผลกระทบของที่เก็บข้อมูล

คุณอาจไม่มีการเข้าถึงโดยตรงไปยังการเรียกใช้เวิร์กโฟลว์ แต่คุณยังคงต้องการอนุมานสิ่งที่ทําให้เวิร์กโฟลว์ทํางานตามกิจกรรมของที่เก็บ:

เมื่อตรวจทานการประทับเวลา กิจกรรมการดึงคําขอ และประวัติการยอมรับ คุณมักจะสามารถระบุสิ่งที่การดําเนินการที่ทําให้เวิร์กโฟลว์ทํางานได้

เพื่อสรุปวิธีการระบุสิ่งที่ทริกเกอร์เวิร์กโฟลว์:

• ตรวจสอบสรุปการเรียกใช้เวิร์กโฟลว์บนแท็บ การดําเนินการ
• พิมพ์หรือเข้าสู่ระบบ github.event_name ภายในเวิร์กโฟลว์สําหรับการมองเห็น
• เปรียบเทียบการประทับเวลาและกิจกรรมที่เก็บข้อมูล (ยืนยัน คําขอดึงข้อมูล ปัญหา) เพื่ออนุมานทริกเกอร์
• ใช้บริบทแบบเต็ม event สําหรับการตรวจสอบอย่างลึกซึ้งขึ้น

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

ทําความเข้าใจเกี่ยวกับผลของเวิร์กโฟลว์โดยการอ่านไฟล์การกําหนดค่า

เมื่อต้องการทําความเข้าใจผลกระทบของเวิร์กโฟลว์จากการอ่านไฟล์การกําหนดค่า ให้วิเคราะห์โครงสร้างและเนื้อหาของไฟล์ที่.ymlจัดเก็บไว้ใน.github/workflows/

ไฟล์การกําหนดค่าเวิร์กโฟลว์จะระบุข้อมูลต่อไปนี้เกี่ยวกับเวิร์กโฟลว์:

• เมื่อเรียกใช้งาน (ในส่วน)on
• สิ่งที่ทํา (ใน jobs และ steps)
• ตําแหน่งที่เรียกใช้ ( runs-on ส่วน)
• ทําไมจึงทํางาน (วัตถุประสงค์ เช่น การทดสอบ การปรับใช้ หรือการวางซับใน)
• วิธีการทํางานของเงื่อนไขเฉพาะ (สภาพแวดล้อม ตัวกรอง ตรรกะ)

ตีความเอฟเฟ็กต์เวิร์กโฟลว์

1. ระบุทริกเกอร์

   หากต้องการระบุการดําเนินการที่เริ่มต้นเวิร์กโฟลว์ ให้ดู on ส่วนของเวิร์กโฟลว์

   เช่น:

   on:
     push:
       branches: [main]
     pull_request:
       types: [opened, synchronize]
     workflow_dispatch:
   

   เวิร์กโฟลว์ตัวอย่างนี้:

   • เรียกใช้โดยอัตโนมัติเมื่อรหัสถูกส่งไปยังสาขาหลัก (push)
   • เรียกใช้เมื่อสร้างหรืออัปเดตคําขอดึงข้อมูล (pull_request)
   • สามารถทริกเกอร์ด้วยตนเองโดยผู้ใช้ (workflow_dispatch)

2. ระบุงานเวิร์กโฟลว์และขั้นตอน

   เมื่อต้องกําหนดสิ่งที่เวิร์กโฟลว์ทํา ให้ดู 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)

3. ประเมินวัตถุประสงค์และผลลัพธ์ของเวิร์กโฟลว์

   โดยการอ่านไฟล์การกําหนดค่า คุณสามารถอธิบายผลลัพธ์ที่ตั้งใจไว้ของเวิร์กโฟลว์:

   "เวิร์กโฟลว์นี้เป็นไปป์ไลน์การรวมอย่างต่อเนื่อง (CI) ตรวจสอบให้แน่ใจว่าโค้ดใหม่ใด ๆ ที่ส่งไปยังที่เก็บหรือส่งผ่านคําขอดึงข้อมูลจะได้รับการทดสอบโดยอัตโนมัติ ถ้าการทดสอบล้มเหลว UI เวิร์กโฟลว์ GitHub จะแสดงผลลัพธ์นี้เพื่อช่วยรักษาคุณภาพโค้ด"

4. ระบุหรือตั้งค่าคุณลักษณะทางเลือกที่มีผลต่อการเรียกใช้เวิร์กโฟลว์:

   • env ตั้งค่าตัวแปรสภาพแวดล้อม
   • if เพิ่มตรรกะแบบมีเงื่อนไขเพื่อเรียกใช้ขั้นตอนเฉพาะเมื่อเป็นไปตามเกณฑ์เท่านั้น
   • timeout-minutes หรือ continue-on-error ตั้งค่าการดําเนินการเวิร์กโฟลว์และการจัดการข้อผิดพลาด

วินิจฉัยการเรียกใช้เวิร์กโฟลว์ที่ล้มเหลว

1. ในที่เก็บของคุณ ให้ไปที่แท็บการดําเนินการ

2. ค้นหาการวิ่งที่ล้มเหลว (โดยทั่วไปจะแสดงด้วย X สีแดง)

3. เลือกเวิร์กโฟลว์ที่ล้มเหลวเพื่อเปิดสรุปการเรียกใช้

4. ในบันทึกเวิร์กโฟลว์ ตรวจทานข้อผิดพลาด

   1. ในสรุปการเรียกใช้ ให้ขยายแต่ละงานและขั้นตอนจนกว่าคุณจะพบงานที่ระบุความล้มเหลว

   2. เลือกงานหรือขั้นตอนเพื่อดูบันทึก

   3. ค้นหา:

      • ข้อความแสดงข้อผิดพลาด
      • การติดตามกองซ้อน
      • รหัสออก

   ตัวอย่างเช่น การทดสอบที่ล้มเหลวอาจแสดง npm ERR! Test failed หรือexit code 1

5. ตรวจสอบไฟล์การกําหนดค่าเวิร์กโฟลว์

   ใช้ .yml ไฟล์เพื่อกําหนด:

   • แต่ละขั้นตอนพยายามทําอะไร
   • ถ้ามีตัวแปรสภาพแวดล้อม (env) หรือเงื่อนไข (if) ที่มีผลต่อการดําเนินการ
   • ถ้าความล้มเหลวเกิดจากการขึ้นต่อกัน ที่หายไป ข้อผิดพลาดทางไวยากรณ์ หรือขั้นตอนที่กําหนดค่าไม่ถูกต้อง

   ถ้าขั้นตอนล้มเหลว ตรวจสอบสาเหตุต่อไปนี้:

   • มีการติดตั้งการขึ้นต่อกันสําเร็จแล้วในขั้นตอนก่อนหน้าหรือไม่
   • มีไฟล์ทดสอบอยู่และส่งผ่านภายในเครื่องหรือไม่

สถานการณ์ความล้มเหลวทั่วไป

ตารางต่อไปนี้อธิบายสถานการณ์ความล้มเหลวของเวิร์กโฟลว์ทั่วไป:

ระบุวิธีการเข้าถึงบันทึกเวิร์กโฟลว์ใน GitHub

1. ในที่เก็บของคุณ ให้ไปที่แท็บการดําเนินการ

2. ในรายการของเวิร์กโฟลว์ ให้เลือกเวิร์กโฟลว์ที่เกี่ยวข้อง

   ตัวอย่างเช่น ถ้าแฟ้มของคุณ .yml มีรหัสต่อไปนี้ ลิงก์ชื่อ CI Workflow จะปรากฏในรายการ:

   name: CI Workflow
   

3. เลือกการเรียกใช้ที่เฉพาะเจาะจง

   ในรายการการทํางานที่แสดงสถานะ ให้เลือกการประทับเวลาหรือยอมรับข้อความของการเรียกใช้เฉพาะที่คุณต้องการตรวจสอบ

4. ขยายแต่ละงานและขั้นตอน

   หน้าสรุปการเรียกใช้แสดงงานตามที่กําหนดไว้ในไฟล์เวิร์กโฟลว์ เช่น การสร้างหรือการทดสอบ:

   1. เลือกงานที่จะขยาย
   2. ภายในงาน ขยายแต่ละขั้นตอน เช่น "ติดตั้งการขึ้นต่อกัน" หรือ "เรียกใช้การทดสอบ"

5. ดูรายการบันทึกเอาต์พุต

   หากต้องการดูผลลัพธ์บันทึกแบบเต็ม รวมถึงบันทึกคอนโซล ข้อความข้อผิดพลาด และข้อมูลดีบัก ให้เลือกขั้นตอนเวิร์กโฟลว์ คุณสามารถคัดลอก ค้นหา และดาวน์โหลดบันทึก

ตารางต่อไปนี้สรุปขั้นตอนที่คุณใช้เพื่อเข้าถึงบันทึกเวิร์กโฟลว์:

รายการบันทึกการดําเนินการสําหรับรุ่น

เมื่อเวิร์กโฟลว์ทํางาน เวิร์กโฟลว์จะสร้างบันทึกที่มีรายละเอียดของสิ่งที่เกิดขึ้น และข้อผิดพลาดหรือความล้มเหลวในการทดสอบ

ถ้าข้อผิดพลาดเกิดขึ้นหรือถ้าการทดสอบล้มเหลว 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