Awalnya cuma mau pasang satu link
Jawaban singkatnya: kamu tidak butuh GitHub Actions untuk menerbitkan situs di Cloudflare Pages. Kalau proyek Pages kamu sudah terhubung ke GitHub, Cloudflare sendiri yang akan build dan deploy setiap kali kamu push. Kalau proyeknya tipe Direct Upload (unggah langsung), build seluruh situs lalu unggah hasilnya pakai Wrangler. Begini cerita saya sampai paham, setelah muter-muter lumayan jauh.
Tugasnya sebenarnya kecil sekali. Supaya lolos review situs dari program afiliasi, saya perlu memasang satu link produk hard disk eksternal di sebuah artikel sungguhan. Sebelum link itu ada pemberitahuan yang jelas: "Halaman ini berisi link afiliasi. Pemilik situs bisa mendapat komisi kalau kamu membeli lewat link ini." Link dibuat, dimasukkan ke artikel, lalu di-commit ke GitHub.
Beres, pikir saya.
Tapi begitu kodenya masuk GitHub, muncul salah paham.
Kode yang sudah ada di GitHub belum tentu halamannya sudah tayang di internet.
GitHub Actions yang biasa dipakai sedang tidak bisa digunakan. Ada yang usul: tangkap saja URL itu pakai Cloudflare Worker dan tayangkan dari sana. Tapi dengan syarat penggunaan kali ini, jalan itu juga tidak bisa dipakai.
Niatnya cuma pasang satu link, tahu-tahu jadi rapat deployment: "CI-nya gimana? Worker-nya? Pages ini terhubung ke Git atau Direct Upload?"
Begitulah proyek "Sagrada Familia afiliasi gedung kedua" dimulai.
Tapi kalau tiap bagian dipisahkan satu per satu, masalahnya jadi jauh lebih sederhana.
1. Kenapa halaman publik harus ada lebih dulu
Sovrn Commerce memberi arahan untuk situs konten dan blog: pasang dulu link Commerce di situs yang didaftarkan, hasilkan beberapa klik, baru setelah itu kampanye masuk tahap review.[3]
Artinya bukan "disetujui dulu, baru pasang link". Peninjau harus bisa melihat dulu contoh nyata yang sudah terpasang.
Sovrn juga meminta setiap halaman yang punya link afiliasi memberi tahu pembaca dengan jelas bahwa kamu bisa dapat uang dari link itu. Pemberitahuan ini harus terlihat sebelum link atau promosinya.[4]
Yang dibutuhkan bukan situs perbandingan produk yang mewah. Syaratnya pendek:
- ada artikel sungguhan di situs yang didaftarkan;
- artikel itu punya link afiliasi;
- pemberitahuan muncul sebelum link;
- siapa saja bisa membuka halaman lewat URL publiknya;
- setelah tayang, kamu bisa menghasilkan beberapa klik untuk cek.
Poin pentingnya ada di nomor dua dari bawah: file di repositori GitHub belum sama dengan halaman publik.
2. GitHub Actions mati bukan berarti Cloudflare Pages ikut mati
GitHub Actions adalah fitur otomatisasi (CI/CD) bawaan GitHub. Fungsinya menjalankan build, tes, dan deploy di dalam GitHub.
Sementara itu, Cloudflare Pages punya Git integration sendiri. Proyek Pages bisa langsung dihubungkan ke GitHub atau GitLab. Setiap kali kamu push ke repositori itu, Cloudflare sendiri yang build dan deploy.[1]
Alurnya begini:
push ke GitHub → Cloudflare Pages mendeteksi commit → Cloudflare build → Cloudflare deploy
Di rantai ini sama sekali tidak ada workflow GitHub Actions.
Ini poin pentingnya. "GitHub Actions tidak bisa dipakai" tidak sama dengan "GitHub tidak bisa menerbitkan ke Cloudflare". Keduanya hal yang berbeda.
Bayangkan begini: GitHub Actions itu ban berjalan di gudangmu sendiri. Git integration milik Cloudflare itu kurir yang datang sendiri untuk menjemput paket.
Ban berjalannya boleh mati, kurirnya tetap datang menjemput.
3. Pertama, cek dulu proyek Pages kamu tipe yang mana
Kalau langkah ini dilewati, Cloudflare Pages cepat sekali berubah jadi labirin.
Ada dua cara utama untuk menerbitkan:
| Tipe | Pemicunya | Yang build dan deploy | Cocok untuk |
|---|---|---|---|
| Git integration | push ke GitHub / GitLab | Cloudflare | repositori jadi patokan dan kamu mau terbit otomatis |
| Direct Upload (unggah langsung) | file hasil build yang sudah jadi | Wrangler atau dasbor | build di komputer sendiri atau CI lain, lalu unggah hasilnya |
Dokumentasi resmi Cloudflare menyebut satu hal dengan jelas: proyek yang dibuat dengan Git integration tidak bisa diubah belakangan menjadi proyek Direct Upload biasa. Proyek yang terhubung ke Git tetap bisa di-deploy manual pakai Wrangler, tapi tidak bisa pakai fitur seret-dan-lepas di dasbor.[1][2]
Sebaliknya juga sama. Proyek yang dari awal tipe Direct Upload tidak bisa ditambahi Git integration belakangan. Kalau mau deploy otomatis dari Git, kamu perlu proyek Pages baru.[2]
Jadi pertanyaan pertama bukan "gimana cara deploy-nya?"
Tapi ini: "Proyek Pages saya sekarang tipe Git integration atau Direct Upload?"
Begitu jawabannya jelas, separuh pilihan langsung gugur.
4. Kalau Git integration, tidak perlu menghidupkan lagi GitHub Actions
Kalau repositori GitHub kamu sudah terhubung dengan benar ke Cloudflare Pages, jalan tercepat bukan Worker dan bukan CI baru.
Cek hal-hal ini di proyek Pages kamu:
- terhubung ke repositori GitHub yang benar;
- branch produksi memang branch yang ingin kamu terbitkan;
- build otomatis untuk branch produksi tidak sedang dijeda;
- perintah build dan folder output cocok dengan proyek sekarang;
- setelah push, muncul deploy baru di layar Deployments milik Pages;
- konten baru terlihat di alamat
pages.devkamu; - terakhir, domain milikmu sendiri juga menampilkan konten baru yang sama.
Git integration Cloudflare memang build dan deploy berdasarkan commit di branch yang terhubung.[1]
Jadi, meskipun GitHub Actions sedang tidak bisa dipakai, situs tetap bisa diperbarui selama build milik Cloudflare sendiri masih jalan.
Yang perlu dilakukan di sini bukan membangun sistem rumit lagi. Cukup cek apakah pintu jemput milik Cloudflare sudah terbuka.
5. Kalau Direct Upload, unggah hasil build lengkap, bukan satu halaman saja
Direct Upload artinya menyerahkan satu set file statis yang sudah jadi ke Cloudflare Pages. Dokumentasi resmi menjelaskan cara mengunggah file hasil build lewat Wrangler atau dasbor.[2]
Di sini sering muncul jalan pintas yang berbahaya:
"Saya cuma ubah satu artikel. Kenapa tidak unggah HTML itu saja?"
Kalau situs statismu di-build sekaligus, sebaiknya jangan.
Yang di-deploy bukan "satu file yang berubah di Git", tapi seluruh hasil build situs pada saat itu. Satu kali build biasanya ikut membuat ulang daftar halaman, CSS, JavaScript, indeks pencarian, gambar, dan aturan rute. Kalau satu halaman dimasukkan manual, situs yang tayang jadi tidak cocok lagi dengan repositori.
Dengan Direct Upload, alur dasarnya:
ambil versi terbaru → jalankan perintah build proyek → cek folder output → deploy seluruh output → cek URL yang tayang
Contohnya, untuk situs statis berbasis Node, jalankan perintah build milik proyek seperti pnpm build, lalu unggah folder hasilnya seperti dist.
Yang penting, situs produksi jangan sampai jadi dunia paralel misterius yang diedit tangan oleh seseorang.
6. Kalau Worker tidak bisa dipakai, coret saja dari rencana
Kalau perlu menayangkan satu halaman dengan cepat, menangkap rute itu pakai Worker memang bisa berhasil secara teori.
Tapi kalau syarat penggunaannya tidak mengizinkan Worker, seperti kali ini, tidak ada gunanya menyusun rencana di sekitarnya.
Setiap jalan "siapa tahu bisa" yang dibiarkan di rancangan bikin semuanya makin susah dirawat.
- GitHub Actions: tidak bisa dipakai
- Worker: tidak bisa dipakai
- Jadi pilih satu: Git integration Cloudflare Pages atau Direct Upload
Sudah, itu saja.
Mencari satu pintu utama yang sedang terbuka jauh lebih cepat daripada membangun sepuluh pintu darurat.
Jangan bangun sistem deploy kedua cuma untuk menayangkan satu link afiliasi.
Itu pelajaran terbesar dari semua ini.
7. "Sudah terbit" dibuktikan di halaman nyata, bukan dengan hash commit
Kesalahan klasik saat mengelola situs adalah menganggap langkah di tengah jalan sebagai "selesai".
- kodenya sudah ditulis
- sudah di-commit ke GitHub
- build-nya lolos
- deploy sudah muncul di Cloudflare
Semuanya penting, tapi pembaca hanya melihat URL terakhir.
Untuk halaman review afiliasi seperti ini, pengecekan terakhirnya:
- URL publik bisa dibuka di jendela penyamaran (incognito);
- yang tampil versi artikel terbaru;
- pemberitahuan afiliasi muncul sebelum link;
- link produk mengarah ke halaman yang benar;
- tampilan di HP rapi;
- kalau perlu, hasilkan beberapa klik untuk cek;
- cek jumlah klik dan status review di akun Sovrn.
Sovrn menjelaskan alur kampanye konten dan blog begini: pasang link, hasilkan klik, lalu review.[3]
Jadi "sudah masuk GitHub, tinggal tunggu review" itu belum cukup. Kamu baru berdiri di garis start kalau peninjau bisa melihatnya berjalan di URL yang tayang.
8. Ke depannya, jangan tulis mati URL afiliasi di isi artikel
Satu link dipasang manual itu tidak masalah.
Tapi kalau artikelnya sudah ratusan atau ribuan, dan setiap kali harus ada orang yang memutuskan "Artikel ini pakai iklan atau tidak? Di mana? Produk apa? Untuk negara mana?", di samping pabrik kontenmu bakal tumbuh pabrik iklan juga.
Langkah berikutnya adalah memisahkan isi artikel dari data monetisasi.
Misalnya, setiap artikel cukup punya blok pengaturan kecil seperti ini:
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
Lalu saat terbit, prosesnya berjalan begini:
artikel → cek monetisasi → pilih produk → buat link afiliasi → sisipkan saat halaman dibuat → ukur hasilnya
Artikelnya tetap jadi aset jangka panjang. URL produk, stok, toko, dan pembagian per negara jadi komponen yang bisa diganti kapan saja.
Dengan begitu, kamu tidak perlu membongkar teks di 12 bahasa setiap kali ada link rusak atau produk ganti.
Link afiliasi itu bukan artikelnya.
Anggap saja sebagai pipa penjualan yang disambungkan ke artikel belakangan. Untuk jangka panjang, cara ini jauh lebih awet.
9. Kesimpulan: kalau CI macet, cari dulu pintu masuk Cloudflare yang asli sebelum membangun istana baru
Cerita ini cukup mewakili banyak kasus.
Awalnya cuma: "Pasang satu link hard disk buat review."
Link-nya sudah jadi. Pemberitahuannya sudah ditulis. Semuanya sudah ada di GitHub.
Tapi saat mau tayang, GitHub Actions tidak bisa dipakai. Mencoba memutar lewat Worker juga tidak bisa.
Kalau di titik itu kamu menambah sistem baru lagi, tujuannya diam-diam bergeser: dari "menayangkan satu link" jadi "memperluas platform deploy".
Pada akhirnya, keputusan yang perlu diambil cuma ini:
- kalau proyek Pages kamu pakai Git integration, biarkan Cloudflare yang build;
- kalau Direct Upload, build seluruh situs lalu deploy hasil resminya;
- kalau Worker tidak bisa dipakai, coret dari daftar;
- jangan pernah menyebut commit di GitHub sebagai "sudah terbit";
- cek pemberitahuan, link, tampilan halaman, dan klik di URL publik yang asli.
Yang paling berisiko bukan pilihan yang terlalu sedikit.
Tapi pilihan yang tidak bisa dipakai, tapi dibiarkan selamanya di rancangan.
