GitHub Actions'ta herhangi bir program kabuk olarak kullanılabiliyor

• GitHub Actions'ta run: bloğunu çalıştırırken kullanılan kabuk shell anahtar sözcüğüyle belirtilebiliyor
• Workflow içinde isteğe bağlı olsa da, tek tek action tanımlarında zorunlu bir alan
• Varsayılan değer işletim sistemine göre otomatik atanıyor: Linux/macOS için bash, Windows için pwsh
• shell: bash açıkça ayarlanırsa, aşağıdaki varsayılan bayraklar da ekleniyor: --noprofile --norc -eo pipefail

Herhangi bir çalıştırılabilir dosya shell olarak belirtilebiliyor

• Genelde shell için kullanılabilecek değerlerin sınırlı olduğunu düşünmek kolay
• Gerçekte $PATH içindeki tüm çalıştırılabilir dosyalar kabuk olarak kullanılabiliyor
• Çalıştırma komutu dosya girdisi almıyorsa, özel bir argüman olan {0} geçirilmesi gerekiyor
• {0} GitHub tarafından otomatik olarak geçici dosya yoluyla değiştiriliyor

Deneysel örnekler

• C derleyicisi tcc'yi kabuk gibi kullanıp doğrudan çalıştırmak da mümkün
• $PATH değiştirilerek sahte bir bash kabuğu oluşturup kullanmak da mümkün
• GitHub, shell alanında belirtilen değerin gerçekte hangi çalıştırılabilir dosya olduğuyla ilgilenmiyor

Güvenlik açısından çıkarımlar

• GitHub Actions'ta dosya yazma ile çalıştırma arasındaki sınır belirsiz (GITHUB_ENV, $GITHUB_PATH vb. üzerinden de çalıştırma ihtimali var)
• shell: bash gibi iyi bilinen değerler bile $PATH üzerinden aranıyor; sabit bir çalıştırma yolu (/bin/bash) kullanılmıyor
• Beklenenin aksine, python gibi değerler de yalnızca bir toolcache referansı değil, gerçek yol tabanlı çalıştırma kullanıyor

[tujuc]

github/runner-image deposuna baksanız bile, doğrudan kullanılabilecek epey fazla paket kurulu oluyor....

İmajı oluşturunca 1GB zaten hemen doluyor....

[GN⁺]

Hacker News görüşleri

• Geçmişte, Actions iş akışında çalıştırılan tüm komutların yazdırılmasını zorlamak için bash'in -x bayrağını kullandığım oldu. Bu, hata ayıklama için çok faydalı
• Çalışırken keşfettiğim GitHub Actions'ın harika gayriresmî hilelerinden biri, repository_dispatch olay adını eşleştirmek için joker karakter kullanmak
  • Bu, merkezi bir sürüm hattı üzerinden tanımlanan yeniden kullanılabilir iş akışlarını zorunlu kılmanın tek yolu
  • Olayı dispatch ederken ürün ve sürümü kolayca ayırt edebiliyorsunuz
• Deneyimime göre GitHub Actions içinde ne kadar az iş yapılırsa o kadar iyi
  • Mantığı kodlamak için bir build sistemi (ör. Make) kullanıp bunu GitHub Actions'dan çağırmayı ya da
  • Küçük bir CLI programı yazıp bunu GitHub Actions'dan çağırmayı tercih ediyorum
  • Yerelde hata ayıklamak, CI içinde hata ayıklamaktan çok daha kolay
• E-tabloları koda dönüştürme isteği geldiğinde korkan bir nesil vardı
  • Bu nesil, GitHub Actions ile kurulmuş deployment'lara disiplin getirme isteği geldiğinde de korkacaktır
• GitHub Actions Runner kodu okunması kolay
  • Popüler shell'ler/binary'ler için varsayılan argümanların tanımlandığı belirli bir yer var
  • ScriptHandler.cs içinde süreç ortamını, argümanları vb. hazırlayan tüm kod bulunuyor
  • Genel olarak bu kodun sadeliği beni olumlu anlamda şaşırttı
• Varsayılan bash shell'ini kandırarak herhangi bir programı çalıştırabilirsiniz
  • Bunu kullanan diğer action'ların okurları ne olduğunu anladığı sürece oldukça faydalı
  • Bir shell script'in birkaç satırdan başlayıp yüz satırı aşan bir canavara dönüştüğü deneyimlerim oldu
  • Python stdlib'in diziler ve tipler dahil sunduğu özellikleri istedim
• GitHub workflow YAML dosyasında, CI işini doğrudan çalıştıran Go kodunu kolayca çalıştırabileceğime dair umut veriyor
  • goeval henüz doğrudan dosya girdisini desteklemiyor
  • Shell hilesi gerekiyor
  • Biraz boilerplate gerekiyor
  • goeval'in yazarı benim
• GitHub CI yaml'in avantajının ne olduğunu merak ediyorum
• CI/CD içinde C yazıp buna düşük seviyeli sistem işi diyebilmek mümkün oldu
  • Hatta assembly bile yazılabilir