1 puan yazan GN⁺ 9 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Kişisel bir sunucudaki bare Git deposuna post-receive hook’u ekleyerek test, build ve dosya taşıma işlemlerini otomatikleştiren basit bir CI yapılandırmasıdır
  • Mevcut CI çözümlerindeki karmaşık YAML ayarları, yavaş çalışma ve zor self-hosting seçeneklerine kıyasla tam build izolasyonuna ya da gizli bilgi yönetimine ihtiyaç duyulmuyordu
  • İşleri doğrudan hook içinde çalıştırmak, hata durumunda push’un reddedilmesine veya tamamlanmasının gecikmesine yol açtığı için arka plan işleme için minimal iş kuyruğu nq kullanılır
  • Hook yalnızca nq çağırır; loglar ssh server nqtail -a ile kontrol edilerek hızlı ve basit şekilde işletilebilir
  • Gerektiğinde landdown·Podman ile build’ler izole edilebilir, sops ile gizli bilgiler yönetilebilir veya Git e-posta patch’leri, git-shell ve git http-backend ile geliştirme biçimi genişletilebilir

post-receive hook’u ve nq yapılandırması

  • Kişisel sunucuda ssh server git init --bare repo ile depo oluşturulur ve git clone server:repo ile klonlanır
  • Push yapıldığında CI’ı başlatmak için bare deponun hooks dizinine shell script biçiminde bir post-receive hook’u konur
  • İşleri doğrudan hook içinde çalıştırmak iki soruna yol açar
    • Script başarısız olursa push reddedilir
    • Script’in çalışması yavaşsa push’un tamamlanması da gecikir
  • Hook içinde minimal iş kuyruğu nq çağrılarak işler arka plan kuyruğuna eklenir
    • Loglar ssh server nqtail -a ile kontrol edilir
    • Kurulum süreci kısa bir öğreticide görülebilir

İzolasyon ve geliştirme biçimini genişletme

  • Build’leri sandbox içinde çalıştırmak için landdown kullanılabilir
  • Podman ile build’ler host ortamından izole edilebilir veya sops ile gizli bilgiler yönetilebilir
  • Bazaar tarzı geliştirme için Git patch’lerini e-posta yoluyla alan bir yapılandırma uygundur
  • Cathedral tarzı geliştirme git-shell veya git http-backend ile yapılandırılabilir

1 yorum

 
GN⁺ 9 시간 전
Lobste.rs yorumları
  • CI'da en az iki sorun var
    Kolay olan sorun, kod değiştiğinde make test çalıştırmak; zor olan ise make testi Linux, Windows ve Mac'in hepsinde çalıştırmak

    • Linux kolay, Windows zor, ama macOS ise tam bir çile
    • CI'daki zor kısmın, başarısızlık durumunda hata ayıklamayı da destekleyen bir iş yürütme motoru olduğunu düşünüyorum
      Mevcut motorların geliştirici deneyimi ve hata ayıklama özellikleri hep geri planda kaldığı için bundan rahatsızım; bu yüzden https://ci.pico.sh üzerinde bir CI sistemi geliştiriyorum. DSL'lerden de hoşlanmıyorum; katman katman uzayan YAML ise sanki yavaş yavaş yaşam enerjisini emiyor
    • Bu yaklaşım kolay sorunu çözüyor; QEMU ile BSD ailesi desteği eklenebilir, Docker ile de çeşitli dağıtımlara genişletilebilir ama bunun ötesi için daha kapsamlı bir araç gerekiyor gibi görünüyor
  • Bunu gitolite üzerine kurup Temporal ile aktararak derleme sürecini hiçbir kısıt olmadan kontrol ettiğim olmuştu
    Çalıştırma başarısız olursa push'u reddetmek de mümkün ama genelde hook'un geçmesine izin verip başarısızlığı ayrı ele alıyorum; yapılandırması da basitti ve eğlenceliydi

    • Özellikle gitolite'in erişim kontrol araçlarını seviyorum; var olmayan bir depoya push atarak yeni depo oluşturabilme şekli de harika
  • Kabuk betiği çalıştırma merkezli bir diğer minimal CI olarak laminar CI var; web arayüzü de sunuyor

  • Çok eski zamanlarda, yalnızca Windows kullanılan bir kurumsal ortamda, tüm ekibin kullandığı yerel bir CI sunucusu olarak bir Mac mini koyup iOS uygulaması derlemiştik; Git'i kullanmaya dair ilk denemelerimden biriydi

  • Bunu https://mccd.space/git/ adresinde buldum; stagit fork'u kullanıyor gibi görünüyor
    Birkaç ay öncesine kadar Forgejo ve Woodpecker çalıştırıyordum ama özelliklerin çoğuna ihtiyacım yoktu; bu yüzden hepsini kaldırıp buna benzer daha hafif bir kurulum arıyordum. Sıradaki işim CI olduğu için tam zamanında geldi; yakında yayımlayacağım küçük bir kütüphaneyi SourceHut'a mirror'layıp mirror'lamamayı da düşünüyorum

    • stagit'i fork'layıp iletişim e-postası ve gezinme çubuğu ekledim, CSS değişiklikleri için ID koydum ve gereksiz bilgileri çıkardım
      Depoyu git-daemon ile web üzerinde salt okunur olarak yayımlıyorum; tüm kurulumun nasıl yapıldığını da burada topladım
  • nqyu ilk kez bu yazı sayesinde duydum ama muhtemelen systemd-run kullanırım
    Neredeyse tüm çalıştırıcılarda Nix kullandığım için, nix flake check sonucunu OTLP metrikleri ve logları olarak dışa verirsem CI gereksinimlerini izleme sistemiyle çözebilirmişim gibi geliyor

  • Böyle basit, kendi kendine barındırılan geliştirme platformu kurulumlarını seviyorum
    CI için hafif ve basit bir konteyner sistemi olan bubblewrap kolayca kurulup kullanılabilir. Ama nq kullanılırsa CI başarısız olduğunda push'u reddetmek mümkün görünmüyor; bunun nasıl ele alındığını merak ediyorum

    • Betikleri kısıtlamak için Landlock kullanan bir yardımcı araç da var; bana göre kullanımı biraz daha basit
      Daha fazla yalıtım gerekirse Podman, Docker veya bubblewrap eklenebilir. Testleri çalıştıran pre-commit hook koymamakla aynı nedenle, CI başarısız olduğunda push'u reddetmiyorum; çünkü bazen bozuk işleri de commit'lemek ya da push'lamak gerekebiliyor ve push çok yavaşlayabiliyor. Reddetmek gerekiyorsa nq olmadan CI'ı eşzamanlı çalıştırıp çıkış kodu 0 değilse push'u engelleyebilirsiniz
      Ya da main dışındaki branch'leri nq ile çalıştırıp yalnızca main branch'ini eşzamanlı çalıştırabilirsiniz
  • landdown bağlantısı bozuk görünüyor