Saya akan berpikir dua kali sebelum menggunakan GitHub Actions lagi

• Keluhan terhadap GitHub Actions
  • Tim terdiri dari sekitar 15 engineer, dan semua orang terus mendorong kode ke branch main
  • Kode berada dalam bentuk monorepo yang terbagi menjadi beberapa modul, dan dideploy beberapa kali sehari melalui pendekatan trunk-based development
• Ada kasus di mana GitHub Actions digunakan dengan baik, tetapi pada skala atau lingkungan tertentu keterbatasannya terlihat jelas

Pull request dan pemeriksaan wajib

• Monorepo dibagi ke beberapa folder, dan setiap folder menjalankan pengujian, build, serta deployment secara independen
• Menggunakan fitur paths di GitHub Actions agar pipeline terkait hanya terpicu saat ada perubahan pada folder tertentu
• Prinsip bahwa semua pemeriksaan harus lolos sebelum pull request digabungkan memang baik, tetapi menjadi bermasalah saat dikombinasikan dengan struktur monorepo
  • Contoh: pemeriksaan web-app1 - Unit tests disetel sebagai “wajib”, tetapi jika tidak ada perubahan di folder web-app1, pemeriksaan itu tidak dijalankan
  • Akibatnya, meskipun hanya satu folder yang berubah, pengujian terkait folder lain tidak dijalankan sehingga penggabungan itu sendiri menjadi tidak mungkin
• Ini bisa terselesaikan jika GitHub menangani hal ini bukan berdasarkan nama pemeriksaan wajib, melainkan dengan cara seperti “bisa digabungkan jika semua pemeriksaan yang benar-benar terpicu saat ini lolos”, tetapi sayangnya tidak ada perubahan selama 3 tahun
• Besarnya dampak masalah ini juga terlihat pada thread isu GitHub terkait 1, 2
• Pada akhirnya, untuk mengakali ini, harus menjalankan pipeline tambahan atau memeliharanya dengan kompleksitas dan biaya yang tinggi

Reusability dan YAML

• Semakin besar skala pipeline, semakin terasa sulit mengelolanya dengan GitHub Actions
  • Banyak kondisi if yang masuk, dan meskipun workflow dipisah, jumlah file yang harus dikelola bertambah sehingga maintainability menurun
• Saat ingin digunakan ulang, bagian pemanggilan yang seharusnya selesai dalam satu baris tetap membutuhkan banyak baris dan konfigurasi duplikat, sehingga sudah ada lebih dari 30 file menumpuk di folder .github
• Pada klausa needs, jika hasil refactor tidak mencerminkan job yang sudah dihapus, butuh waktu sampai error tersebut ditemukan
• GitHub Actions tidak bisa dijalankan secara lokal, sehingga pengembangan dan pengujian menjadi rumit
  • Ada alat seperti act, tetapi dalam penggunaan nyata sering memiliki banyak keterbatasan dan tidak memenuhi harapan

Ketidakpedulian GitHub

• Masalah terbesar dari poin-poin di atas adalah GitHub tampak tidak menganggap isu-isu ini terlalu penting
• Banyak isu sudah terbuka selama bertahun-tahun dan tidak masuk ke roadmap publik, sehingga tidak terlihat ada kemauan untuk memperbaikinya
• Bahkan masalah yang lama dibicarakan pun belakangan ditutup massal dalam isu-isu terbaru, yang memicu penolakan dari komunitas

Opsi

• Dengan mempertimbangkan masalah-masalah ini dan kurangnya kemauan GitHub untuk memperbaikinya, perlu berhati-hati sebelum mengadopsi GitHub Actions
• Di pasar ada berbagai opsi CI/CD lain seperti GitLab, Jenkins, dan TeamCity
• Alat yang menawarkan pendekatan baru seperti Dagger juga layak dipertimbangkan

[bichi]

CI/CD, GitLab yang paling mantap

[devsepnine]

Saya juga ingat waktu pakai GitLab lalu ditempatkan di lingkungan GitHub Actions, rasanya seperti tidak ada yang berjalan ...

[jjpark78]

Salah satu keluhan besar saya juga adalah di GitHub tidak ada cara untuk mengelola repositori dengan mengelompokkannya berdasarkan grup..

[jjpark78]

Menurut saya, untuk pipeline GitLab memang sangat bagus. Semua hal yang disebutkan di atas bisa dilakukan di GitLab.
Kalau memakai monorepo, cukup mudah untuk mengatur bahwa saat folder tertentu berubah, maka komponen-komponen tertentu harus dijalankan untuk pengujian.

[tujuc]

Ini memang perlu tahu sejarah GitHub Actions dulu...

Awal-awal GitHub Actions punya kondisi yang berbeda dari sekarang... Sekitar 6 bulan sebelum dibuka (ingatan saya agak samar), GitHub diakuisisi oleh Microsoft, dan sepertinya pengembangan Actions dikerjakan bersama tim Azure DevOps di Microsoft. Pada saat itu, Azure DevOps tidak lagi mendapat fitur baru, dan fitur-fitur yang ada di Azure DevOps justru mulai muncul sebagai fitur baru di GitHub Actions... Di masa itu juga berubah ke YAML, lalu lingkungan yang sekarang pun terbentuk.... T_T

Setelah itu para pengembang sepertinya kembali ke bagian masing-masing, jadi terlihat seperti sudah tidak banyak disentuh lagi... Sayang sekali... Di perusahaan saya sekarang, CI/CD dibangun berbasis GitHub Actions... sejauh ini belum ada kekurangan yang terasa, jadi masih kami pakai...

Sepertinya memang harus terus dipantau...

[GN⁺]

Opini Hacker News

• DSL pipeline seharusnya tidak memuat logika nyata, melainkan hanya digunakan untuk mengoordinasikan pekerjaan. Tugas yang kompleks sebaiknya dibuat sebagai skrip agar bisa dijalankan dengan sederhana. Dengan begitu, tugas yang sama bisa dijalankan dengan mudah di GitHub Actions, Jenkins, Azure DevOps, dan lainnya

• Saat menyiapkan GitHub Actions, sebaiknya hindari action siap pakai dan gunakan hanya sebagai peluncur shell sederhana. Tulis skrip dalam Python, Ruby, Bash, dan sebagainya, lalu jalankan dari GitHub Action agar mudah diuji secara lokal dan mengurangi penderitaan yang tidak perlu

• GitHub Actions dapat menjalankan pemeriksaan hanya ketika kondisi tertentu terpenuhi. Namun, jika memakai aturan seperti ini, Anda akan menghadapi masalah "pull request dan pemeriksaan wajib". Saat digunakan bersama layanan eksternal, pemeriksaan wajib harus lolos; jika tidak, merge tidak bisa dilakukan

• Salah satu cara mengatasi masalah 'pull request dan pemeriksaan wajib' adalah membuat versi no op untuk setiap workflow pemeriksaan wajib, lalu menjalankannya saat kondisi tidak terpenuhi dan keluar dengan kode 0. Ini adalah fungsi dasar, tetapi solusinya agak rumit

• Travis CI dulu sangat bagus untuk menguji CI secara lokal. GitHub Actions dibuat untuk bersaing dengan GitLab CI, dan saat itu sedang kehilangan pangsa di pasar enterprise

• Disarankan mencoba Buildkite. Jika sudah melampaui GitHub Actions, Buildkite bisa menjadi alternatif yang baik. Ada pengalaman memakainya di perusahaan teknologi besar di AS, dan itu merupakan satu-satunya bagian CI yang terasa menyenangkan

• Arsitektur GitHub Actions dapat mendorong pengambilan keputusan keamanan yang buruk. Misalnya, secret organisasi atau repository memang praktis, tetapi bisa menjadi celah keamanan. Environment repository dapat memiliki secret terpisah, tetapi workflow yang tepat harus dipastikan hanya bisa mengakses environment yang tepat

• Filosofi umum sistem CI itu keliru. Alih-alih CI yang menjalankan kode, seharusnya kode yang menjalankan CI. CI perlu menyediakan API agar pengguna bisa memberikan informasi ke sistem

• Dengan Bazel, alat CI bisa dibuat untuk membangun target Bazel, dan bila perlu paralelisme dapat ditingkatkan melalui remote build execution. Ini cocok untuk basis kode sekitar 10M+ baris atau layanan berskala besar

• Di GitHub, Anda bisa menetapkan "pemeriksaan wajib" yang harus selalu hijau. Namun, karena pemeriksaan itu hanya berjalan saat ada perubahan di folder tertentu, perubahan di folder lain justru bisa membuat merge tidak mungkin. Jika tidak menjalankan semua pengujian, integrasi kehilangan maknanya, jadi pengujian harus bisa berjalan cepat