วิธีเผยแพร่ข้อมูลเหตุการณ์ GitHub ด้วย GitHub Actions และ Pages

ทีมที่ทำงานบน GitHub อาศัยข้อมูลเหตุการณ์ในการทำงานร่วมกัน ข้อมูลที่บันทึกเป็นปัญหา คำขอดึง และความคิดเห็นมีความสำคัญต่อการทำความเข้าใจโครงการ

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

และถ้าคุณเป็นเหมือนฉัน คุณสามารถเปลี่ยนความคิดเห็นเกี่ยวกับปัญหา GitHub ให้เป็นหน้าสมุดเยี่ยมยุค 90 ที่ยอดเยี่ยมได้

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

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

การเข้าถึงข้อมูลเหตุการณ์ GitHub

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

เส้นทางที่ขยายดูเหมือน /home/runner/work/_temp/_github_workflow/event.json และข้อมูลสอดคล้องกับเหตุการณ์เว็บฮุค คุณสามารถดูเอกสารประกอบสำหรับข้อมูลเหตุการณ์ webhook ได้ใน GitHub REST API Event Types และ Payloads ในการทำให้ข้อมูล JSON พร้อมใช้งานในสภาพแวดล้อมเวิร์กโฟลว์ คุณสามารถใช้เครื่องมือเช่น jq เพื่อแยกวิเคราะห์ข้อมูลเหตุการณ์และใส่ไว้ในตัวแปรสภาพแวดล้อม

ด้านล่างนี้ ฉันคว้ารหัสความคิดเห็นจากกิจกรรมแสดงความคิดเห็นเกี่ยวกับปัญหา:

ID="$(jq '.comment.id' $GITHUB_EVENT_PATH)"

ข้อมูลเหตุการณ์ส่วนใหญ่ยังมีอยู่ใน github.event ตัวแปรบริบทโดยไม่ต้องแยกวิเคราะห์ JSON ช่องต่างๆ เข้าถึงได้โดยใช้เครื่องหมายจุด ดังในตัวอย่างด้านล่าง ซึ่งฉันคว้ารหัสความคิดเห็นเดียวกัน:

ID=${{ github.event.comment.id }}

สำหรับสมุดเยี่ยมของฉัน ฉันต้องการแสดงรายการที่มีหมายเลขอ้างอิงของผู้ใช้ และวันที่และเวลา ฉันสามารถบันทึกข้อมูลเหตุการณ์เช่นนี้ได้:

AUTHOR=${{ github.event.comment.user.login }}
DATE=${{ github.event.comment.created_at }}

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

การรักษาข้อมูลเหตุการณ์:การใช้สิ่งประดิษฐ์

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

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

การดำเนินการสองอย่างช่วยในการใช้สิ่งประดิษฐ์:upload-artifact และ download-artifact . คุณสามารถใช้การดำเนินการเหล่านี้เพื่อทำให้ไฟล์พร้อมใช้งานสำหรับงานอื่นในเวิร์กโฟลว์เดียวกัน สำหรับตัวอย่างทั้งหมด โปรดดูการส่งข้อมูลระหว่างงานในเวิร์กโฟลว์

upload-artifact การกระทำของ action.yml มีคำอธิบายของคำหลัก ไฟล์ที่อัพโหลดจะถูกบันทึกไว้ใน .zip รูปแบบ. งานอื่นในการรันเวิร์กโฟลว์เดียวกันสามารถใช้ download-artifact เพื่อนำข้อมูลไปใช้ในขั้นต่อไป

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

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

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

การรักษาข้อมูลเหตุการณ์:การพุชไฟล์เวิร์กโฟลว์ไปยังที่เก็บ

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

การสร้างไฟล์ในเวิร์กโฟลว์

ในการทำงานกับไฟล์ที่เก็บในเวิร์กโฟลว์ ให้ใช้ checkout การดำเนินการเพื่อรับสำเนาเพื่อใช้งานก่อน:

- uses: actions/checkout@master
  with:
    fetch-depth: 1

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

- name: Turn comment into file
  run: |
    ID=${{ github.event.comment.id }}
    AUTHOR=${{ github.event.comment.user.login }}
    DATE=${{ github.event.comment.created_at }}
    COMMENT=$(echo "${{ github.event.comment.body }}")
    NO_TAGS=${COMMENT//[<>]/\`}
    FOLDER=comments

    printf '%b\n' "<div class=\"comment\"><p>${AUTHOR} says:</p><p>${NO_TAGS//$'\n'/\<\/p\>\<p\>}</p><p>${DATE}</p></div>\r\n" > ${FOLDER}/${ID}.html

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

<div class="comment">
  <p>victoriadrake says:</p>
  <p>This is a comment!</p>
  <p>2019-11-04T00:28:36Z</p>
</div>

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

หากคุณกำลังใช้ตัวสร้างไซต์แบบสแตติกเช่น Hugo คุณสามารถสร้างไฟล์รูปแบบ Markdown ติดมันใน content/ ของคุณ โฟลเดอร์และการสร้างไซต์ปกติจะดูแลส่วนที่เหลือ

ในกรณีของสมุดเยี่ยมแบบง่ายของฉัน ฉันมีขั้นตอนเพิ่มเติมในการรวมไฟล์ความคิดเห็นแต่ละรายการไว้ในหน้า ทุกครั้งที่รัน มันจะเขียนทับ index.html . ที่มีอยู่ ด้วย header.html ส่วน (> ) จากนั้นค้นหาและต่อท้าย (>> ) เนื้อหาของไฟล์ความคิดเห็นทั้งหมดโดยเรียงจากมากไปน้อย และท้ายสุดต่อท้าย footer.html ส่วนที่จะจบหน้า

- name: Assemble page
  run: |
    cat header.html > index.html
    find comments/ -name "*.html" | sort -r | xargs -I % cat % >> index.html
    cat footer.html >> index.html

กำลังดำเนินการเปลี่ยนแปลงที่เก็บข้อมูล

ตั้งแต่ checkout การดำเนินการไม่เหมือนกับการโคลนที่เก็บ ในขณะที่เขียน ยังมีปัญหาบางอย่างที่ต้องแก้ไข จำเป็นต้องมีขั้นตอนเพิ่มเติมสองสามขั้นตอนเพื่อ pull , checkout และ push . สำเร็จ เปลี่ยนกลับเป็น master สาขา แต่สิ่งนี้ทำได้ค่อนข้างน้อยในเชลล์

ด้านล่างนี้คือขั้นตอนที่เพิ่ม คอมมิต และพุชการเปลี่ยนแปลงที่ทำโดยเวิร์กโฟลว์กลับไปที่ master ของที่เก็บ สาขา

- name: Push changes to repo
  run: |
    REMOTE=https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}
    git config user.email "${{ github.actor }}@users.noreply.github.com"
    git config user.name "${{ github.actor }}"

    git pull ${REMOTE}
    git checkout master
    git add .
    git status
    git commit -am "Add new comment"
    git push ${REMOTE} master

อันที่จริงรีโมตที่เก็บของเรานั้นถูกระบุโดยใช้ github.repository ตัวแปรบริบท เพื่อให้เวิร์กโฟลว์ของเราได้รับอนุญาตให้ผลักดันสู่ระดับมาสเตอร์ เราใช้ secrets.GITHUB_TOKEN ตัวแปร

เนื่องจากสภาพแวดล้อมเวิร์กโฟลว์มีความเป็นประกายและเกิดใหม่ เราจึงต้องกำหนดค่า Git ในตัวอย่างข้างต้น ฉันได้ใช้ github.actor ตัวแปรบริบทเพื่อป้อนชื่อผู้ใช้ของบัญชีที่เริ่มต้นเวิร์กโฟลว์ อีเมลได้รับการกำหนดค่าในทำนองเดียวกันโดยใช้ noreply . ที่เป็นค่าเริ่มต้น ที่อยู่อีเมล GitHub

การแสดงข้อมูลเหตุการณ์

การแก้ไข 6 พ.ย. 2019:การดำเนินการของ GitHub ต้องใช้โทเค็นการเข้าถึงส่วนบุคคลเพื่อทริกเกอร์การสร้างไซต์ของเพจ

หากคุณกำลังใช้ GitHub Pages กับ secrets.GITHUB_TOKEN ที่เป็นค่าเริ่มต้น ตัวแปรและไม่มีตัวสร้างไซต์ การพุชการเปลี่ยนแปลงไปยังที่เก็บในเวิร์กโฟลว์จะอัพเดตไฟล์ที่เก็บเท่านั้น การสร้าง GitHub Pages จะล้มเหลวโดยมีข้อผิดพลาด "ไซต์ของคุณมีปัญหาในการสร้าง:การสร้างเพจล้มเหลว"

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

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

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

- name: Run Makefile
  env:
    TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: make all

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

ไม่มีขอบฟ้าข้อมูลเหตุการณ์อีกต่อไป

GitHub Actions เป็นวิธีที่เรียบร้อยในการจับภาพและใช้ข้อมูลเหตุการณ์ ดังนั้นจึงไม่สามารถใช้งานได้เฉพาะใน GitHub เท่านั้น ความเป็นไปได้นั้นจำกัดอยู่ที่จินตนาการของคุณเท่านั้น! ต่อไปนี้คือแนวคิดบางประการสำหรับสิ่งต่างๆ ที่ทำให้เราสร้างสรรค์ได้:

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

ฉันพูดถึงฉันทำหน้าสมุดเยี่ยมยุค 90 หรือไม่? นักภูมิศาสตร์ชั้นในของฉันตื่นเต้นเล็กน้อย