Program apa pun bisa digunakan sebagai shell di GitHub Actions

• Di GitHub Actions, shell yang digunakan untuk menjalankan blok run: dapat ditentukan dengan kata kunci shell
• Di workflow ini bersifat opsional, tetapi dalam definisi action individual ini wajib
• Nilai bawaan ditentukan otomatis sesuai sistem operasi: Linux/macOS menggunakan bash, Windows menggunakan pwsh
• Jika secara eksplisit menetapkan shell: bash, flag bawaan berikut juga akan disertakan: --noprofile --norc -eo pipefail

Program apa pun dapat ditetapkan sebagai shell

• Orang mudah mengira bahwa nilai yang bisa digunakan pada shell itu terbatas
• Kenyataannya, semua executable yang ada di $PATH dapat digunakan sebagai shell
• Jika perintah yang dijalankan tidak menerima input file, argumen khusus {0} harus diteruskan
• {0} akan otomatis diganti GitHub dengan path file sementara

Contoh eksperimental

• Bahkan compiler bahasa C (tcc) bisa dipakai seperti shell untuk menjalankan sesuatu secara langsung
• Dengan memanipulasi $PATH, shell bash palsu juga bisa dibuat dan digunakan
• GitHub tidak peduli apakah nilai yang dicantumkan pada entri shell itu sebenarnya executable apa

Implikasi keamanan

• Di GitHub Actions, batas antara menulis file dan mengeksekusi file menjadi kabur (bahkan melalui GITHUB_ENV, $GITHUB_PATH, dll. ada kemungkinan untuk dieksekusi)
• Bahkan nilai yang sudah dikenal seperti shell: bash pun dicari melalui $PATH, dan tidak menggunakan path executable tetap seperti /bin/bash
• Bertentangan dengan dugaan, nilai seperti python juga dieksekusi berdasarkan path nyata, bukan sekadar referensi tool cache

[tujuc]

Bahkan hanya dengan melihat repo github/runner-image, sudah terpasang cukup banyak paket yang bisa langsung digunakan....

Kalau membuat image, 1GB itu langsung terpakai....

[GN⁺]

Opini Hacker News

• Saya pernah memaksa semua perintah yang dijalankan di workflow Actions untuk dicetak dengan menggunakan flag -x pada bash. Ini sangat berguna untuk debugging
• Trik tidak resmi GitHub Actions yang keren yang saya temukan saat bekerja adalah mencocokkan nama event repository_dispatch dengan wildcard
  • Ini adalah satu-satunya cara untuk menegakkan workflow reusable yang didefinisikan melalui pipeline rilis terpusat
  • Saat mendispatch event, produk dan versinya bisa dengan mudah diidentifikasi
• Dari pengalaman saya, semakin sedikit yang dilakukan di GitHub Actions, semakin baik
  • Saya lebih suka mengenkode logika menggunakan build system (misalnya Make) lalu memanggilnya dari GitHub Actions, atau
  • menulis program CLI kecil lalu memanggilnya dari GitHub Actions
  • Debugging secara lokal jauh lebih mudah daripada debugging di CI
• Ada generasi yang dulu takut ketika diminta mengubah spreadsheet menjadi kode
  • Generasi ini akan takut ketika diminta memberi disiplin pada deployment yang dibangun dengan GitHub Actions
• Kode GitHub Actions Runner mudah dibaca
  • Ada lokasi tertentu yang mendefinisikan argumen default untuk shell/binary populer
  • ScriptHandler.cs berisi semua kode untuk menyiapkan environment proses, argumen, dan sebagainya
  • Secara keseluruhan, saya terkejut secara positif oleh kesederhanaan kode ini
• Kita bisa mengakali shell default bash untuk menjalankan program apa pun
  • Selama pembaca action lain memahami apa yang sedang terjadi, ini sangat berguna
  • Saya pernah mengalami skrip shell yang mulai dari beberapa baris lalu tumbuh menjadi monster lebih dari seratus baris
  • Saya menginginkan fitur seperti array dan type dari Python stdlib
• Ini memberi harapan bahwa kode Go yang menjalankan pekerjaan CI secara langsung dari file YAML workflow GitHub bisa dijalankan dengan mudah
  • goeval masih belum mendukung input file secara langsung
  • Trik shell diperlukan
  • Sedikit boilerplate diperlukan
  • Saya adalah penulis goeval
• Saya penasaran apa sebenarnya kelebihan dari yaml GitHub CI
• Di CI/CD, sekarang kita bisa menulis C dan menyebutnya sebagai pekerjaan sistem tingkat rendah
  • Mungkin kita juga bisa menulis assembly