สามารถใช้โปรแกรมใดก็ได้เป็นเชลล์ใน GitHub Actions

• ใน GitHub Actions สามารถระบุเชลล์ที่ใช้รันบล็อก run: ได้ด้วยคีย์เวิร์ด shell
• ในเวิร์กโฟลว์นั้นเป็นตัวเลือก แต่ในการกำหนดแอ็กชันแต่ละตัวถือเป็นรายการที่จำเป็น
• ค่าเริ่มต้นจะถูกกำหนดอัตโนมัติตามระบบปฏิบัติการ: Linux/macOS ใช้ bash, Windows ใช้ pwsh
• หากตั้งค่า shell: bash แบบชัดเจน จะมีแฟลกเริ่มต้นต่อไปนี้รวมอยู่ด้วย: --noprofile --norc -eo pipefail

สามารถระบุไฟล์ปฏิบัติการใดก็ได้เป็น shell

• โดยทั่วไปมักเข้าใจได้ง่ายว่าค่าที่ใช้กับ shell มีข้อจำกัด
• แต่ในความเป็นจริง ไฟล์ปฏิบัติการทุกตัวที่อยู่ใน $PATH สามารถใช้เป็นเชลล์ได้
• หากคำสั่งที่รันไม่รับอินพุตจากไฟล์ จะต้องส่งอาร์กิวเมนต์พิเศษ {0} ให้
• GitHub จะแทนที่ {0} ด้วยพาธของไฟล์ชั่วคราวให้อัตโนมัติ

ตัวอย่างเชิงทดลอง

• สามารถใช้คอมไพเลอร์ภาษา C (tcc) ราวกับเป็นเชลล์เพื่อรันได้โดยตรง
• สามารถปรับแต่ง $PATH เพื่อสร้างเชลล์ bash ปลอมขึ้นมาแล้วใช้งานได้เช่นกัน
• GitHub ไม่ได้สนใจว่าค่าที่ระบุในรายการ shell จะเป็นไฟล์ปฏิบัติการอะไรจริง ๆ

นัยด้านความปลอดภัย

• ใน GitHub Actions เส้นแบ่งระหว่างการเขียนไฟล์กับการรันโค้ดค่อนข้างเลือนราง (ยังมีความเป็นไปได้ในการรันผ่าน GITHUB_ENV, $GITHUB_PATH เป็นต้น)
• แม้แต่ค่าที่คุ้นเคยอย่าง shell: bash ก็ยังถูกค้นหาผ่าน $PATH และไม่ได้ใช้พาธตายตัวอย่าง /bin/bash
• ต่างจากที่คาดไว้ ค่าอย่าง python ก็ไม่ได้อ้างถึงทูลแคชแบบง่าย ๆ แต่เป็นการรันตามพาธจริง

[tujuc]

ดูแค่รีโป github/runner-image ก็จะเห็นว่ามีแพ็กเกจที่ติดตั้งมาให้และใช้งานได้ทันทีอยู่ค่อนข้างเยอะ....

พอสร้างอิมเมจก็ปาไป 1GB แบบสบาย ๆ....

[GN⁺]

ความเห็นจาก Hacker News

• เคยบังคับให้พิมพ์ทุกคำสั่งที่รันในเวิร์กโฟลว์ Actions ออกมา โดยใช้แฟลก -x ของ bash ซึ่งมีประโยชน์มากสำหรับการดีบัก
• ทริกไม่เป็นทางการเจ๋ง ๆ ของ GitHub Actions ที่เจอระหว่างทำงานคือการใช้ wildcard เพื่อแมตช์ชื่ออีเวนต์ repository_dispatch
  • นี่เป็นวิธีเดียวที่สามารถบังคับใช้เวิร์กโฟลว์แบบใช้ซ้ำได้ที่ถูกกำหนดผ่านรีลีสไปป์ไลน์แบบรวมศูนย์
  • สามารถระบุผลิตภัณฑ์และเวอร์ชันได้ง่ายตอน dispatch อีเวนต์
• จากประสบการณ์ ยิ่งทำอะไรใน GitHub Actions ให้น้อยยิ่งดี
  • ชอบเข้ารหัสลอจิกไว้ใน build system (เช่น Make) แล้วค่อยเรียกจาก GitHub Actions มากกว่า
  • หรือเขียนโปรแกรม CLI เล็ก ๆ แล้วเรียกจาก GitHub Actions
  • การดีบักบนเครื่อง local ง่ายกว่าการดีบักใน CI มาก
• เคยมีคนรุ่นหนึ่งที่รู้สึกหวาดกลัวเมื่อถูกขอให้แปลงสเปรดชีตเป็นโค้ด
  • คนรุ่นนี้ก็น่าจะกลัวเมื่อถูกขอให้ใส่ระเบียบให้กับการ deploy ที่สร้างด้วย GitHub Actions
• โค้ดของ GitHub Actions Runner อ่านง่าย
  • มีจุดเฉพาะที่กำหนดอาร์กิวเมนต์เริ่มต้นสำหรับ shell/binary ยอดนิยม
  • ใน ScriptHandler.cs มีโค้ดทั้งหมดสำหรับเตรียม process environment, arguments และอื่น ๆ
  • โดยรวมแล้วรู้สึกประหลาดใจในทางบวกกับความเรียบง่ายของโค้ดนี้
• สามารถหลอก default shell bash เพื่อให้รันโปรแกรมอะไรก็ได้
  • ตราบใดที่คนที่มาดู action อื่น ๆ รู้ว่าเกิดอะไรขึ้น สิ่งนี้มีประโยชน์มาก
  • เคยเจอสคริปต์ shell ที่เริ่มจากไม่กี่บรรทัดแล้วโตเป็นสัตว์ประหลาดเกินร้อยบรรทัด
  • อยากได้ความสามารถอย่าง array และ type ต่าง ๆ ใน Python stdlib
• ทำให้มีความหวังว่าจะรันโค้ด Go ที่รันงาน CI ได้โดยตรงจากไฟล์ GitHub workflow YAML ได้ง่าย
  • goeval ยังไม่รองรับการรับไฟล์โดยตรง
  • เลยต้องใช้ shell trick
  • ต้องมี boilerplate เล็กน้อย
  • เป็นผู้เขียน goeval
• สงสัยว่าข้อดีของ Github CI yaml คืออะไร
• ใน CI/CD ตอนนี้สามารถเขียน C แล้วเรียกมันว่าเป็นงานระบบระดับล่างได้
  • น่าจะเขียน assembly ได้เหมือนกัน