Penderitaan akibat GitHub Actions

 (feldera.com)
2 poin oleh GN⁺ 2025-03-21 | 1 komentar | Bagikan ke WhatsApp

  • Masalah GitHub Actions

    • Baru-baru ini banyak waktu dihabiskan untuk menulis ulang skrip CI dengan GitHub Actions. Sebelumnya menggunakan Earthly, tetapi karena dihentikan, kembali lagi ke GitHub Actions.
    • CI itu kompleks, mencakup merge queue, beberapa runner, build Rust, image Docker, pengujian integrasi, dan lain-lain. Setiap kali PR digabung, banyak waktu CI yang terpakai.
    • Sebagai praktik software yang baik, semua pengujian harus lulus, kesalahan kecil seharusnya diperbaiki secara otomatis, dan artefak yang diuji harus sama dengan yang dirilis. GitHub Actions memungkinkan hal ini, tetapi konfigurasinya rumit dan tidak konsisten.

  • Pemeriksaan status dan merge queue

    • Merge queue GitHub menjalankan CI setelah melakukan rebase PR ke branch utama. Namun, CI harus dijalankan baik sebelum maupun sesudah masuk ke antrean, dan menyiapkan ini sulit.
    • Solusinya adalah menetapkan nama job yang sama pada kedua tahap. Dengan begitu, kedua tahap harus sama-sama lulus.

  • Masalah keamanan

    • Baru-baru ini sebuah GitHub Action yang populer disusupi. Sebagai tanggapan, ada anjuran untuk mengunci dependensi dengan hash, tetapi kebanyakan pengguna tidak melakukannya.
    • Model keamanan GitHub rumit dan sulit dipahami. Anda bisa menetapkan izin default untuk GITHUB_TOKEN, tetapi cara mencabut izin tidak jelas.
    • Izin workflow tidak bergantung pada action itu sendiri, dan menaikkan izin di dalam kode terasa janggal.

  • Kombinasi Docker dan GitHub Actions

    • Di GitHub Actions, pekerjaan bisa dijalankan di dalam container, tetapi ini menimbulkan masalah seperti izin file dan perubahan lokasi direktori $HOME.
    • Field container memiliki banyak batasan, sehingga tidak mungkin menimpa entrypoint atau menjalankan hanya sebagian langkah di dalam container.

  • Mengembangkan workflow dengan YAML

    • Menulis logika dalam YAML bisa menjadi rumit dan mudah menimbulkan kesalahan. IDE RustRover digunakan untuk melakukan sebagian pemeriksaan, tetapi dibutuhkan pemeriksaan statis yang lebih baik.
    • Sulit untuk menguji secara lokal, sehingga harus membuat repositori yang sama lalu berulang kali commit dan push sampai CI berfungsi.
    • Workflow dijaga tetap kecil dan artefak didorong agar bisa digunakan kembali di workflow lain. Namun, token diperlukan saat mengunduh artefak.

  • Kesimpulan

    • Dengan skrip CI yang baru, waktu merge berkurang drastis, tetapi proses konfigurasinya rumit dan debugging-nya sulit. Diperlukan inovasi.

Bacaan terkait

1 komentar

 
GN⁺ 2025-03-21
Opini Hacker News

  • Ada pendapat bahwa GitLab lebih baik, tetapi GitLab juga punya masalah dengan cara yang berbeda

    • Setelah mencoba berbagai alat CI, hal yang penting adalah menulis sebanyak mungkin logika CI di kode sendiri
    • Perlu berinvestasi agar pipeline bisa dijalankan secara lokal di mesin pengembang
    • Hindari penggunaan YAML sebisa mungkin
    • Jangan bergantung pada alat baru yang didanai modal ventura
    • Sebisa mungkin gunakan runner sendiri dan operasikan secara on-premises

  • Menarik bahwa GitHub Actions dan DevOps mendapat kritik yang luas

    • Konfigurasi dan pengujian bisa merepotkan, tetapi begitu berfungsi hampir tidak perlu disentuh
    • Selain pembaruan versi Node, workflow hampir tidak diubah selama 4 tahun
    • Secara pribadi merasa puas

  • Pernah menggunakan GitLab lalu beralih ke GitHub, tetapi merasa kecewa

    • GitHub Actions terasa sangat kurang dibandingkan GitLab
    • Jika menjalankan perusahaan, akan memilih GitLab

  • Feedback loop 30-60 detik adalah yang terburuk

    • Sudah mencoba mereplikasi lingkungan GHA secara lokal, tetapi tidak memungkinkan
    • Kesalahan kecil bisa menghabiskan banyak waktu

  • Tidak ingin CI memperbaiki kode secara otomatis

    • Pemeriksaan sepele seharusnya dijalankan dengan pre-commit hook

  • Kecewa karena perkembangan GitHub Actions tampaknya terhenti

    • Disayangkan bahwa pengembangan Earthly dan Dagger berhenti
    • Setelah mengevaluasi Depot.dev, tim yang sangat cerdas berhasil menyelesaikan masalah dengan baik

  • GitHub Actions mendorong penyalahgunaan container sebagai skrip instalasi

    • Dalam workflow, banyak waktu habis untuk menjalankan installer

  • Penting untuk memilih alat yang tepat

    • GitHub Actions cocok untuk tugas sederhana, tetapi tidak cocok untuk tugas yang kompleks

  • Karena masalah keamanan GitHub Action, dependensi harus dipin menggunakan hash

    • Dengan hash, jauh lebih aman

  • Ada banyak masalah pada GitHub Actions

    • Batas cache 10GB, batas konkurensi berdasarkan tipe runner, biaya tinggi, dan lain-lain
    • Depot.dev berupaya membuat GitHub Actions lebih cepat dan menyelesaikan masalah-masalah tersebut
    • Mempercepat build image Docker dan mengoptimalkan runner sehingga pekerjaan menjadi sangat cepat
    • GitHub Actions sangat populer, tetapi masih banyak ruang untuk perbaikan