GitHub Actions'ın Yarattığı Acı

• GitHub Actions'ın sorunları

  • Son dönemde CI betiklerini GitHub Actions ile yeniden yazmaya çok zaman harcadım. Daha önce Earthly kullanıyordum, ancak artık sürdürülmediği için yeniden GitHub Actions'a döndüm.
  • CI karmaşıktır; merge queue, birden fazla runner, Rust derlemeleri, Docker imajları ve entegrasyon testleri gibi unsurları içerir. Her PR birleştirmesinde ciddi miktarda CI süresi harcanır.
  • İyi yazılım pratiği gereği tüm testlerin geçmesi, küçük hataların otomatik olarak düzeltilmesi ve test edilen artifact'lerin yayınlanan sürümle aynı olması gerekir. GitHub Actions bunu mümkün kılıyor, ancak yapılandırması karmaşık ve tutarsız.

• Durum kontrolleri ve merge queue

  • GitHub'ın merge queue özelliği, PR'ı ana dala rebase ettikten sonra CI çalıştırır. Ancak CI'nin hem kuyruğa alınmadan önce hem de alındıktan sonra çalışması gerekir ve bunu yapılandırmak zordur.
  • Çözüm, iki aşamada da iş adını aynı ayarlamaktır. Böylece her iki aşamanın da geçmesi gerekir.

• Güvenlik sorunları

  • Yakın zamanda popüler bir GitHub Action tehlikeye atıldı. Buna karşılık bağımlılıkların hash ile sabitlenmesi önerildi, ancak çoğu kullanıcı bunu yapmıyor.
  • GitHub'ın güvenlik modeli karmaşık ve anlaşılması zor. GITHUB_TOKEN için varsayılan izinler ayarlanabiliyor, ancak izinleri kaldırmanın nasıl yapılacağı net değil.
  • Workflow izinleri action'ın kendisine bağlı değildir ve kod içinden izin yükseltmek tuhaf bir yaklaşımdır.

• Docker ve GitHub Actions kombinasyonu

  • GitHub Actions içinde işleri bir container içinde çalıştırabilirsiniz, ancak dosya izinleri sorunları ve $HOME dizininin konumunun değişmesi gibi problemler ortaya çıkar.
  • container alanında çok sayıda kısıtlama vardır; entrypoint'i override etmek ya da yalnızca bazı adımları container içinde çalıştırmak mümkün değildir.

• YAML ile workflow geliştirmek

  • Mantığı YAML ile yazmak, iş akışları büyüdükçe karmaşık hale gelebilir ve hata yapmaya açıktır. Bazı kontroller için RustRover IDE kullandım, ancak daha iyi statik denetimlere ihtiyaç var.
  • Yerelde test etmek zordur; bu yüzden aynı repository üzerinde CI çalışana kadar tekrar tekrar commit ve push yapmak gerekir.
  • Workflow'ları küçük tutup artifact'leri yükleyerek başka workflow'larda yeniden kullanılmalarını sağlıyorum. Ancak artifact indirirken token gerekiyor.

• Sonuç

  • Yeni CI betikleriyle birleştirme süresi ciddi ölçüde kısaldı, ancak yapılandırma süreci karmaşık ve hata ayıklamak zor. Yeniliğe ihtiyaç var.

[GN⁺]

Hacker News görüşleri

• GitLab’ın daha iyi olduğuna dair görüşler var, ancak GitLab’ın da farklı açılardan sorunları bulunuyor

  • Çeşitli CI araçlarını kullandıktan sonra, mümkün olduğunca fazla CI mantığını kendi kodunuzda yazmanın önemli olduğu görülüyor
  • Geliştirici makinesinde pipeline’ı yerelde çalıştırabilmek için yatırım yapılmalı
  • Mümkün olduğunca YAML kullanımından kaçınılmalı
  • VC yatırımı almış yeni araçlara bağımlı kalınmamalı
  • Mümkün olduğunca self-hosted runner kullanılmalı ve on-premise çalıştırılmalı

• GitHub Actions ve DevOps’un yaygın biçimde eleştirilmesi ilginç

  • Kurulum ve test zahmetli olabiliyor, ancak bir kez çalışınca neredeyse hiç dokunulmuyor
  • Node sürümü güncellemeleri dışında 4 yıldır workflow neredeyse hiç değiştirilmedi
  • Kişisel olarak memnunum

• GitLab kullanırken GitHub’a geçildi ama hayal kırıklığı yarattı

  • GitHub Actions’ın GitLab’a kıyasla çok yetersiz olduğu düşünülüyor
  • Bir şirket işletiliyor olsaydı GitLab tercih edilirdi

• 30-60 saniyelik geri bildirim döngüsü en kötüsü

  • GHA ortamını yerelde yeniden oluşturmaya çalıştım ama mümkün olmadı
  • Küçük bir hata yüzünden çok zaman harcanıyor

• CI’ın kodu otomatik olarak düzeltmesi istenmiyor

  • Basit kontroller pre-commit hook ile çalıştırılmalı

• GitHub Actions’ın gelişiminin durmuş gibi görünmesi hayal kırıklığı yaratıyor

  • Earthly ve Dagger geliştirmelerinin durması üzücü
  • Depot.dev değerlendirildiğinde, çok zeki bir ekibin bu sorunu iyi çözdüğü görülüyor

• GitHub Actions, container’ların kurulum script’i gibi kötüye kullanılmasına yol açıyor

  • Workflow içinde çok zaman kurulum araçlarını çalıştırmakla geçiyor

• Uygun aracı seçmek önemli

  • GitHub Actions basit işler için uygun, ancak karmaşık işler için uygun değil

• GitHub Action’ın güvenlik sorunları nedeniyle bağımlılıkları hash kullanarak sabitlemek gerekiyor

  • Hash kullanmak çok daha güvenli

• GitHub Actions’ın pek çok sorunu var

  • 10GB cache sınırı, runner türüne göre eşzamanlılık sınırları, yüksek maliyet gibi sorunlar var
  • Depot.dev, GitHub Actions’ı daha hızlı hale getirmeye ve sorunlarını çözmeye çalışıyor
  • Docker image build sürecini hızlandırıyor, runner’ları optimize ederek işleri çok daha hızlı yapıyor
  • GitHub Actions popüler olsa da iyileştirme için hâlâ çok alan var