Cleanup Pull Request Preview Capgo API Key

Menghapus pull request preview terlihat seperti pekerjaan satu perintah saja. Namun, Capgoada satu kendala: Anda harus keluar dari preview yang aktif sebelum menghapusnya, lalu hapus bundle berdasarkan ID. Kami akan membangun alur cleanup yang aman dengan API key yang terbatas, preview lookup, penanganan reset, penghapusan bundle, dan otomatisasi CI.

Table of Contents

• Langkah 1: Buat Capgo API Key Terbatas untuk Cleanup Preview
• Langkah 2: Identifikasi Pull Request Preview dan Bundle ID-nya
• Langkah 3: Alihkan dari Preview Aktif Sebelum Cleanup
• Langkah 4: Hapus Preview Bundle via ID dengan Key API
• Langkah 5: Otomatisasi Cleanup Saat Pull Request Ditutup
• Langkah 6: Verifikasi Cleanup dan Lindungi Rollout dari Penghapusan
• FAQ
• Kesimpulan

Langkah 1: Buat Key Capgo API Terbatas untuk Preview Cleanup

Langkah pertama dalam alur cleanup Capgo pull request preview adalah membuat key yang hanya bisa melakukan tugas yang dibutuhkan CI job Anda.

Jangan gunakan key organisasi yang luas dalam workflow pull request. Pull request bisa datang dari branch yang belum terpercaya. Workflow juga bisa mencetak command atau nilai environment saat run gagal. Key yang spesifik akan membatasi dampak jika hal itu terjadi.

Di Capgo, mulailah dengan App Preview key untuk pekerjaan preview. Key tersebut harus terikat pada scope app atau preview yang dikelola job Anda. Jika tim Anda menggunakan role-based access control, batasi key hanya pada app tertentu daripada memberi akses ke seluruh organisasi. Capgo mendokumentasikan pilihan preview key tersebut di pengaturan key API untuk workflow web app.

Simpan secret di encrypted secret store milik provider CI Anda. Beri nama yang menjelaskan fungsinya, sepertiCAPGO_PREVIEW_CLEANUP_KEY. Jangan letakkan di file workflow, shell script, komentar pull request, atau log yang dihasilkan.

Teruskan key ke proses cleanup melalui environment variable. Script Anda harus gagal jika variabel tersebut tidak ada. Silent fallback sangat berbahaya karena bisa mengubah job cleanup menjadi request tanpa auth, atau memancing developer untuk menempelkan key langsung di command line.

if [ -z "$CAPGO_PREVIEW_CLEANUP_KEY" ]; then echo "Missing preview cleanup key" exit 1
fi

Pisahkan key ini dari key yang digunakan untuk publish production bundles. Job publish mungkin perlu upload rilis, sedangkan job cleanup hanya perlu menghapus resource preview. Key yang terpisah mempermudah review dan mengurangi risiko aksi delete mengenai production channel.

Gunakan secret yang sama di protected environment jika memungkinkan. Wajibkan approval sebelum sebuah job bisa menyentuh shared channels. Untuk preview pull request biasa, job tersebut seharusnya hanya bekerja pada temporary channel dan tidak lainnya.

Poin Penting: Gunakan App Preview key khusus, batasi scope app-nya, dan simpan di dalam encrypted CI secrets.

Sebelum lanjut, tes key tersebut dengan aksi read yang aman. Pastikan job bisa melihat app yang dituju, tetapi tidak bisa mengakses app lain atau production workflow. Detail request eksak untuk cleanup belum dipublikasikan sepenuhnya, jadi lakukan tes kecil terlebih dahulu dan periksa panduan support SDK atau Capgo sebelum menambahkan pemanggilan delete.

Langkah 2: Identifikasi Pull Request Preview dan Bundle ID-nya

Key API untuk cleanup pull request preview Capgo hanya berguna jika job Anda mengetahui preview dan bundle ID mana yang menjadi miliknya.

Gunakan aturan penamaan yang stabil untuk preview channel. Pola umum yang digunakan adalah nama repositori ditambah nomor pull request. Kuncinya adalah konsistensi. Job cleanup Anda harus membangun kembali identifier yang sama setelah pull request ditutup.

Simpan nama preview channel saat preview dibuat. Anda bisa menyimpannya di workflow output, pull request check, atau metadata job yang kecil. Jangan mengandalkan display name yang bisa saja diubah oleh orang di dashboard.

Selanjutnya, list bundle yang terhubung dengan preview tersebut. Aksi Delete Bundle pada Capgo memerlukan bundle ID. Dokumentasi sumber menyarankan pemanggilan list untuk mengambil semua bundle ID yang tersedia sebelum penghapusan. Gunakan list tersebut sebagai source of truth. Jangan pernah menebak ID dari nama file, commit hash, atau nama branch.

Filter record yang dikembalikan berdasarkan preview channel atau nilai lain yang dikontrol workflow Anda. Kemudian simpan bundle ID yang tepat untuk setiap kecocokan. Jika list kosong, tandai cleanup sebagai selesai. Hasil kosong bukan berarti gagal, kecuali jika workflow Anda memang mengharapkan adanya preview.

Catat juga commit SHA yang menghasilkan setiap preview. Ini memberi Anda pengecekan kedua sebelum penghapusan. Jika nama channel cocok tetapi commit tidak, hentikan proses dan minta review. Jeda singkat ini dapat mencegah race condition di mana preview baru sedang dibangun saat job cleanup lama sedang berjalan.

Jangan hapus saat job publish masih berjalan. Tambahkan dependency antara workflow preview build dan cleanup, atau gunakan lock berdasarkan nomor pull request. Job cleanup hanya boleh dimulai setelah event close dan setelah semua proses preview upload selesai.

API publik milik Capgo mencakup resource seperti channel dan bundle melalui request HTTP terautentikasi, namun tindakan cleanup tetap butuh verifikasi teliti di proyek Anda. Capgo Ringkasan API publik Capgo adalah tempat yang tepat untuk mengonfirmasi model resource saat ini sebelum Anda menulis wrapper.

Sekarang Anda seharusnya sudah memiliki preview identifier, daftar bundle ID yang tepat, dan commit SHA yang terikat ke setiap record. Jika salah satu nilai ini hilang, berhenti di sini. Cleanup tanpa pengecekan ownership hanyalah tebak-tebakan.

Langkah 3: Alihkan dari Preview Aktif Sebelum Cleanup

Preview yang aktif tidak bisa dihapus sampai aplikasi beralih darinya atau Anda memanggilresetPreview. Ini adalah detail kunci dalam alur cleanup pull request preview Capgo.

Anggap preview aktif sebagai versi yang sedang dipilih oleh aplikasi. Menghapus record di sisi server terlebih dahulu akan membuat aplikasi menunjuk ke sesuatu yang sudah tidak ada. Capgo memblokir perubahan state tersebut, jadi job cleanup Anda harus mereset state preview aplikasi sebelum menghapus preview-nya.

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 channel staging khusus.

GunakanresetPreviewsaat state preview perlu dihapus langsung. Pastikan pemanggilan ini terikat pada 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 proses preview upload yang berjalan.
• Pindah dari preview aktif atau panggilresetPreview.
• Tunggu perubahan state tersebut selesai.
• Baru setelah itu panggil Delete Preview.

Jangan anggap respons HTTP sukses dari request reset sebagai bukti bahwa app sudah berubah state di setiap device. Device mungkin mengecek update nanti. Cleanup sisi server tetap bisa dilanjutkan setelah assignment preview dihapus sesuai respons API, tapi pisahkan perilaku device dari penghapusan resource.

Capgo mendukung kontrol rollout berbasis channel, yang membuat 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 digunakan device produksi.

Untuk tim yang butuh batas lebih ketat, gunakan yang terdokumentasi Workflow channel Capgo untuk otomatisasi preview. Ini menjelaskan pola channel sementara dan membantu memisahkan job cleanup dari channel default bersama.

Dokumentasi updater open-source juga mencatat limit penghapusan: preview yang aktif harus di-switch atau di-reset terlebih dahulu. Anda bisa meninjau source-nya di repositori updater Capgo Capacitor. Source tersebut berguna jika wording di dashboard terlalu singkat untuk pengambilan keputusan CI.

Tips Pro: Jadikan reset sebagai langkah log terpisah. Jika Delete Preview gagal, log harus menunjukkan apakah preview masih aktif atau apakah ada masalah lain pada request delete.

Setelah status aktif hilang, record preview siap untuk dihapus. Jangan gabungkan reset dan delete menjadi satu baris perintah yang tidak jelas. Dua perintah yang jelas lebih mudah untuk di-retry dan jauh lebih mudah untuk diaudit.

Langkah 4: Hapus Preview Bundles berdasarkan ID dengan Key API

Hapus setiap preview bundle berdasarkan ID tepatnya, setelah preview yang aktif telah di-reset. Di sinilah Capgo cleanup key menghapus objek storage 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 yang tersedia di akun Anda.

Periksa signature method SDK atau konfirmasi struktur request saat ini dengan bantuan Capgo. Catat format method dan response di runbook internal tim setelah Anda memverifikasinya. Runbook tersebut harus mencakup versi API, identifier yang diperlukan, dan error code yang bisa ditangani oleh retry logic Anda.

Gunakan mode dry-run pada script Anda. Mode ini harus mencetak preview channel dan bundle ID yang akan dihapus tanpa mengirimkan request delete. Jalankan mode tersebut pada beberapa pull request yang sudah closed. Pastikan mode ini mengecualikan production channel dan tidak menganggap list kosong sebagai wildcard.

Loop penghapusan yang aman memiliki tiga gerbang:

1. Tolak bundle ID yang hilang atau malformed.
2. Tolak bundle yang channel-nya tidak cocok dengan pull request preview.
3. Hapus hanya setelah pengecekan ownership berhasil.

Kemudian tangani setiap response berdasarkan tipenya. Delete yang sukses dapat dicatat sebagai selesai. Response not-found dapat dianggap sudah bersih jika resource tersebut memang sudah dihapus oleh retry sebelumnya. Error permission harus membatalkan job dan memberi alert ke owner. Rate limit harus menjeda dan melakukan retry dengan delay yang dibatasi.

Jangan melakukan retry untuk setiap error. ID yang salah tidak akan menjadi valid setelah tiga kali percobaan. Error otorisasi biasanya berarti scope key salah. Lakukan retry hanya pada transient failure, dan atur maksimum run time agar job cleanup yang stuck tidak menghabiskan antrean CI Anda.

Penghapusan bundle terpisah dari penghapusan preview. Menghapus preview channel tidak otomatis menjamin semua bundle sudah hilang. Tugas Anda harus menyimpan hasil untuk setiap ID, lalu lakukan request list terakhir jika API mendukungnya. Jika masih ada bundle yang tersisa, laporkan ID tersebut dan berhenti, jangan hanya mengklaim sukses secara diam-diam.

Pastikan log penghapusan bebas dari rahasia. Tidak masalah jika Anda mencatat nomor pull request, nama preview, bundle ID, hasil request, dan timestamp. Jangan pernah mencatat API key, authorization header, atau objek request lengkap yang mungkin mengandung data tersebut.

Pendekatan ini memberi Anda audit trail yang berguna tanpa membuat log menjadi tempat kebocoran kredensial. Ini juga memudahkan proses cleanup yang gagal untuk dilanjutkan kembali karena run berikutnya bisa melewati record yang sudah terkonfirmasi hilang.

Langkah 5: Otomatisasi Cleanup Saat Pull Request Ditutup

Jalankan job cleanup dari event pull request close, tetapi tambahkan pengecekan agar build yang terlambat tidak menghapus preview yang baru.

Workflow Anda harus menerima repository dan nomor pull request dari event payload. Susun ulang nama preview channel dari nilai tersebut. Jangan menerima nama channel yang diberikan melalui komentar pull request atau variabel branch yang tidak terpercaya.

Urutan job yang berguna adalah sebagai berikut:

1. Muat restricted cleanup key dari encrypted secrets.
2. Konfirmasi bahwa event adalah closed pull request.
3. Periksa apakah preview tersebut milik repository dan app yang sesuai.
4. Tunggu deployment preview yang sedang aktif selesai.
5. Pindah dari preview atau panggilresetPreview.
6. Daftar bundle ID untuk preview tersebut.
7. Hapus setiap bundle yang terverifikasi.
8. Hapus record preview.
9. Tulis ringkasan hasil ke workflow summary.

Urutan itu penting. Jika Anda menghapus lebih dulu, aturan preview aktif bisa memblokir request. Jika Anda melewatkan pemanggilan list, Anda mungkin tidak tahu bundle ID mana yang masih ada. Jika menghapus dengan menebak nama, Anda berisiko menghapus resource yang salah.

Gunakan aturan concurrency berdasarkan nomor pull request. Saat event close dan rebuild datang hampir bersamaan, job cleanup lama tidak boleh beradu dengan deployment baru. Batalkan run cleanup yang sudah usang atau buat job menunggu sampai deployment lock selesai.

Workflow CLI satu perintah dari Capgo dapat mengurangi jumlah shell call kustom pada proses build dan release. Untuk nama perintah dan operasi yang didukung, cek dokumentasi perintah CLI Capgo. Gunakan CLI untuk perintah yang sudah terverifikasi. Gunakan SDK atau API publik jika aksi cleanup memerlukan request langsung.

Jangan masukkan cleanup ke dalam workflow yang berjalan setiap kali push. Job push bisa menghapus preview yang masih dalam tahap testing. Event close adalah trigger yang tepat untuk cleanup normal. Tambahkan manual workflow dispatch untuk pemulihan jika job gagal.

Atur juga fallback retensi. Jika event close terlewat, scheduled job dapat menemukan preview yang lebih lama dari jendela pengujian yang diizinkan tim Anda. Job tersebut memerlukan pengamanan lebih ketat daripada hook close biasa. Job ini hanya boleh memilih preview dengan owner yang jelas dan timestamp yang sudah kedaluwarsa.

Untuk GitHub Actions, batasi izin dan hanya teruskan nilai yang dibutuhkan langkah cleanup. Dokumentasi integrasi GitHub Actions milik Capgo saat ini menjelaskan di mana token disimpan dan bagaimana workflow terhubung ke Capgo.

Sekarang Anda seharusnya sudah punya alur otomatis yang bereaksi terhadap closure, menunggu job yang bersaing, mereset status aktif, mendaftar ID, dan hanya menghapus bundle yang cocok. Ini cukup cepat untuk development harian tanpa membuat cleanup membabi buta.

Langkah 6: Verifikasi Cleanup dan Lindungi Rollout dari Penghapusan Tidak Sengaja

Verifikasi menutup loop cleanup preview pull request Capgo. Respons delete saja tidak cukup untuk proses rilis yang aman.

Setelah job cleanup berjalan, cek lagi preview channel. Pastikan channel tersebut tidak lagi muncul sebagai preview aktif. Lalu cek daftar bundle untuk app dan filter yang sama. Hasil yang diharapkan: bundle ID yang ditargetkan sudah hilang, sementara bundle produksi tetap ada.

Simpan nilai-nilai ini di job summary:

• Repository dan nomor pull request.
• Nama preview channel.
• Commit SHA yang digunakan untuk pengecekan ownership.
• Bundle ID yang ditemukan.
• Bundle ID yang dihapus.
• Semua ID yang mengembalikan error.

Gunakan status yang jelas. “Cleaned” berarti semua target terverifikasi sudah dihapus. “Already clean” berarti resource sudah tidak ada sebelum proses 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 bersifat fail closed. Jika script tidak bisa mengidentifikasi target dengan yakin, proses harus berhenti.

Pisahkan rollback dari cleanup. Rollback mengubah bundle yang diterima perangkat. Cleanup menghapus resource preview lama. Jika pengujian menemukan bug setelah pull request ditutup, Anda mungkin butuh bundle tersebut untuk investigasi. Atur retention window yang singkat daripada langsung menghapus saat event tiba jika tim Anda sering melakukan debug setelah merge.

Perhatikan tiga pola kegagalan umum:

• Error preview aktif: reset atau pindah dulu sebelum mencoba Delete Preview lagi.
• Bundle ID hilang: jalankan aksi list lagi daripada menebak-nebak.
• Error izin (permission): review scope key, lalu buat key baru jika diperlukan.

Rotasi cleanup key sesuai jadwal kebijakan keamanan Anda, dan segera rotasi jika muncul di log atau commit. Key baru harus dites sebelum key lama dicabut, kecuali jika kebocoran mengharuskan pencabutan segera.

Celah dokumentasi seputar cleanup layak dicatat di tinjauan keamanan Anda. Jadikan panduan SDK dan Capgo yang terverifikasi sebagai acuan implementasi, dan simpan request contract Anda sendiri di version control.

Poin Penting: Verifikasi daftar preview dan bundle setelah penghapusan, blokir target produksi di code, dan laporkan cleanup parsial sebagai kegagalan.

Satu perintah hanya berguna kalau guardrails-nya jelas. Pantau preview. Pakai nama channel yang mudah diprediksi. Roll back perubahan rilis secara terpisah. Lalu biarkan job cleanup menjalankan tugas kecilnya tanpa menyentuh live traffic.

FAQ

Bisakah saya menghapus preview pull request Capgo yang sedang aktif?

Tidak bisa. Preview yang aktif harus dialihkan dulu, atau Anda harus memanggilresetPreview. Setelah status aktifnya hilang, jalankan Delete Preview. Aturan ini adalah detail utama yang perlu diingat saat mengatur API key untuk cleanup pull request preview Capgo di CI.

Apakah saya perlu bundle ID untuk cleanup preview Capgo?

Ya. Aksi Delete Bundle di Capgo membutuhkan bundle ID, jadi lihat daftar bundle yang tersedia sebelum menghapusnya. Cocokkan setiap ID dengan preview channel dan commit sebelum mengirim request delete. Jangan pernah menyusun ID dari nama branch atau berasumsi bahwa menghapus preview juga menghapus semua bundle.

Jenis API key seperti apa yang sebaiknya dipakai CI untuk preview cleanup?

Gunakan App Preview key yang terbatas untuk cleanup preview, simpan di encrypted secret store penyedia CI Anda. Batasi key hanya untuk app atau scope yang diperlukan. Pisahkan dari key yang digunakan untuk publish production updates. Ini membuat job cleanup Capgo lebih mudah direview dan lebih aman saat rotasi.

Bisakah saya mengotomatiskan cleanup saat pull request ditutup?

Bisa. Trigger cleanup dari event closed pull request, lalu tunggu deployment job yang aktif sebelum me-reset preview. List bundle ID, hapus yang cocok, dan konfirmasi hasilnya. Tambahkan concurrency control agar build yang terlambat tidak bentrok dengan job cleanup.

Mengapa request cleanup Capgo saya gagal?

Penyebab umumnya adalah preview yang masih aktif, bundle ID tidak ditemukan, atau key tanpa scope yang dibutuhkan. Reset preview terlebih dahulu, ulangi pemanggilan list, dan periksa izin key. Karena detail request bisa berbeda tergantung versi API atau SDK, pastikan method dan parameter terbaru sebelum mengubah script.

Kesimpulan

Gunakan Capgo dengan preview key khusus dan urutan cleanup yang ketat: reset preview yang aktif, list bundle ID-nya, hapus bundle yang terverifikasi, lalu hapus preview-nya. Mulai dengan dry run pada satu closed pull request, konfirmasi format request di SDK saat ini, dan tambahkan guard production-channel sebelum mengaktifkan automatic cleanup.