4 Pola GitHub Actions untuk Monorepo ETL
Menjalankan tiga situs dari satu monorepo menimbulkan masalah. Anda menghadapi tiga pekerjaan ETL yang terpisah, tiga proses rebuild konten, dan tiga pipeline deployment. Jika Anda tidak mengoordinasikannya, mereka akan bertabrakan.
Saya menghabiskan enam minggu menguji jadwal untuk menstabilkan pengaturan ini. Berikut adalah empat pola yang saya gunakan.
- Gunakan Offset Waktu untuk Pekerjaan Cron
Menjalankan semua pekerjaan ETL pada waktu yang sama menyebabkan kegagalan. Pekerjaan-pekerjaan tersebut berebut limit API. Ketika HuggingFace atau GitHub mengembalikan error 429, prosesnya gagal.
Saya menggunakan offset 30 menit untuk mencegah hal ini.
- Pekerjaan pertama dimulai pada 02:00
- Pekerjaan kedua dimulai pada 02:30
- Pekerjaan ketiga dimulai pada 03:00
Tiga puluh menit adalah waktu yang cukup untuk menyelesaikan proses penarikan (pull) data yang berat sebelum pekerjaan berikutnya dimulai. Ini menjaga log Anda tetap bersih dan mencegah tabrakan API.
- Gunakan Flag Skip untuk Menghentikan Rebuild yang Tidak Perlu
Setiap pekerjaan ETL diakhiri dengan deployment Vercel. Masalah muncul ketika commit artikel juga memicu rebuild. Tanpa rencana, setiap pembaruan artikel memaksa ketiga situs untuk melakukan rebuild. Ini membuang-buang menit build.
Saya menggunakan tag [skip publish-articles] dalam pesan commit ETL.
Saya menambahkan langkah dalam workflow saya untuk memeriksa flag ini. Jika tag tersebut ada, workflow akan melewati (skip) langkah build dan deploy. Ini menjaga pipeline ETL tetap terpisah dari pipeline artikel.
- Gunakan Path Filter untuk Menargetkan Situs Tertentu
Anda tentu tidak ingin pembaruan satu situs memicu tiga deployment. Saya mengonfigurasi workflow setiap situs untuk hanya memantau foldernya sendiri dan folder paket bersama (shared packages).
Contoh logika:
- Situs alat AI hanya memantau
apps/ai-tools/ - Situs OSS hanya memantau
apps/oss-alternatives/
Jika Anda mengubah kode di direktori bersama, semua situs akan melakukan rebuild. Saya menerima konsekuensi ini karena perubahan kode bersama jarang terjadi.
- Tambahkan Manual Dispatch untuk Kontrol
Cron menangani rutinitas harian. Manual dispatch menangani segalanya yang lain. Saya menggunakan workflow_dispatch sehingga saya dapat:
- Menjalankan ulang pekerjaan ETL yang gagal
- Memaksa penyegaran (refresh) setelah menambahkan data
- Menjalankan dry run untuk menguji data tanpa menulis ke database
UI GitHub menampilkan menu dropdown untuk pilihan-pilihan ini. Ini mencegah kesalahan ketik dan memudahkan debugging.
Ringkasan
Pola-pola ini tidak rumit. Pola ini bersifat eksplisit. Saya menyimpan file markdown sederhana di repositori saya untuk mendokumentasikan aturan-aturan ini. Hal ini memastikan saya tidak merusak sistem saat menambahkan workflow baru.