แคช แชร์ และดีบักเวิร์กโฟลว์

เสร็จสมบูรณ์เมื่อ

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

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

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

การขึ้นต่อกันของแคชด้วยการดําเนินการแคช

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

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

พารามิเตอร์	คำอธิบาย	จำเป็น
Key	อ้างอิงถึงตัวระบุคีย์ที่สร้างขึ้นเมื่อบันทึกและค้นหาแคช	ใช่
Path	อ้างถึงเส้นทางของไฟล์บนตัวเรียกใช้เพื่อแคชหรือค้นหา	ใช่
Restore-keys	ประกอบด้วยคีย์ทางเลือกที่มีอยู่เพื่อแคชถ้าไม่พบคีย์แคชที่ต้องการ	ไม่ใช่

steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

ในตัวอย่างก่อนหน้า path ถูกตั้งค่าเป็น ~/.npm และ key รวมถึงระบบปฏิบัติการของผู้เรียกใช้และแฮช SHA-256 ของไฟล์ package-lock.json การใส่คํานําหน้าคีย์ด้วย ID (npm-cache ในตัวอย่างนี้) จะมีประโยชน์เมื่อคุณกําลังใช้การแสดงแทน restore-keys และมีแคชหลายรายการ

ส่งผ่านข้อมูลวัตถุระหว่างงาน

คล้ายกับแนวคิดของการแคชการขึ้นต่อกันภายในเวิร์กโฟลว์ของคุณ คุณสามารถส่งผ่านข้อมูลระหว่างงานภายในเวิร์กโฟลว์เดียวกัน คุณสามารถส่งผ่านข้อมูลโดยใช้ การดําเนินการ upload-artifact และdownload-artifact งานที่ขึ้นอยู่กับอาร์ติแฟกต์ของงานก่อนหน้านี้ต้องรอให้งานก่อนหน้านี้เสร็จสมบูรณ์ก่อนที่จะสามารถเรียกใช้ได้ วิธีการนี้มีประโยชน์ถ้าคุณมีชุดงานที่ต้องเรียกใช้ตามลําดับตามอาร์ติแฟกต์ที่อัปโหลดจากงานก่อนหน้านี้ ตัวอย่างเช่น job_2 ต้องการ job_1 โดยใช้ไวยากรณ์ needs: job_1

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

ตัวอย่างนี้มีสองงาน job_1 เขียนข้อความบางอย่างใน file.txt ไฟล์ จากนั้นใช้การดําเนินการ actions/upload-artifact@v2 เพื่ออัปโหลดอาร์ติแฟกตินี้ และจัดเก็บข้อมูลสําหรับการใช้งานในอนาคตภายในเวิร์กโฟลว์ job_2 จําเป็นต้องใช้ job_1 เพื่อดําเนินการให้เสร็จสมบูรณ์โดยใช้ไวยากรณ์ needs: job_1 จากนั้นใช้การดําเนินการ actions/download-artifact@v2 เพื่อดาวน์โหลดอาร์ติแฟกต์นั้น แล้วพิมพ์เนื้อหาของ file.txt

เปิดใช้งานการบันทึกขั้นตอนดีบักในเวิร์กโฟลว์

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

• เมื่อต้องการเปิดใช้งานการบันทึกการวินิจฉัย ให้ACTIONS_RUNNER_DEBUGตั้งค่าข้อมูลลับในที่เก็บที่ประกอบด้วยเวิร์กโฟลว์เป็นtrue
• เมื่อต้องการเปิดใช้งานการบันทึกการวินิจฉัยขั้นตอน ตั้งค่าข้อมูลลับ ACTIONS_STEP_DEBUG ในที่เก็บที่ประกอบด้วยเวิร์กโฟลว์เพื่อ true

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

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

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

เมื่อต้องการดูบันทึกของเวิร์กโฟลว์ที่เรียกใช้ใน GitHub:

1. ในที่เก็บของคุณ ไปที่แท็บ การดําเนินการ
2. ในบานหน้าต่างด้านซ้าย ให้เลือกเวิร์กโฟลว์
3. ในรายการของการเรียกใช้เวิร์กโฟลว์ ให้เลือกการเรียกใช้
4. ภายใต้ งาน ให้เลือกงาน
5. อ่านรายการบันทึกเอาต์พุต

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

เข้าถึงบันทึกเวิร์กโฟลว์จาก REST API

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

ตัวอย่างเช่น GET การร้องขอเพื่อดูบันทึกการเรียกใช้เวิร์กโฟลว์ที่ระบุจะเป็นไปตามเส้นทางนี้:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

ระบุเวลาที่จะใช้โทเค็นการติดตั้งจากแอป GitHub

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

ในตัวอย่างต่อไปนี้ คุณแทนที่ INSTALLATION_ACCESS_TOKEN ด้วยโทเค็นการเข้าถึงการติดตั้ง:

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

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

คุณแทนที่ TOKEN ในตัวอย่างด้วยโทเค็นการเข้าถึงการติดตั้ง:

git clone https://x-access-token:TOKEN@github.com/owner/repo.git