GitHub Actions'tan Gerçekten Nefret Ediyorum

 (xlii.space)
10 puan yazan GN⁺ 2026-01-15 | 3 yorum | WhatsApp'ta paylaş
  • Geliştiricinin, GitHub Actions'ın yavaş geri bildirim döngüsü ve karmaşık hata ayıklama süreciyle yaşadığı hayal kırıklığı deneyimi paylaşılıyor
  • tmplr projesinde build.rs üzerinden CUE ile belgeler üretildi, ancak CI derlemesi başarısız olunca sorun başladı
  • 4 platformdan yalnızca Linux ARM derlemesi başarısız oldu; nedeni, cross build sırasında x86_64 ikili dosyalarının arm64 runner üzerinde gizlenmesine yol açan GitHub Actions çalışma biçimi
  • Tek bir değişikliği test etmek için 2-3 dakika harcanan verimsiz geri bildirim döngüsü tekrarlandı
  • Çözüm olarak build.rs silinip GNU Makefile'a geçildi; CI mantığı doğrudan kontrol edilerek sorun çözüldü

Sorunun ortaya çıkış arka planı

  • tmplr, insanların okuyup yazabildiği şablon dosyalarını kullanan bir dosya/proje scaffold aracı
  • build.rs içinde CUE kullanılarak README.md, CHANGELOG.md, sürüm/yardım dosyaları üretiliyor ve böylece tutarlılık sağlanıyordu
  • İşin kendisi yaklaşık 1,5 saatte tamamlandı ve ilgili yazı da yazıldı
  • Yerelde her şey düzgün çalışıyordu, ancak GitHub Actions'ın CI ortamında CUE ikili dosyası kurulu olmadığı için derleme başarısız oldu

Derleme hatasının nedeni

  • 4 platformdan (Linux ARM, macOS ARM, Linux x86_64, macOS x86_64) yalnızca Linux ARM'de “command not found” hatası oluştu
  • Neden: matrix cross build çok sıkı şekilde yalıtılmış durumda, bu yüzden CUE yalnızca x86_64 Linux host ve macOS ARM host üzerine kuruluydu
    • macOS, x86_64 ikili dosyalarını çalıştırmakta sorun yaşamıyor
    • Linux x86_64 de x86_64 ikili dosyalarını çalıştırmakta sorun yaşamıyor
    • Ancak GitHub Actions, arm64 runner üzerinde x86_64 ikili dosyalarını gizleyerek çalıştırılamaz hale getiriyor

Verimsiz geri bildirim döngüsü

  • Sorunu çözmek için tekrar tekrar izlenen süreç:
    1. Olası düzeltme yöntemlerini araştır
    2. ci.yml dosyasını değiştir
    3. Commit edip push et (jj squash --ignore-immutable && jj git push)
    4. "Actions" sekmesini aç
    5. En son çalıştırmayı aç
    6. Linux ARM çalıştırmasını aç
    7. Birkaç saniye bekle
    8. Hayal kırıklığı yaşa
    9. Tekrar et
  • Tek bir değişiklik için 2-3 dakika harcandı
  • İdeal olarak GitHub ya tam özellikli bir yerel runner sağlamalı ya da push sonrası ilerlemeyi hızlıca görmeyi mümkün kılan bir özellik sunmalı
    • "scratch commit" benzeri bir özellik: Git geçmişini ve Action çalıştırma kayıtlarını kirletmeden farklı çalıştırmaları test etmenin bir yolu
  • Ancak şu anda böyle bir özellik yok

Çözüm yolu

  • 30 dakika boyunca döngü tekrarlandıktan sonra duruldu
  • İnternette önerilen yaklaşım uygulandı: "GitHub Actions'ın mantığı yönetmesine izin vermeyin; betikleri doğrudan siz kontrol edin ve Actions yalnızca o betikleri çağırsın"
  • build.rs silindi (biraz üzücü olsa da bu fedakârlık gerekliydi)
  • Tüm üretim işleri GNU Makefile'a taşındı
  • Üretilen dosyalar depoya commit edildi ve CI değişiklikleri geri alındı
  • Sorun tamamen çözüldü

Sonuç

  • GitHub Actions, bazı iyi şeylere sahip olamamanın nedeni oluyor
  • Runner hata ayıklama ya da derleme sürecini optimize etme sırasında çok zaman kaybına yol açıyor
  • Ancak başka yollarla elde etmesi zor olan macOS derlemeleri gibi avantajlar da var
  • Elbette GitHub Actions'tan daha kolay yapılandırılan başka bir sistem de pek bilinmiyor

We are all doomed to GitHub Actions. …but at least I dodged the bullet early.

İlgili okumalar

3 yorum

 
iolothebard 2026-01-15

GitHub Actions sadece ortam kurulumu (OS, build toolchain, …) ve script (shell, Python, bat, ps1…) çalıştırma işi yapmalı. GitHub çökse bile, sadece ortam hazırsa her yerde build alınabilmeli. Son zamanlarda GitHub Actions workflow’larına bakınca, buna kadar da gidip özel bir şeyler kullanmak gerçekten gerekli mi diye düşündürüyor. Çok eskiden(?) Ansible da böyle yapıp battı.
 
GN⁺ 2026-01-15
Hacker News yorumları

  • GitHub Actions’ın temel sorunu, geri bildirim döngüsünün fazla yavaş olması
    Basit bir hatayı görmek için push atıp beklemek gerçekten sinir bozucu
    CI işlerini yerelde çalıştırılabilen script’lere ayırmanın ve Actions özelliklerini yalnızca kademeli iyileştirme olarak kullanmanın daha iyi olduğunu düşünüyorum
    workflow_dispatch ve gh workflow run birleşimi de fena değil, ama ikincisinin çalıştırılan workflow’nun URL’sini doğrudan vermemesi kullanışsız

    • nektos/act ile Actions’ı yerelde çalıştırabilirsiniz
      Hızlı geri bildirim almakta oldukça başarılı oldu
    • Ben Actions’ın Docker image’larını build edip test etmesini standartlaştırdım
      Bir sorun çıkarsa, GitHub Actions ortamına neredeyse birebir aynı durumda debug edebiliyorum
    • CI adımlarının yerelde çalıştırılamaması bana mantıksız geliyor
      Bu, tüm CI sistemleri için temel bir gereklilik olmalı
    • Yerelde çalışabilen bir CI aracı yazmayı kendim de düşündüm
      Sonuçta önemli olan kuyruklama, çıktı analizi ve build geçmişi telemetrisi gibi özellikler
    • gh workflow run kullanırken URL almak için GitHub API ile workflow çalıştırma listesini yeniden çekmem gerekti
      Aynı anda birden fazla çalışma varsa karışabiliyor, ama şimdilik idare ediyor

  • CI tasarımı için birkaç ipucu derledim

    1. bash yerine pwsh gibi CI dostu bir script dili kullanın
    2. Workflow’ya mantık koymayın, basit tutun
    3. Bağımsız script’ler yapın ki yerelde test edilebilsin
    4. Debug’ı kolaylaştırmak için durum çıktıları ve sürüm bilgisi bırakın
    5. Debug özellikleri iyi olan üçüncü taraf runner’ları değerlendirin
    • (1)’e katılmıyorum. Build ya da test sürecinin karmaşıklaşması bir kötü koku işaretidir
      Basit bir shell yeterli olmalı
    • (1)’e katılmıyorum ama (2)’nin doğru olduğunu düşünüyorum
      CI target’larını Makefile içinde tanımlayıp, make ci-test gibi basitçe çağırmak iyi olur
    • Eskiden Jenkins plugin cehennemi yaşadım
      O zamandan beri tüm CI’ı make build gibi basit wrapper’larla yönetiyorum
    • Tüm build’leri tek bir script’le sarmak, CI sisteminin ayrıntılı adım içgörüsünü kaybetmesine yol açıyor
      BeginStep("Step Name") gibi işaretleyicilerle ayırabilmek güzel olurdu
    • Sonuçta böyle bir yapıda, script’leri doğrudan çalıştıran yeni bir CI aracı gerekmiyor mu diye düşünüyorum

  • Sorun GitHub Actions’ın kendisinden çok, üstüne dağınık şekilde bindirilmiş otomasyon
    Mantığın Python gibi bir dille script’e dökülmesi ve yerelde de çalıştırılabilmesi gerekiyor

    • Birçok kişinin asıl şikayeti, hata veren VM’e SSH ile doğrudan bağlanıp debug edememek
      Her seferinde workflow’yu değiştirip push atıp beklemek gerekiyor
    • “Böyle bir script’e dökme işi ücretli yapılabilecek birkaç haftalık iş çıkarır” diye şaka yapanlar da var
    • Deployment, release, caching gibi yalnızca CI’ye özgü özellikleri yerelde tamamen yeniden üretmek zor
    • Bu yaklaşım biraz systemd’nin init.d script’lerini çağırdığı dönemi andırıyor, ama kötü değil
    • Bazılarına göre “bu %100 GitHub Actions’ın suçu”

  • Ben tüm CI’ı container içinde hallediyorum
    CI platformu sadece o container’ı çalıştırıyor, bu yüzden yerelde de aynısını koşturabiliyorum
    Platformlar bu yaklaşımı sevmez, çünkü vendor lock-in bozulur

    • SourceHut CI’ı seviyorum
      Hata olduğunda SSH ile doğrudan bağlanıp debug edebiliyorsunuz ve branch’e push atmadan manifest’i değiştirip yeniden çalıştırabiliyorsunuz
      Ama self-hosting gerekiyor
    • GitLab CI’da da benzer şekilde özel Docker image’ları oluşturup kullandım
      Standartlaşma kolaylaşıyor ama image bakım maliyeti gibi bir ödünleşim doğuyor
    • Dezavantajı, macOS build’lerini container içine almak zor olması
    • GitHub’ın webhook’ları çok ayrıntılı
      Aslında ortada bir lock-in yok, ama insanlar CI/CD cargo cult’una kapılmış durumda
    • “Bunu bana newsletter olarak gönderin” diyenler de oldu

  • Ben GitHub Actions’ı seviyorum
    Eskiden kullandığım Travis’ten daha iyi ve OSS projeleri için ücretsiz kaynak olarak çok faydalı
    Nix’e geçtikten sonra ortamın yeniden üretilebilirliği arttı, bu da Actions ile uyumu çok iyileştirdi

    • Ben de Nix yaklaşımına katılıyorum
      flake ile oluşturulan container’ı Actions içinde aynen çalıştırabiliyorsunuz
      örnek proje

  • Bence GitHub Actions yalnızca bash veya Python script’lerini çağıran bir yapı olmalı
    bash’ın sınırları var, Python daha esnek ve yerelde çalıştırması da kolay
    bu yazıdaki gibi uv’yi otomatik kurup bağımlılıkları yöneten bir yaklaşım ideal
    bash’tan daha karmaşık ama Actions ortamında performans sorunu büyük değil

    • Aslında YAML, çalışma zamanı ortamını tanımlamak için var; yürütme mantığını dış script’lerde tutmak doğru yaklaşım

  • Actions’ın en büyük sorunu, workflow’ları birleştirin şeklindeki tanıtım biçimi
    Debug etmek neredeyse imkânsız ve cache ayarı zahmetli olduğu için build’ler yavaşlıyor
    Bu yüzden kalıcı VM üzerinde doğrudan çalıştırma yaklaşımı cazip geliyor

  • Ben Depot’nun kurucusuyum
    GitHub Actions runner’larını daha hızlı ve daha ucuza sunan bir hizmet işletiyorum
    İnsanların hissettiği memnuniyetsizlik gerçekten çoğunluğun görüşü
    Actions sistemi yapısal olarak verimsiz ve her hafta yeni bir darboğaz keşfediyoruz
    Daha iyi bir yol olduğuna inanıyorum ve bunu deniyoruz
    Ayrıntılar için depot.dev

  • Geçen hafta sonu gg watch action adlı bir araç yaptım
    Mevcut branch’in en son ya da hâlen çalışan action’ını bulan bir araç
    GitHub linki

    • “Bu, gh CLI’ın bir özelliği olmalıydı” diye iyi tepki aldı
      Ama gg tui komutunda repository’nin görünmemesi gibi bir bug vardı

  • act gibi araçlar işe yarar mı diye merak ettim
    nektos/act
    Mimari farklar yüzünden yerel ve çevrimiçi çalıştırma birebir aynı olmayabilir, ama yine de faydalı görünüyor

    • Daha önce baktığımda tam bir alternatif değildi
      Yaklaşık %80 uyumluluk vardı
    • Tamamen aynı değil ama hızlı geri bildirim döngüsü oluşturmak için çok faydalı
    • Aslında en çok gereken şey, bir hata sonrasında SSH ile bağlanıp debug edebilme özelliği
      SourceHut bunu destekliyor ve gerçekten çok kullanışlı
 
anyflow 2026-01-18

YAML içine mantık koymak zorunda bırakan bir yapı olduğu için kaçınılmaz bir sorun gibi görünüyor.

Yukarıdaki yazı buna kabaca aşağıdaki gibi bir yanıt vermiş gibi, ama script kısmını Dagger ile değiştirirsek asıl doğru cevap bu değil mi diye de düşündürüyor.

"GitHub Actions'ın mantığı yönetmesine izin vermeyin; script'i doğrudan siz kontrol edin ve Actions sadece o script'i çağırsın"