Saya Sangat Membenci GitHub Actions

 (xlii.space)
10 poin oleh GN⁺ 2026-01-15 | 3 komentar | Bagikan ke WhatsApp
  • Pengembang membagikan pengalaman frustrasi terhadap loop umpan balik yang lambat dan proses debugging yang rumit di GitHub Actions
  • Dalam proyek tmplr, dokumentasi dibuat dengan CUE melalui build.rs, tetapi masalah dimulai ketika build CI gagal
  • Dari 4 platform, hanya Linux ARM yang gagal build; penyebabnya adalah cara kerja GitHub Actions yang menyembunyikan biner x86_64 di runner arm64 saat cross build
  • Loop umpan balik yang tidak efisien berulang, dengan waktu 2–3 menit untuk menguji satu perubahan
  • Sebagai solusi, build.rs dihapus dan dialihkan ke GNU Makefile, sehingga logika CI dapat dikendalikan langsung untuk menyelesaikan masalah

Latar belakang terjadinya masalah

  • tmplr adalah alat scaffolding file/proyek yang menggunakan file template yang bisa dibaca dan ditulis manusia
  • Di build.rs, CUE digunakan untuk menghasilkan README.md, CHANGELOG.md, serta file versi/bantuan guna menjaga konsistensi
  • Pekerjaan itu sendiri selesai hanya dalam sekitar 1,5 jam, dan tulisan terkait juga sudah selesai dibuat
  • Semuanya berjalan normal secara lokal, tetapi build gagal di lingkungan CI GitHub Actions karena biner CUE tidak terpasang

Penyebab kegagalan build

  • Dari 4 platform (Linux ARM, macOS ARM, Linux x86_64, macOS x86_64), hanya Linux ARM yang mengalami error “command not found”
  • Penyebabnya: matrix cross build sangat terisolasi, sehingga CUE hanya terpasang di host Linux x86_64 dan host macOS ARM
    • macOS tidak bermasalah saat menjalankan biner x86_64
    • Linux x86_64 juga tidak bermasalah saat menjalankan biner x86_64
    • Namun, GitHub Actions menyembunyikan biner x86_64 di runner arm64, sehingga tidak bisa dijalankan

Loop umpan balik yang tidak efisien

  • Proses yang berulang untuk menyelesaikan masalah:
    1. Mencari kemungkinan cara perbaikan
    2. Mengubah ci.yml
    3. Commit dan push (jj squash --ignore-immutable && jj git push)
    4. Membuka tab “Actions”
    5. Membuka eksekusi terbaru
    6. Membuka eksekusi Linux ARM
    7. Menunggu beberapa detik
    8. Frustrasi
    9. Ulangi
  • Dibutuhkan 2–3 menit untuk setiap satu perubahan
  • Idealnya, GitHub menyediakan runner lokal yang lengkap fiturnya, atau setidaknya fitur untuk memeriksa progres dengan cepat setelah push
    • Fitur seperti “scratch commit”: cara untuk menguji berbagai eksekusi tanpa mengotori riwayat Git dan catatan eksekusi Actions
  • Namun, saat ini fitur seperti itu belum ada

Solusi

  • Setelah mengulang loop selama 30 menit, proses itu dihentikan
  • Menerapkan pendekatan yang dikenal di internet: “Jangan biarkan GitHub Actions mengelola logika; kendalikan sendiri lewat skrip, dan biarkan Actions hanya memanggil skrip tersebut”
  • build.rs dihapus (meski sayang, tetapi perlu pengorbanan)
  • Semua pekerjaan generasi dipindahkan ke GNU Makefile
  • File yang dihasilkan di-commit ke repositori, lalu perubahan CI dikembalikan
  • Masalah selesai

Kesimpulan

  • GitHub Actions menjadi alasan mengapa beberapa hal bagus tidak bisa dimanfaatkan
  • Banyak waktu terbuang untuk debugging runner atau mengoptimalkan proses build
  • Namun, tetap ada keuntungan seperti build macOS yang sulit didapat dengan cara lain
  • Tentu saja, juga belum diketahui ada sistem lain yang lebih mudah disiapkan daripada GitHub Actions

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

Bacaan terkait

3 komentar

 
iolothebard 2026-01-15

GitHub Actions seharusnya hanya untuk menyiapkan environment (OS, toolchain build, …) dan menjalankan skrip (shell, Python, bat, ps1…). Meski GitHub down, selama environment-nya siap, build harus bisa dilakukan di mana saja. Kalau lihat workflow GitHub Actions belakangan ini, rasanya jadi berpikir apa perlu sampai repot-repot mencari dan memakai hal seperti itu. Dulu sekali (?) Ansible juga begitu lalu gagal.
 
GN⁺ 2026-01-15
Komentar Hacker News

  • Masalah inti GitHub Actions adalah loop umpan baliknya terlalu lambat
    Sangat menjengkelkan harus push lalu menunggu hanya untuk mengecek kegagalan sederhana
    Menurut saya, sebaiknya pekerjaan CI dipisahkan menjadi skrip yang bisa dijalankan secara lokal, dan fitur Actions hanya dipakai sebagai peningkatan bertahap
    Kombinasi workflow_dispatch dan gh workflow run juga lumayan, tetapi sangat merepotkan karena yang terakhir tidak langsung memberikan URL workflow yang dijalankan

    • Dengan nektos/act, kita bisa menjalankan Actions secara lokal
      Cukup berhasil untuk mendapatkan umpan balik cepat
    • Saya menstandarkan Actions agar membangun dan menguji image Docker
      Jika ada masalah, saya bisa melakukan debugging dalam kondisi yang hampir sama dengan lingkungan GitHub Actions
    • Menurut saya tidak masuk akal jika tahap CI tidak bisa dijalankan secara lokal
      Itu seharusnya menjadi persyaratan dasar semua sistem CI
    • Saya pernah mempertimbangkan membuat sendiri alat CI yang bisa dijalankan lokal
      Pada akhirnya yang penting adalah fitur seperti antrean, analisis output, dan telemetri riwayat build
    • Saat memakai gh workflow run, untuk mendapatkan URL saya harus memuat ulang daftar eksekusi workflow lewat GitHub API
      Kalau ada beberapa eksekusi sekaligus memang bisa berantakan, tetapi sejauh ini cukup berjalan

  • Saya merangkum beberapa tips desain CI

    1. Gunakan bahasa skrip yang ramah CI seperti pwsh alih-alih bash
    2. Jangan taruh logika di workflow; pertahankan sesederhana mungkin
    3. Buat sebagai skrip terpisah agar bisa diuji secara lokal
    4. Sisakan output status dan informasi versi agar debugging lebih mudah
    5. Pertimbangkan runner pihak ketiga dengan fitur debugging yang baik
    • Saya tidak setuju dengan (1). Kalau proses build atau test menjadi rumit, itu menurut saya sebuah bau kode
      Shell sederhana seharusnya sudah cukup
    • Saya tidak setuju dengan (1), tetapi menurut saya (2) benar
      Ada baiknya mendefinisikan target CI di Makefile, lalu memanggilnya sesederhana make ci-test
    • Dulu saya pernah mengalami neraka plugin Jenkins
      Sejak itu saya mengelola semua CI dengan wrapper sederhana seperti make build
    • Jika semua build dibungkus dalam satu skrip, sistem CI akan kehilangan wawasan detail tiap tahap
      Akan bagus jika bisa dibedakan dengan penanda seperti BeginStep("Step Name")
    • Kalau strukturnya seperti ini, pada akhirnya saya jadi berpikir apakah kita butuh alat CI baru yang langsung mengeksekusi skrip

  • Masalahnya bukan GitHub Actions itu sendiri, melainkan otomatisasi yang ditumpuk secara berantakan di atasnya
    Logika seharusnya dijadikan skrip dalam bahasa seperti Python agar bisa dijalankan juga secara lokal

    • Keluhan banyak orang adalah mereka tidak bisa masuk via SSH ke VM yang gagal untuk debugging
      Setiap kali harus mengubah workflow, push, lalu menunggu
    • Ada juga yang bercanda bahwa “pekerjaan membuat semuanya jadi skrip seperti itu adalah kerjaan beberapa minggu yang layak dibayar”
    • Fitur khusus CI seperti deployment, rilis, dan caching sulit direproduksi sepenuhnya secara lokal
    • Pendekatan ini terasa seperti masa ketika systemd memanggil skrip init.d, tetapi tidak buruk juga
    • Ada yang dengan tegas berkata, “Ini 100% salah GitHub Actions”

  • Saya memproses semua CI di dalam container
    Platform CI hanya menjalankan container itu, jadi hal yang sama bisa dijalankan lokal juga
    Platform-platform tidak menyukai pendekatan seperti ini, karena vendor lock-in mereka jadi rusak

    • Saya suka SourceHut CI
      Saat gagal, saya bisa langsung masuk via SSH untuk debugging, dan bisa mengubah manifest lalu menjalankannya ulang tanpa push branch
      Hanya saja perlu self-hosting
    • Di GitLab CI saya juga pernah memakai image Docker khusus yang dibuat terpisah
      Standardisasi jadi lebih mudah, tetapi ada trade-off berupa perawatan image
    • Kekurangannya adalah sulit melakukan containerisasi untuk build macOS
    • Webhook GitHub sangat detail
      Praktis sebenarnya tidak ada lock-in, tetapi orang-orang terjebak dalam cargo cult CI/CD
    • Ada juga respons seperti, “Tolong kirimkan ini sebagai newsletter”

  • Saya suka GitHub Actions
    Ini lebih baik daripada Travis yang dulu saya pakai, dan sangat berguna sebagai sumber daya gratis untuk proyek OSS
    Setelah mengadopsi Nix, reproduksibilitas lingkungan meningkat sehingga kecocokannya dengan Actions jadi jauh lebih baik

    • Saya juga setuju dengan pendekatan Nix
      Container yang dibuat dengan flake bisa langsung dijalankan di Actions
      Contoh proyek

  • Menurut saya, GitHub Actions seharusnya hanya menjadi struktur untuk memanggil skrip bash atau python
    Bash punya banyak keterbatasan, Python lebih fleksibel dan juga mudah dijalankan secara lokal
    Pendekatan seperti dalam artikel ini—menginstal uv otomatis dan mengelola dependensi—terasa ideal
    Memang lebih rumit daripada bash, tetapi di lingkungan Actions dampak performanya tidak terlalu besar

    • Pada praktiknya, YAML memang untuk mendefinisikan lingkungan runtime, dan logika eksekusinya sebaiknya diletakkan di skrip eksternal

  • Masalah terbesar Actions adalah cara pemasarannya yang bilang “susun saja workflow”
    Debugging hampir mustahil, dan pengaturan cache merepotkan sehingga build menjadi lambat
    Karena itulah pendekatan menjalankan langsung di VM persisten terasa menarik

  • Saya adalah pendiri Depot
    Saya menjalankan layanan yang menyediakan runner GitHub Actions yang lebih cepat dan lebih murah
    Keluhan yang dirasakan banyak orang memang benar-benar merupakan pendapat mayoritas
    Sistem Actions secara struktural tidak efisien, dan tiap minggu kami menemukan bottleneck baru
    Saya yakin ada cara yang lebih baik, dan kami sedang bereksperimen dengannya
    Cerita lebih lengkap bisa dilihat di depot.dev

  • Akhir pekan lalu saya membuat alat bernama gg watch action
    Ini adalah alat untuk menemukan action terbaru atau yang sedang berjalan pada branch saat ini
    Link GitHub

    • Responsnya bagus, seperti “Fitur ini seharusnya sudah ada di CLI gh”
      Hanya saja ada bug di perintah gg tui yang membuat repositori tidak terlihat

  • Saya penasaran apakah alat seperti act bisa membantu
    nektos/act
    Karena perbedaan arsitektur, eksekusi lokal dan online bisa saja berbeda, tetapi tetap terlihat berguna

    • Saat terakhir saya lihat, ini belum menjadi pengganti penuh
      Kompatibilitasnya sekitar 80%
    • Memang tidak identik sepenuhnya, tetapi sangat berguna untuk membuat loop umpan balik cepat
    • Sebenarnya yang paling dibutuhkan adalah fitur untuk masuk via SSH dan melakukan debugging setelah kegagalan
      SourceHut mendukung ini, jadi benar-benar praktis
 
anyflow 2026-01-18

Sepertinya ini adalah masalah yang tak terhindarkan karena strukturnya mengharuskan logika dimasukkan ke dalam YAML.

Tulisan di atas tampaknya kurang lebih sudah memberi jawabannya seperti di bawah ini, tetapi rasanya kalau bagian skrip diganti dengan Dagger, justru itulah jawaban yang tepat.

"Jangan biarkan GitHub Actions mengelola logika; kendalikan sendiri skripnya, dan biarkan Actions hanya memanggil skrip tersebut"