CI Minimalis dengan Git Hook dan nq

 (mccd.space)
1 poin oleh GN⁺ 10 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Ini adalah konfigurasi CI sederhana yang menambahkan hook post-receive ke repositori bare Git di server pribadi untuk mengotomatiskan pengujian, build, dan pemindahan file
  • Dibanding CI yang ada, yang memiliki konfigurasi YAML rumit, eksekusi lambat, dan self-hosting yang sulit, kebutuhan seperti isolasi build penuh atau pengelolaan informasi rahasia tidak diperlukan
  • Jika pekerjaan dijalankan langsung dari hook, push bisa ditolak saat gagal atau penyelesaiannya tertunda, sehingga pemrosesan dilakukan di latar belakang dengan antrean pekerjaan minimalis nq
  • Hook hanya memanggil nq, dan log diperiksa dengan ssh server nqtail -a, sehingga operasinya cepat dan sederhana
  • Jika diperlukan, build dapat diisolasi dengan landdown·Podman, informasi rahasia dikelola dengan sops, atau alur pengembangan diperluas dengan patch Git via email, git-shell, dan git http-backend

Konfigurasi hook post-receive dan nq

  • Di server pribadi, buat repositori dengan ssh server git init --bare repo lalu clone dengan git clone server:repo
  • Letakkan hook post-receive berbentuk skrip shell di direktori hooks pada repositori bare, sehingga CI dimulai setiap kali ada push
  • Jika pekerjaan dijalankan langsung dari hook, ada dua masalah yang muncul
    • Jika skrip gagal, push akan ditolak
    • Jika eksekusi skrip lambat, penyelesaian push juga ikut tertunda
  • Di dalam hook, panggil antrean pekerjaan minimalis nq untuk menambahkan pekerjaan ke antrean latar belakang
    • Log diperiksa dengan ssh server nqtail -a
    • Proses konfigurasinya dapat dilihat di tutorial singkat

Isolasi dan perluasan cara pengembangan

  • Untuk menjalankan build di sandbox, landdown dapat digunakan
  • Dengan Podman, build dapat diisolasi dari lingkungan host, atau sops dapat digunakan untuk mengelola informasi rahasia
  • Untuk pengembangan bergaya bazaar, konfigurasi yang menerima patch Git melalui email cocok digunakan
  • Pengembangan bergaya cathedral dapat dikonfigurasi dengan git-shell atau git http-backend

Bacaan terkait

1 komentar

 
GN⁺ 10 jam lalu
Komentar di Lobste.rs

  • CI setidaknya punya dua masalah
    Masalah yang mudah adalah menjalankan make test saat kode berubah, sedangkan masalah yang sulit adalah menjalankan make test di Linux, Windows, dan Mac sekaligus

    • Linux mudah dan Windows sulit, tetapi macOS benar-benar menyakitkan
    • Bagian sulit dari CI menurut saya adalah mesin eksekusi job yang juga mendukung debugging saat terjadi kegagalan
      Saya tidak puas karena pengalaman developer dan fitur debugging pada engine yang ada selalu dinomorduakan, jadi saya sedang membuat sistem CI di https://ci.pico.sh. Saya juga tidak suka DSL, dan YAML berantai secara hierarkis terasa seperti perlahan-lahan menyedot daya hidup
    • Cara ini menyelesaikan masalah yang mudah, dan mungkin bisa diperluas untuk mendukung keluarga BSD dengan QEMU serta berbagai distro dengan Docker, tetapi untuk lebih dari itu tampaknya diperlukan alat yang lebih lengkap

  • Saya pernah membangun ini di atas gitolite dan meneruskannya ke Temporal agar proses build bisa dikendalikan tanpa batas
    Saat eksekusi gagal, push bisa saja ditolak, tetapi biasanya saya membiarkan hook lolos lalu menangani kegagalan secara terpisah; konfigurasinya juga sederhana dan menyenangkan

    • Saya terutama menyukai alat kontrol akses milik gitolite, dan cara membuat repositori baru dengan melakukan push ke repositori yang belum ada juga sangat bagus

  • Sebagai CI minimal lain yang berpusat pada eksekusi skrip shell, ada laminar CI, yang juga menyediakan UI web

  • Dulu sekali, di lingkungan perusahaan khusus Windows, kami menaruh Mac mini sebagai server CI lokal yang dipakai seluruh tim untuk membangun aplikasi iOS; itu salah satu cara awal kami memanfaatkan Git

  • Saya menemukannya di https://mccd.space/git/, dan tampaknya menggunakan fork stagit
    Sampai beberapa bulan lalu saya menjalankan Forgejo dan Woodpecker, tetapi sebagian besar fiturnya tidak saya perlukan, jadi saya menghapus semuanya dan sedang mencari konfigurasi yang lebih ringan seperti ini. Tugas berikutnya memang CI, jadi waktunya pas, dan saya sedang mempertimbangkan apakah akan me-mirror library kecil yang akan segera saya rilis ke SourceHut

    • Saya mem-fork stagit untuk menambahkan email kontak dan bilah navigasi, memasukkan ID untuk perubahan CSS, serta menghapus informasi yang tidak perlu
      Repositori dipublikasikan read-only di web dengan git-daemon, dan cara konfigurasi lengkapnya sudah saya rangkum di sini

  • Dari tulisan ini saya baru mengenal nq, tetapi mungkin saya akan memakai systemd-run
    Karena saya memakai Nix di hampir semua runner, jika hasil nix flake check diekspos sebagai metrik dan log OTLP, sepertinya kebutuhan CI bisa diselesaikan lewat sistem monitoring

  • Saya suka konfigurasi platform pengembangan self-hosted yang sederhana seperti ini
    Untuk CI, bubblewrap, sistem container yang ringan dan sederhana, bisa disiapkan dan digunakan dengan mudah. Namun jika memakai nq, tampaknya menolak push saat CI gagal tidak memungkinkan; saya penasaran bagaimana itu ditangani

    • Ada juga alat bantu yang memakai Landlock untuk membatasi skrip, dan menurut saya penggunaannya sedikit lebih sederhana
      Jika perlu isolasi lebih, Podman, Docker, atau bubblewrap bisa ditambahkan. Saya tidak menolak push saat CI gagal karena alasan yang sama dengan tidak memasang hook pre-commit yang menjalankan pengujian: kadang pekerjaan yang rusak tetap perlu di-commit atau di-push, dan push bisa menjadi sangat lambat. Jika perlu penolakan, jalankan CI secara sinkron tanpa nq dan blokir push saat exit code bukan 0
      Atau, branch selain main bisa dijalankan dengan nq, sementara branch main saja dijalankan secara sinkron

  • Tautan landdown tampaknya rusak