Bất kỳ chương trình nào cũng có thể được dùng làm shell trong GitHub Actions

• Trong GitHub Actions, có thể chỉ định shell dùng để thực thi khối run: bằng từ khóa shell
• Trong workflow thì đây là tùy chọn, nhưng trong định nghĩa action riêng lẻ thì là mục bắt buộc
• Giá trị mặc định được tự động chọn theo hệ điều hành: Linux/macOS là bash, Windows là pwsh
• Nếu đặt rõ shell: bash, các cờ mặc định sau cũng sẽ được thêm vào: --noprofile --norc -eo pipefail

Có thể chỉ định bất kỳ tệp thực thi nào làm shell

• Thông thường rất dễ nghĩ rằng các giá trị có thể dùng cho shell bị giới hạn
• Thực tế, mọi tệp thực thi có trong $PATH đều có thể được dùng làm shell
• Nếu lệnh thực thi không nhận đầu vào từ tệp, cần truyền đối số đặc biệt {0}
• {0} sẽ được GitHub tự động thay thế bằng đường dẫn tới tệp tạm

Một số ví dụ thử nghiệm

• Cũng có thể dùng trình biên dịch C (tcc) như một shell để chạy trực tiếp
• Cũng có thể thao tác $PATH để tạo và dùng một shell bash giả
• GitHub không quan tâm giá trị ghi trong mục shell thực chất là tệp thực thi nào

Hàm ý về bảo mật

• Trong GitHub Actions, ranh giới giữa ghi tệp và thực thi khá mờ nhạt (vẫn có khả năng thực thi qua GITHUB_ENV, $GITHUB_PATH v.v.)
• Ngay cả những giá trị quen thuộc như shell: bash cũng được tra cứu qua $PATH, chứ không dùng đường dẫn thực thi cố định như /bin/bash
• Trái với dự đoán, các giá trị như python cũng được thực thi dựa trên đường dẫn thực tế, chứ không chỉ đơn thuần tham chiếu tới tool cache

[tujuc]

Chỉ nhìn vào repo github/runner-image thôi cũng thấy có khá nhiều gói đã được cài sẵn để có thể dùng ngay...

Tạo image là dung lượng đội lên 1GB ngay...

[GN⁺]

Ý kiến trên Hacker News

• Trước đây tôi từng dùng cờ -x của bash để buộc in ra mọi lệnh được chạy trong workflow Actions. Điều này rất hữu ích cho việc debug
• Một mẹo không chính thức nhưng khá hay của GitHub Actions mà tôi phát hiện trong lúc làm việc là dùng wildcard để khớp tên sự kiện repository_dispatch
  • Đây là cách duy nhất để ép dùng workflow tái sử dụng được định nghĩa thông qua một pipeline phát hành tập trung
  • Khi dispatch sự kiện, có thể dễ dàng nhận diện sản phẩm và phiên bản
• Theo trải nghiệm của tôi, càng làm ít việc trong GitHub Actions càng tốt
  • Tôi thích mã hóa logic trong hệ thống build (ví dụ: Make) rồi gọi từ GitHub Actions, hoặc
  • viết một chương trình CLI nhỏ rồi gọi từ GitHub Actions
  • Debug cục bộ dễ hơn rất nhiều so với debug trong CI
• Đã từng có một thế hệ thấy sợ khi được yêu cầu chuyển bảng tính thành mã
  • Thế hệ này sẽ sợ khi được yêu cầu áp đặt kỷ luật cho việc triển khai được xây bằng GitHub Actions
• Mã của GitHub Actions Runner khá dễ đọc
  • Có một chỗ cụ thể định nghĩa các đối số mặc định cho những shell/binary phổ biến
  • ScriptHandler.cs chứa toàn bộ mã để chuẩn bị môi trường tiến trình, đối số, v.v.
  • Nhìn chung tôi ngạc nhiên theo hướng tích cực trước sự đơn giản của phần mã này
• Có thể đánh lừa shell mặc định bash để chạy bất kỳ chương trình nào
  • Miễn là người đọc action khác hiểu chuyện gì đang diễn ra thì điều này rất hữu ích
  • Tôi từng có những shell script bắt đầu chỉ vài dòng rồi phình thành quái vật hơn cả trăm dòng
  • Tôi muốn có các tính năng như mảng và kiểu dữ liệu trong Python stdlib
• Điều này cho tôi hy vọng rằng có thể dễ dàng chạy mã Go thực thi trực tiếp các tác vụ CI từ file YAML workflow của GitHub
  • goeval vẫn chưa hỗ trợ trực tiếp đầu vào từ file
  • Cần đến mẹo shell
  • Cần thêm một chút boilerplate
  • Tôi là tác giả của goeval
• Tôi tự hỏi ưu điểm của file yaml CI trên GitHub là gì
• Trong CI/CD giờ có thể viết C và gọi đó là làm việc hệ thống mức thấp
  • Chắc cũng có thể viết cả assembly nữa