Menghapus pratinjau pull request terlihat seperti pekerjaan satu perintah. Dengan Capgo, ada satu hal yang perlu diperhatikan: Anda harus beralih dari pratinjau yang aktif sebelum menghapusnya, lalu menghapus bundle-nya berdasarkan ID. Kami akan membangun alur pembersihan yang aman dengan kunci API yang dibatasi, pencarian pratinjau, penanganan reset, penghapusan bundle, dan otomasi CI.
Table of Contents
- Langkah 1: Buat Capgo API Key Terbatas untuk Preview Cleanup
- Langkah 2: Identifikasi Pull Request Preview dan Bundle ID-nya
- Langkah 3: Beralih dari preview aktif sebelum pembersihan
- Langkah 4: Hapus Preview Bundle berdasarkan ID dengan Kunci API
- Langkah 5: Otomatiskan Cleanup Saat Pull Request Ditutup
- Langkah 6: Verifikasi Cleanup dan Lindungi Rollouts dari Penghapusan Tidak Sengaja
- FAQ
- Kesimpulan
Langkah 1: Buat Capgo API Key Terbatas untuk Preview Cleanup
Langkah pertama dalam alur pembersihan pratinjau pull request Capgo adalah membuat kunci yang hanya bisa melakukan pekerjaan yang dibutuhkan oleh job CI Anda.
Jangan masukkan kunci organisasi yang luas ke dalam workflow pull request. Pull request bisa berasal dari branch yang belum mendapat kepercayaan. Workflow juga mungkin mencetak perintah atau nilai environment saat run gagal. Kunci yang terbatas membatasi kerusakan jika hal itu terjadi.
Di Capgo, mulai dengan kunci App Preview untuk pekerjaan pratinjau. Kunci harus terikat pada app atau scope pratinjau yang dikelola oleh job Anda. Jika tim Anda menggunakan role-based access control, batasi kunci untuk app tertentu alih-alih memberikan akses di seluruh organisasi. Capgo mendokumentasikan pilihan kunci pratinjau tersebut di pengaturan kunci API untuk workflow web app.
Simpan secret di encrypted secret store provider CI Anda. Beri nama yang jelas fungsinya, sepertiCAPGO_PREVIEW_CLEANUP_KEY. Jangan letakkan di file workflow, shell script, komentar pull request, atau log yang dihasilkan.
Lewatkan kunci ke proses pembersihan melalui environment variable. Script Anda harus gagal jika variabel tidak ada. Fallback yang diam-diam berbahaya karena bisa mengubah job pembersihan menjadi request tanpa auth, atau menggoda developer untuk menempelkan kunci ke command line.
if [ -z "$CAPGO_PREVIEW_CLEANUP_KEY" ]; then echo "Missing preview cleanup key" exit 1
fiJaga agar kunci ini terpisah dari kunci yang digunakan untuk menerbitkan bundle produksi. Job penerbitan mungkin perlu mengunggah rilis. Job pembersihan hanya perlu menghapus sumber daya pratinjau. Kunci terpisah memudahkan review dan mengurangi kemungkinan aksi penghapusan menjangkau channel produksi.
Gunakan secret yang sama di lingkungan yang dilindungi jika memungkinkan. Wajibkan persetujuan sebelum job dapat menyentuh channel bersama. Untuk pratinjau pull request biasa, job harus bekerja pada channel sementara dan tidak boleh menyentuh yang lain.
Poin Penting: Gunakan kunci App Preview khusus, batasi cakupan aplikasinya, dan simpan di secret CI yang terenkripsi.
Sebelum lanjut, uji kunci tersebut terhadap aksi baca yang tidak berbahaya. Pastikan job dapat melihat aplikasi yang dituju, tetapi tidak dapat mengakses aplikasi lain atau alur kerja produksi. Detail permintaan spesifik untuk pembersihan belum sepenuhnya dipublikasikan, jadi pertahankan uji pertama Anda tetap kecil dan periksa panduan dukungan SDK atau Capgo sebelum menambahkan panggilan penghapusan.
Langkah 2: Identifikasi Pratinjau Pull Request dan ID Bundle-nya
Kunci API pembersihan pratinjau pull request Capgo hanya berguna jika job Anda mengetahui ID pratinjau dan bundle yang dimilikinya.
Gunakan aturan penamaan yang stabil untuk channel pratinjau. Pola umum adalah nama repository ditambah nomor pull request. Poin kuncinya adalah konsistensi. Job pembersihan Anda harus membangun ulang identifikasi yang sama setelah pull request ditutup.
Simpan nama channel preview saat preview dibuat. Anda bisa menaruhnya di output workflow, check pull request, atau metadata job kecil. Jangan andalkan display name yang bisa diubah orang lain di dashboard.
Selanjutnya, daftarkan bundle yang terkait dengan preview tersebut. Aksi Delete Bundle dari Capgo membutuhkan ID bundle. Dokumentasi sumber mengarah ke panggilan list untuk mengambil semua ID bundle yang tersedia sebelum penghapusan. Perlakukan daftar itu sebagai sumber kebenaran. Jangan pernah menebak ID dari nama file, commit hash, atau nama branch.
Filter record yang dikembalikan berdasarkan channel preview atau nilai lain yang dikontrol workflow Anda. Lalu simpan ID bundle yang persis untuk setiap kecocokan. Jika daftar kosong, tandai cleanup sebagai selesai. Hasil kosong bukan kegagalan kecuali workflow Anda memang mengharapkan preview ada.
Juga catat commit SHA yang menghasilkan setiap preview. Ini memberi Anda pemeriksaan kedua sebelum penghapusan. Jika nama channel cocok tetapi commit-nya tidak, berhenti dan minta review. Jeda kecil itu bisa mencegah race saat preview baru sedang di-build sementara job cleanup lama berjalan.
Jangan hapus saat job publish masih berjalan. Tambahkan dependensi antara workflow build preview dan cleanup, atau gunakan lock dengan key nomor pull request. Job cleanup harus dimulai hanya setelah event close dan setelah upload preview yang tertunda selesai.
API publik Capgo mencakup resource seperti channel dan bundle melalui request HTTP terautentikasi, tetapi tindakan cleanup tetap perlu diverifikasi dengan cermat di proyek Anda. Halaman Ikhtisar API publik Capgo adalah tempat yang tepat untuk mengonfirmasi model resource saat ini sebelum Anda menulis wrapper.
Sampai sini, Anda seharusnya sudah punya identifier preview, daftar ID bundle yang persis, dan commit SHA yang terikat ke setiap record. Jika salah satu nilai itu hilang, berhenti di sini. Cleanup tanpa pemeriksaan kepemilikan cuma tebak-tebakan.
Langkah 3: Beralih dari preview aktif sebelum pembersihan
Preview yang aktif tidak dapat dihapus sampai aplikasi beralih dari preview tersebut atau Anda memanggilresetPreview. Ini detail kunci dalam alur pembersihan preview pull request Capgo.
Anggap preview aktif sebagai versi yang saat ini dipilih oleh app. Menghapus record di sisi server terlebih dahulu akan membuat app menunjuk ke sesuatu yang tidak lagi ada. Capgo memblokir perubahan state tersebut, jadi job pembersihan Anda harus mereset state preview app sebelum menghapus preview.
Pertama, cek apakah preview masih aktif. Jika iya, pindahkan app ke channel yang aman atau gunakan aksi reset updater. Pilihan yang tepat tergantung pada konfigurasi test app Anda. Test app sekali pakai bisa kembali ke channel default normalnya. Test app bersama mungkin butuh staging channel khusus.
GunakanresetPreviewsaat state preview perlu dihapus langsung. Pastikan pemanggilan ini terkait dengan pull request dan app yang sama yang membuat preview. Script cleanup tidak boleh mereset device produksi atau shared release channel hanya karena nama channel-nya kebetulan sama.
Ada aturan urutan yang berguna di sini:
- Pastikan pull request sudah ditutup.
- Pastikan tidak ada upload preview yang sedang berjalan.
- Pindah dari preview yang aktif atau panggil
resetPreview. - Tunggu hingga perubahan state tersebut selesai.
- Baru setelah itu panggil Delete Preview.
Jangan anggap respons HTTP sukses dari request reset sebagai bukti bahwa state app sudah berubah di setiap device. Device mungkin baru mengecek update nanti. Cleanup di sisi server tetap bisa dilanjutkan setelah assignment preview dihapus sesuai respons API, tetapi pisahkan perilaku device dari penghapusan resource.
Capgo mendukung kontrol rollout berbasis channel, sehingga pemisahan ini lebih mudah dipahami. Channel adalah jalur bernama yang memberi tahu app stream update mana yang harus diikuti. Channel preview Anda tidak boleh sama dengan channel yang dipakai device produksi.
Untuk tim yang butuh batasan lebih ketat, gunakan yang terdokumentasi Alur kerja channel Capgo untuk otomasi preview. Ini menjelaskan pola channel sementara dan membantu menjaga job pembersihan tetap terpisah dari channel default bersama.
Dokumentasi updater open-source juga mencatat batas penghapusan: preview aktif harus dialihkan dulu atau direset. Anda bisa meninjau sumbernya di repositori updater Capgo Capacitor. Sumber itu berguna saat teks di dashboard terlalu singkat untuk keputusan CI.
Tips Pro: Jadikan reset sebagai langkah terpisah yang tercatat. Jika Delete Preview gagal, log harus menunjukkan apakah preview masih aktif atau apakah permintaan penghapusan punya masalah lain.
Setelah status aktifnya hilang, catatan preview siap dihapus. Jangan gabungkan reset dan hapus jadi satu baris shell yang tidak jelas. Dua perintah yang jelas lebih mudah dicoba ulang dan jauh lebih mudah diaudit.
Langkah 4: Hapus Preview Bundle berdasarkan ID dengan Kunci API
Hapus setiap preview bundle berdasarkan ID-nya yang tepat, setelah preview aktif direset. Di sinilah kunci pembersihan Capgo menghapus objek penyimpanan yang ditinggalkan oleh pull request.
Mulai dengan daftar bundle dari Langkah 2. Untuk setiap ID yang cocok, panggil aksi Delete Bundle melalui Capgo SDK atau metode API publik terkini yang tersedia untuk akun Anda.
Periksa signature metode SDK atau konfirmasi bentuk request terkini dengan support Capgo. Catat metode dan format respons di runbook internal tim Anda setelah diverifikasi. Runbook tersebut harus mencakup versi API, identifier yang diperlukan, dan kode error yang dapat ditangani logika retry Anda.
Gunakan mode dry-run di skrip Anda. Skrip ini harus mencetak channel preview dan ID bundle yang akan dihapus, tanpa mengirim permintaan hapus. Jalankan mode tersebut terhadap beberapa pull request yang sudah ditutup. Pastikan channel produksi dikecualikan dan daftar kosong tidak diperlakukan sebagai wildcard.
Loop penghapusan yang aman memiliki tiga gerbang:
- Tolak ID bundle yang hilang atau tidak valid.
- Tolak bundle yang channel-nya tidak cocok dengan preview pull request.
- Hapus hanya setelah pemeriksaan kepemilikan berhasil.
Lalu tangani setiap respons berdasarkan tipenya. Hapus yang berhasil bisa dicatat sebagai selesai. Respons not-found bisa dianggap sudah bersih jika sumber daya diketahui sudah dihapus oleh retry sebelumnya. Error izin harus membuat job gagal dan memberi tahu pemilik. Rate limit harus dijeda dan di-retry dengan delay yang dibatasi.
Jangan retry semua error. ID yang salah tidak akan menjadi valid setelah tiga percobaan. Error otorisasi biasanya berarti scope key salah. Hanya retry kegagalan sementara, dan atur waktu maksimum agar job cleanup yang macet tidak menghabiskan antrean CI Anda.
Penghapusan bundle terpisah dari penghapusan preview. Menghapus channel preview tidak otomatis membuktikan bahwa semua bundle sudah hilang. Job Anda harus menyimpan hasil untuk setiap ID, lalu membuat permintaan daftar akhir jika API mendukungnya. Jika ada bundle yang tersisa, laporkan ID-nya dan berhenti, bukan mengklaim sukses secara diam-diam.
Jaga agar log penghapusan bebas dari rahasia. Tidak masalah mencatat nomor pull request, nama preview, ID bundle, hasil permintaan, dan timestamp. Jangan pernah mencatat kunci API, header otorisasi, atau objek permintaan lengkap yang mungkin memuatnya.
Pendekatan ini memberi Anda jejak audit yang berguna tanpa menjadikan log sebagai tempat lain di mana kredensial bisa bocor. Ini juga memudahkan pemulihan pembersihan yang gagal karena eksekusi berikutnya dapat melewati catatan yang sudah dikonfirmasi tidak ada.
Langkah 5: Otomatiskan Pembersihan Saat Pull Request Ditutup
Jalankan tugas pembersihan dari peristiwa penutupan pull request, tetapi tambahkan pemeriksaan yang mencegah build terlambat menghapus preview baru.
Workflow Anda harus menerima repositori dan nomor pull request dari payload peristiwa. Bangun ulang nama channel preview dari nilai-nilai tersebut. Jangan terima nama channel yang disediakan oleh komentar pull request atau variabel branch yang tidak tepercaya.
Urutan tugas yang berguna terlihat seperti ini:
- Muat kunci pembersihan terbatas dari rahasia terenkripsi.
- Konfirmasi bahwa peristiwanya adalah pull request yang ditutup.
- Periksa bahwa preview tersebut milik repositori dan aplikasi yang diharapkan.
- Tunggu hingga deployment preview aktif selesai.
- Beralih dari preview atau panggil
resetPreview. - Daftarkan ID bundle untuk preview tersebut.
- Hapus setiap bundle yang terverifikasi.
- Hapus record preview.
- Tulis hasil singkat ke ringkasan workflow.
Urutan penting. Jika Anda menghapus lebih dulu, aturan preview aktif dapat memblokir permintaan. Jika Anda melewatkan panggilan list, Anda mungkin tidak tahu ID bundle mana yang masih ada. Jika Anda menghapus berdasarkan nama tebakan, Anda berisiko menyentuh resource yang salah.
Gunakan aturan concurrency yang dikey ke nomor pull request. Ketika event close dan event rebuild tiba hampir bersamaan, job cleanup lama tidak boleh bersaing dengan deployment baru. Batalkan run cleanup yang sudah usang atau buat job menunggu sampai lock deployment bersih.
Workflow CLI satu perintah dari Capgo dapat mengurangi jumlah panggilan shell kustom di sekitar pekerjaan build dan release. Untuk nama perintah dan operasi yang didukung, periksa dokumentasi perintah CLI Capgo. Gunakan CLI di mana ia memberi Anda perintah yang terverifikasi. Gunakan SDK atau API publik di mana aksi pembersihan membutuhkan permintaan langsung.
Jangan taruh pembersihan di workflow yang berjalan dengan setiap push. Job push dapat menghapus preview yang masih diuji. Event close adalah pemicu yang tepat untuk pembersihan normal. Tambahkan dispatch workflow manual untuk pemulihan jika job gagal.
Atur juga fallback retensi. Jika event close terlewat, job terjadwal dapat menemukan preview yang lebih tua dari jendela uji yang diizinkan tim Anda. Job itu membutuhkan pengaman yang lebih ketat daripada hook close normal. Seharusnya hanya memilih preview dengan pemilik yang jelas dan timestamp yang kedaluwarsa.
Untuk GitHub Actions, batasi permissions dan hanya lewati nilai yang dibutuhkan oleh langkah cleanup. Dokumentasi integrasi GitHub Actions saat ini dari Capgo menjelaskan di mana token disimpan dan bagaimana workflow terhubung ke Capgo.
Sekarang Anda seharusnya punya jalur otomatis yang bereaksi terhadap penutupan, menunggu job yang bersaing, mereset status aktif, mendaftar ID, dan hanya menghapus bundle yang cocok. Ini cukup cepat untuk pengembangan harian tanpa membuat cleanup jadi sapu buta.
Langkah 6: Verifikasi Cleanup dan Lindungi Rollout dari Penghapusan Tidak Sengaja
Verifikasi menutup loop cleanup pratinjau pull request Capgo. Respons hapus saja tidak cukup untuk proses rilis yang aman.
Setelah job cleanup berjalan, periksa kembali channel pratinjau. Pastikan tidak lagi muncul sebagai pratinjau aktif. Lalu periksa daftar bundle untuk aplikasi dan filter yang sama. Hasil yang diharapkan adalah ID bundle yang ditargetkan hilang, sementara bundle produksi tetap ada.
Simpan nilai-nilai ini di ringkasan job:
- Repository dan nomor pull request.
- Nama channel pratinjau.
- Commit SHA used for ownership checks.
- ID bundle yang ditemukan.
- ID bundle yang dihapus.
- ID apa pun yang mengembalikan error.
Gunakan status yang jelas. “Cleaned” berarti semua target terverifikasi sudah dihapus. “Already clean” berarti resource sudah tidak ada sebelum run ini. “Needs review” berarti satu atau lebih pengecekan gagal. Jangan tandai penghapusan parsial sebagai sukses.
Tambahkan production guard di code. Tolak nama channel seperti default atau release channel. Tolak juga bundle jika metadatanya tidak cocok dengan preview app. Guard harus fail closed. Jika script tidak bisa mengidentifikasi target dengan pasti, script harus berhenti.
Pisahkan rollback dari cleanup. Rollback mengubah bundle yang diterima perangkat. Cleanup menghapus resource preview lama. Jika tes menemukan bug setelah pull request ditutup, Anda mungkin butuh bundle tersebut untuk investigasi. Atur retention window singkat daripada langsung menghapus begitu event masuk jika tim Anda sering debug setelah merge.
Waspadai tiga pola kegagalan umum:
- Error preview aktif: reset atau beralih dulu sebelum mencoba Delete Preview lagi.
- Bundle ID hilang: jalankan aksi list lagi daripada menebak-nebak.
- Error permission: periksa scope key, lalu buat key baru jika perlu.
Rotasi cleanup key sesuai jadwal yang ditetapkan kebijakan keamanan Anda, dan segera rotasi jika key muncul di log atau commit. Key baru harus dites sebelum key lama dicabut, kecuali kebocoran mengharuskan pencabutan segera.
Kesenjangan dokumentasi soal cleanup layak dicatat di review keamanan Anda. Jadikan panduan SDK dan Capgo yang sudah terverifikasi sebagai acuan implementasi, dan simpan kontrak request Anda sendiri dalam version control.
Poin Penting: Verifikasi daftar preview dan bundle setelah penghapusan, blokir target produksi di code, dan laporkan cleanup parsial sebagai kegagalan.
Satu command hanya berguna kalau guardrails-nya jelas. Lacak preview-nya. Pakai nama channel yang mudah diprediksi. Roll back perubahan release secara terpisah. Lalu biarkan job cleanup menjalankan tugas kecilnya tanpa menyentuh traffic live.
FAQ
Bisakah saya menghapus preview pull request Capgo yang aktif?
Tidak. Preview yang aktif harus dialihkan dulu, atau Anda harus memanggilresetPreview. Setelah status aktifnya hilang, jalankan Delete Preview. Aturan ini detail utama yang perlu diingat saat mengatur key API untuk cleanup preview pull request Capgo di CI.
Apakah saya perlu bundle ID untuk membersihkan preview Capgo?
Ya. Aksi Delete Bundle dari Capgo memerlukan bundle ID, jadi daftarkan bundle yang tersedia sebelum menghapusnya. Cocokkan setiap ID dengan channel preview dan commit sebelum mengirim request delete. Jangan pernah menyusun ID dari nama branch atau menganggap bahwa menghapus preview juga menghapus semua bundle.
Key API jenis apa yang sebaiknya dipakai CI untuk cleanup preview?
Gunakan kunci App Preview terbatas untuk pembersihan preview, disimpan di penyimpanan rahasia terenkripsi provider CI Anda. Batasi kunci ke aplikasi atau scope yang dibutuhkan. Pisahkan dari kunci yang dipakai untuk menerbitkan update produksi. Ini membuat job pembersihan Capgo lebih mudah ditinjau dan lebih aman dirotasi.
Bisakah saya mengotomatiskan pembersihan saat pull request ditutup?
Ya. Picu pembersihan dari event pull request yang ditutup, lalu tunggu job deployment aktif selesai sebelum mereset preview. Ambil daftar bundle ID, hapus kecocokan yang terverifikasi, dan konfirmasi hasilnya. Tambahkan kontrol konkurensi agar build yang terlambat tidak bertabrakan dengan job pembersihan.
Mengapa permintaan pembersihan Capgo saya gagal?
Penyebab umumnya adalah preview yang masih aktif, bundle ID yang hilang, atau kunci tanpa scope yang dibutuhkan. Reset preview dulu, ulangi panggilan list, dan periksa izin kunci. Karena detail permintaan bisa berbeda tergantung versi API atau SDK, konfirmasi metode dan parameter yang berlaku sebelum mengubah skrip.
Kesimpulan
Gunakan Capgo dengan kunci preview khusus dan urutan pembersihan yang ketat: reset preview aktif, ambil daftar bundle ID-nya, hapus bundle yang terverifikasi, lalu hapus preview. Mulai dengan dry run pada satu pull request yang ditutup, konfirmasi struktur request di SDK terkini, dan tambahkan guard channel produksi sebelum mengaktifkan pembersihan otomatis.
