Validación completa de la versión

Full Release Validation es el flujo general de validación del producto para la versión. La mayor parte del trabajo se realiza en flujos secundarios, de modo que una máquina con errores pueda volver a ejecutarse sin reiniciar toda la versión.

Inmovilice el commit anterior al registro de cambios que contiene el producto completo como Code SHA y, a continuación, ejecute:

pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH

provider también acepta anthropic o minimax para la incorporación entre distintos sistemas operativos y el turno integral del agente. El asistente infiere el perfil beta a partir de versiones de paquetes alfa/beta y stable en caso contrario. Pase entradas alternativas del flujo de trabajo con -f key=value; use -f release_profile=full únicamente para el análisis general de avisos.

El asistente crea una referencia temporal release-ci/* fijada a un único SHA de flujo de trabajo origin/main de confianza, pasa el SHA de destino únicamente como ref candidato y elimina la referencia temporal después de la validación. Cada flujo secundario ejecutado debe informar del mismo SHA de flujo de trabajo. Pase -f reuse_evidence=false para forzar una ejecución nueva o --workflow-sha <trusted-main-sha> para seleccionar un commit anterior del flujo de trabajo que todavía sea accesible desde el origin/main actual. El flujo de trabajo nunca crea ni actualiza por sí mismo las referencias del repositorio.

Cuando el Code SHA esté en verde, genere y confirme únicamente CHANGELOG.md. Este nuevo commit es el Release SHA. Ejecute el mismo asistente para el Release SHA. La evidencia del producto solo se reutiliza cuando GitHub demuestra que el Release SHA desciende del Code SHA y que el conjunto completo de rutas modificadas es exactamente CHANGELOG.md; la comprobación preliminar de npm y la aceptación del paquete o de la instalación siguen ejecutándose en el Release SHA.

release_profile=stable y release_profile=full siempre ejecutan la prueba prolongada exhaustiva en vivo/Docker. Pase run_release_soak=true para incluir las mismas vías de prueba prolongada con el perfil beta. La publicación estable rechaza un manifiesto de validación sin esta prueba prolongada y sin evidencia bloqueante de rendimiento del producto.

Package Acceptance normalmente compila el tarball candidato desde el ref resuelto, incluidas las ejecuciones con SHA completo iniciadas con pnpm ci:full-release. Después de una publicación beta, pase release_package_spec=openclaw@YYYY.M.PATCH-beta.N para reutilizar el paquete de npm publicado en las comprobaciones de versión, Package Acceptance, las pruebas entre sistemas operativos, Docker en la ruta de publicación y Telegram con el paquete. Use package_acceptance_package_spec únicamente cuando Package Acceptance deba comprobar intencionadamente un paquete diferente. La vía de paquete en vivo del plugin de Codex sigue el mismo estado: los valores release_package_spec publicados derivan codex_plugin_spec=npm:@openclaw/codex@<version>; las ejecuciones con SHA/artefacto empaquetan extensions/codex desde la referencia seleccionada; y los operadores pueden establecer codex_plugin_spec directamente para fuentes del plugin npm:, npm-pack: o git:. La vía concede la aprobación explícita de instalación de Codex CLI que exige ese plugin y, a continuación, ejecuta la comprobación preliminar de Codex CLI y turnos del agente de OpenAI en la misma sesión.

Etapas de nivel superior

Para rerun_group=all, primero se ejecuta un trabajo Check for reusable validation evidence. Busca la validación completa correcta anterior más reciente con el mismo perfil de versión, la misma configuración efectiva de prueba prolongada y las mismas entradas de validación. Las repeticiones del destino exacto usan exact-target-full-validation-v1. Un descendiente cuya diferencia completa sea exactamente CHANGELOG.md usa changelog-only-release-v1; se omiten todas las vías del producto y el verificador vuelve a comprobar de forma independiente la comparación de commits de GitHub, el artefacto principal inmutable, las ejecuciones secundarias y los registros de inicio. Cualquier otro cambio de destino exige una validación nueva del Code SHA. Pase reuse_evidence=false para forzar una ejecución completa nueva. La reutilización de evidencia solo se ejecuta desde main o desde una referencia release-ci/* canónica fijada mediante SHA cuyo commit del flujo de trabajo permanezca en el linaje main de confianza; las demás referencias del flujo de trabajo ejecutan de nuevo las vías seleccionadas.

También para rerun_group=all, un trabajo Verify Docker runtime image assets compila el destino de Docker runtime-assets con OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Se ejecuta en paralelo con las demás etapas y el verificador general exige su cumplimiento; las vías ya no esperan a que termine antes de iniciarse. Un rerun_group más limitado omite esta comprobación preliminar.

El flujo general siempre inicia el rendimiento del producto en modo de solo artefactos. OpenClaw Performance permite publicar informes únicamente para ejecuciones programadas o para un inicio manual que establezca explícitamente publish_reports=true. La protección del modo de solo artefactos debe completarse correctamente, lo que demuestra que el trabajo del publicador permaneció omitido. Las evidencias nuevas y reutilizadas registran controls.performanceReportPublication=artifact-only; el verificador y el selector de reutilización rechazan las evidencias sin la prueba normalizada correspondiente del flujo secundario de rendimiento.

El verificador carga el manifiesto canónico como full-release-validation-<run-id>-<run-attempt>. Las herramientas de evidencia validan su ID de artefacto, resumen, ejecución productora e intento antes de descargar ese ID de artefacto exacto. Limitan el ZIP descargado, verifican sus bytes mediante el resumen sha256: de REST y transmiten la única entrada acotada permitida del manifiesto sin extraer el archivo. Se conserva temporalmente un alias de nombre estable para consumidores de publicación anteriores. El verificador siempre prefiere el artefacto cuyo nombre incluye el intento; como transición, acepta el nombre estable únicamente para un productor del manifiesto v2 en el intento 1. Rechaza ese nombre heredado para intentos posteriores y para el manifiesto v3.

Para ref=main con rerun_group=all, para referencias release/* y para referencias alfa de Tideclaw, una ejecución más reciente del flujo general sustituye a una anterior con la misma referencia y el mismo grupo de repetición. Cuando se cancela el flujo principal, su monitor cancela todos los flujos de trabajo secundarios que ya haya iniciado. Las ejecuciones de validación de etiquetas y SHA fijados no se cancelan entre sí.

Etapas de las comprobaciones de la versión

OpenClaw Release Checks es el flujo de trabajo secundario más grande. Resuelve el destino una vez y prepara un artefacto release-package-under-test compartido cuando lo necesitan las etapas orientadas a paquetes o Docker.

Bloques de la ruta de lanzamiento de Docker

La etapa de la ruta de lanzamiento de Docker ejecuta estos bloques cuando live_suite_filter está vacío:

Utilice docker_lanes=<lane[,lane]> de forma específica en el flujo de trabajo reutilizable en vivo/E2E cuando solo haya fallado un carril de Docker. Los artefactos de lanzamiento incluyen comandos de repetición por carril con entradas para reutilizar el artefacto de paquete y la imagen cuando estén disponibles.

Perfiles de lanzamiento

release_profile controla principalmente la amplitud de las pruebas en vivo y de proveedores dentro de las comprobaciones de lanzamiento. No elimina la CI completa normal, la versión preliminar de plugins, la prueba rápida de instalación, la aceptación de paquetes ni QA Lab. Los perfiles estable y completo siempre ejecutan una cobertura exhaustiva E2E del repositorio/en vivo y de pruebas prolongadas de la ruta de lanzamiento de Docker. El perfil beta puede incluirla mediante run_release_soak=true. La aceptación de paquetes proporciona el E2E canónico de paquetes de Telegram para cada candidato completo, por lo que el flujo general no duplica ese sondeador en vivo.

Incorporaciones exclusivas del perfil completo

Estas suites se omiten con stable y se incluyen con full:

stable incluye native-live-src-gateway-profiles-anthropic-smoke y native-live-src-gateway-profiles-opencode-go-smoke; en su lugar, full usa los fragmentos más amplios de modelos de Anthropic y OpenCode Go. Las repeticiones específicas aún pueden usar los identificadores agregados native-live-src-gateway-profiles-anthropic o native-live-src-gateway-profiles-opencode-go.

Repeticiones específicas

Use rerun_group para evitar repetir entornos de versión no relacionados:

Use live_suite_filter con rerun_group=live-e2e cuando falle una suite en vivo. Los identificadores de filtro válidos se definen en el flujo de trabajo reutilizable en vivo/E2E, incluidos 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 y live-codex-harness-docker.

El identificador live-gateway-advisory-docker es un identificador de repetición agregado para sus tres fragmentos de proveedores, por lo que sigue distribuyéndose a todos los trabajos consultivos del Gateway de Docker.

Use cross_os_suite_filter con rerun_group=cross-os cuando falle una vía entre sistemas operativos. El filtro acepta un identificador de SO, un identificador de suite o un par SO/suite; por ejemplo, windows/packaged-upgrade, windows o packaged-fresh. Los resúmenes entre sistemas operativos incluyen tiempos por fase para las vías de actualización con paquetes, y los comandos de larga duración imprimen líneas de Heartbeat para que una actualización bloqueada sea visible antes de que se agote el tiempo de espera del trabajo.

Los fallos en las comprobaciones de versión de QA bloquean la validación normal de la versión. La comprobación de cobertura de herramientas del entorno de ejecución de QA (desviación dinámica de herramientas entre openclaw y codex en el nivel estándar) también bloquea el verificador de comprobaciones de versión, aunque la vía subyacente de paridad del entorno de ejecución de QA sea consultiva. Las ejecuciones alfa de Tideclaw aún pueden tratar como consultivas las vías de comprobaciones de versión no relacionadas con la seguridad de los paquetes. Con release_profile=beta, las suites de proveedores en vivo Run repo/live E2E validation son consultivas: las implementaciones de modelos de terceros cambian durante una versión, por lo que el perfil beta presenta sus fallos como advertencias, mientras que los perfiles estable y completo los mantienen como bloqueantes. Cuando live_suite_filter solicita explícitamente una vía restringida de QA en vivo, como Discord, WhatsApp o Slack, debe estar habilitada la variable de repositorio OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED correspondiente; de lo contrario, la captura de entrada falla en lugar de omitir silenciosamente la vía. Vuelva a ejecutar rerun_group=qa, qa-parity o qa-live cuando necesite evidencia de QA reciente.

Evidencia que se debe conservar

Conserve el resumen Full Release Validation como índice de la versión. Este enlaza los identificadores de las ejecuciones secundarias e incluye tablas de los trabajos más lentos. En caso de fallos, inspeccione primero el flujo de trabajo secundario y, después, vuelva a ejecutar el identificador coincidente más específico de los anteriores.

Registre tanto el SHA del código como el SHA de la versión, la política de reutilización y el conjunto de rutas modificadas, la ejecución principal correcta del SHA del código y la ejecución principal ligera del SHA de la versión.

Artefactos útiles:

• release-package-under-test de OpenClaw Release Checks
• Artefactos de la ruta de versión de Docker en .artifacts/docker-tests/
• package-under-test de aceptación de paquetes y artefactos de aceptación de Docker
• Artefactos de comprobación de versión entre sistemas operativos para cada SO y suite
• Artefactos de paridad de QA, paridad del entorno de ejecución, Matrix y Telegram

Archivos de flujo de trabajo

• .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