Validasi rilis penuh

Full Release Validation adalah payung rilis: satu-satunya titik masuk manual untuk pembuktian prarilis. Sebagian besar pekerjaan berlangsung dalam alur kerja turunan sehingga lingkungan yang gagal dapat dijalankan ulang tanpa memulai ulang seluruh rilis.

Jalankan dari referensi alur kerja tepercaya, biasanya main, dan berikan cabang rilis, tag, atau SHA commit lengkap sebagai ref:

gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=stable

provider juga menerima anthropic atau minimax untuk onboarding lintas OS dan putaran agen menyeluruh. Pekerjaan turunan yang dapat digunakan kembali menentukan harness alur kerja yang dipanggil dari job.workflow_repository dan job.workflow_sha, sedangkan input ref memilih kandidat yang diuji. Dengan demikian, logika validasi tepercaya terkini tetap tersedia saat memvalidasi cabang atau tag rilis yang lebih lama.

Setiap turunan yang dikirim harus melaporkan SHA alur kerja yang sama dengan proses induk Full Release Validation. Jika main berubah di antara pengiriman induk dan turunan, payung akan gagal secara tertutup meskipun turunan itu sendiri berhasil. Untuk pembuktian commit persis yang tidak dapat diubah, gunakan pnpm ci:full-release --sha <target-sha>. Pembantu tersebut membuat referensi release-ci/* sementara yang disematkan ke origin/main tepercaya saat ini, hanya meneruskan SHA target sebagai kandidat ref, menggunakan kembali bukti target persis yang ketat jika tersedia, dan menghapus referensi setelah validasi. Berikan -f reuse_evidence=false untuk memaksa proses baru atau --workflow-sha <trusted-main-sha> untuk memilih commit alur kerja lama yang masih dapat dijangkau dari origin/main saat ini. Alur kerja tidak pernah membuat atau memperbarui referensi repositori itu sendiri.

release_profile=stable dan release_profile=full selalu menjalankan uji ketahanan langsung/Docker yang menyeluruh. Berikan run_release_soak=true untuk menyertakan jalur uji ketahanan yang sama dengan profil beta. Publikasi stabil menolak manifes validasi tanpa uji ketahanan ini dan bukti performa produk yang bersifat memblokir.

Package Acceptance biasanya membangun tarball kandidat dari ref yang telah ditentukan, termasuk proses SHA lengkap yang dikirim dengan pnpm ci:full-release. Setelah publikasi beta, berikan release_package_spec=openclaw@YYYY.M.PATCH-beta.N untuk menggunakan kembali paket npm yang telah dirilis dalam pemeriksaan rilis, Package Acceptance, lintas OS, Docker jalur rilis, dan Telegram paket. Gunakan package_acceptance_package_spec hanya ketika Package Acceptance memang dimaksudkan untuk membuktikan paket yang berbeda. Jalur paket langsung Plugin Codex mengikuti keadaan yang sama: nilai release_package_spec yang telah dipublikasikan menghasilkan codex_plugin_spec=npm:@openclaw/codex@<version>; proses SHA/artefak mengemas extensions/codex dari referensi yang dipilih; dan operator dapat menetapkan codex_plugin_spec secara langsung untuk sumber Plugin npm:, npm-pack:, atau git:. Jalur tersebut memberikan persetujuan instalasi CLI Codex secara eksplisit yang diwajibkan oleh Plugin tersebut, lalu menjalankan prapemeriksaan CLI Codex dan putaran agen OpenAI dalam sesi yang sama.

Tahapan tingkat atas

Untuk rerun_group=all, pekerjaan Check for reusable validation evidence berjalan lebih dahulu: pekerjaan ini mencari validasi penuh berhasil sebelumnya yang terbaru untuk SHA target, profil rilis, pengaturan uji ketahanan efektif, dan input validasi yang persis sama. Jika bukti tersebut tersedia, setiap jalur dilewati dan verifikator payung memeriksa ulang artefak induk yang tidak dapat diubah, proses turunan, dan log pengiriman. Ini hanya untuk pemulihan proses ulang kandidat yang sama; hal ini tidak mengizinkan penggunaan kembali lintas SHA. Untuk kandidat yang berubah, jalankan ulang setiap gerbang paket, artefak, instalasi, Docker, atau penyedia yang terpengaruh oleh perubahan tersebut. Berikan reuse_evidence=false untuk memaksa proses penuh yang baru. Penggunaan kembali bukti hanya berjalan dari main atau referensi kanonis release-ci/* yang disematkan ke SHA dan commit alur kerjanya tetap berada dalam garis keturunan main tepercaya; referensi alur kerja lainnya menjalankan jalur yang dipilih secara baru.

Juga untuk rerun_group=all, pekerjaan Verify Docker runtime image assets membangun target Docker runtime-assets dengan OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Pekerjaan ini berjalan paralel dengan tahapan lain dan diberlakukan oleh verifikator payung; jalur tidak lagi menunggunya sebelum dikirim. rerun_group yang lebih sempit melewati prapemeriksaan ini.

Payung selalu mengirim performa produk dalam mode khusus artefak. OpenClaw Performance mengizinkan publikasi laporan hanya untuk proses terjadwal atau pengiriman manual yang secara eksplisit menetapkan publish_reports=true. Pelindung khusus artefak harus diselesaikan dengan berhasil, yang membuktikan pekerjaan penerbit tetap dilewati. Bukti baru dan yang digunakan kembali mencatat controls.performanceReportPublication=artifact-only; verifikator dan pemilih penggunaan kembali menolak bukti tanpa pembuktian turunan performa ternormalisasi yang sesuai.

Verifikator mengunggah manifes kanonis sebagai full-release-validation-<run-id>-<run-attempt>. Peralatan bukti memvalidasi ID artefak, digest, proses penghasil, dan percobaannya sebelum mengunduh ID artefak yang persis tersebut. Peralatan ini membatasi ukuran ZIP yang diunduh, memverifikasi byte-nya terhadap digest REST sha256:, dan mengalirkan satu-satunya entri manifes terbatas yang diizinkan tanpa mengekstrak arsip. Alias bernama stabil tetap tersedia sementara untuk konsumen publikasi lama. Verifikator selalu mengutamakan artefak yang memenuhi syarat percobaan; sebagai transisi, verifikator menerima nama stabil hanya untuk penghasil manifes v2 pada percobaan pertama. Verifikator menolak nama lama tersebut untuk percobaan selanjutnya dan manifes v3.

Untuk ref=main dengan rerun_group=all, untuk referensi release/*, dan untuk referensi alfa Tideclaw, proses payung yang lebih baru menggantikan proses lama dengan referensi dan grup proses ulang yang sama. Ketika induk dibatalkan, pemantaunya membatalkan setiap alur kerja turunan yang telah dikirim. Proses validasi tag dan SHA yang disematkan tidak saling membatalkan.

Tahapan pemeriksaan rilis

OpenClaw Release Checks adalah alur kerja turunan terbesar. Alur kerja ini menentukan target satu kali dan menyiapkan artefak release-package-under-test bersama ketika tahapan yang berkaitan dengan paket atau Docker membutuhkannya.

Bagian jalur rilis Docker

Tahap jalur rilis Docker menjalankan bagian-bagian ini ketika live_suite_filter kosong:

Gunakan docker_lanes=<lane[,lane]> yang ditargetkan pada alur kerja langsung/E2E yang dapat digunakan kembali ketika hanya satu jalur Docker yang gagal. Artefak rilis menyertakan perintah pengulangan per jalur dengan input penggunaan ulang artefak paket dan citra jika tersedia.

Profil rilis

release_profile terutama mengontrol cakupan live/penyedia di dalam pemeriksaan rilis. Ini tidak menghapus CI penuh normal, Prarilis Plugin, smoke instalasi, penerimaan paket, atau QA Lab. Profil stable dan full selalu menjalankan cakupan menyeluruh E2E repo/live dan soak jalur rilis Docker. Profil beta dapat mengaktifkannya dengan run_release_soak=true. Penerimaan Paket menyediakan E2E Telegram paket kanonis untuk setiap kandidat penuh, sehingga alur payung tidak menduplikasi poller live tersebut.

Penambahan khusus full

Suite berikut dilewati oleh stable dan disertakan oleh full:

stable menyertakan native-live-src-gateway-profiles-anthropic-smoke dan native-live-src-gateway-profiles-opencode-go-smoke; full sebagai gantinya menggunakan shard model Anthropic dan OpenCode Go yang lebih luas. Pengulangan terfokus tetap dapat menggunakan handle agregat native-live-src-gateway-profiles-anthropic atau native-live-src-gateway-profiles-opencode-go.

Pengulangan terfokus

Gunakan rerun_group untuk menghindari pengulangan kotak rilis yang tidak terkait:

Gunakan live_suite_filter dengan rerun_group=live-e2e ketika satu suite live gagal. ID filter yang valid ditentukan dalam alur kerja live/E2E yang dapat digunakan kembali, termasuk docker-live-models, live-gateway-docker, live-gateway-anthropic-docker, live-gateway-google-docker, live-gateway-minimax-docker, live-gateway-advisory-docker, live-cli-backend-docker, live-acp-bind-docker, dan live-codex-harness-docker.

Handle live-gateway-advisory-docker adalah handle pengulangan agregat untuk ketiga shard penyedianya, sehingga tetap menyebar ke semua tugas gateway Docker advisori.

Gunakan cross_os_suite_filter dengan rerun_group=cross-os ketika satu jalur lintas OS gagal. Filter menerima ID OS, ID suite, atau pasangan OS/suite, misalnya windows/packaged-upgrade, windows, atau packaged-fresh. Ringkasan lintas OS menyertakan waktu per fase untuk jalur peningkatan paket, dan perintah yang berjalan lama mencetak baris Heartbeat agar pembaruan yang macet terlihat sebelum batas waktu tugas.

Kegagalan pemeriksaan rilis QA memblokir validasi rilis normal. Pemeriksaan cakupan alat runtime QA (pergeseran alat dinamis antara openclaw dan codex pada tingkat standar) juga memblokir pemverifikasi pemeriksaan rilis meskipun jalur paritas runtime QA yang mendasarinya bersifat advisori. Proses alpha Tideclaw tetap dapat memperlakukan jalur pemeriksaan rilis yang bukan terkait keamanan paket sebagai advisori. Dengan release_profile=beta, suite penyedia live Run repo/live E2E validation bersifat advisori: deployment model pihak ketiga berubah di bawah sebuah rilis, sehingga beta menampilkan kegagalannya sebagai peringatan, sementara profil stable dan full tetap menjadikannya pemblokir. Ketika live_suite_filter secara eksplisit meminta jalur live QA berpagar seperti Discord, WhatsApp, atau Slack, variabel repo OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED yang sesuai harus diaktifkan; jika tidak, pengambilan input akan gagal alih-alih melewati jalur secara diam-diam. Ulangi rerun_group=qa, qa-parity, atau qa-live ketika Anda memerlukan bukti QA terbaru.

Bukti yang perlu disimpan

Simpan ringkasan Full Release Validation sebagai indeks tingkat rilis. Ringkasan ini menautkan ID proses anak dan menyertakan tabel tugas paling lambat. Untuk kegagalan, periksa alur kerja anak terlebih dahulu, lalu ulangi handle terkecil yang sesuai di atas.

Artefak yang berguna:

• release-package-under-test dari OpenClaw Release Checks
• Artefak jalur rilis Docker di bawah .artifacts/docker-tests/
• package-under-test Penerimaan Paket dan artefak penerimaan Docker
• Artefak pemeriksaan rilis lintas OS untuk setiap OS dan suite
• Artefak paritas QA, paritas runtime, Matrix, dan Telegram

Berkas alur kerja

• .github/workflows/full-release-validation.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-live-and-e2e-checks-reusable.yml
• .github/workflows/plugin-prerelease.yml
• .github/workflows/install-smoke.yml
• .github/workflows/install-smoke-reusable.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-performance.yml
• .github/workflows/npm-telegram-beta-e2e.yml