Validación completa de la versión

Full Release Validation es el marco general de validación del producto para la versión. La mayor parte del trabajo se realiza en flujos de trabajo secundarios para que se pueda volver a ejecutar una máquina con errores sin reiniciar toda la versión. Ejecute la preparación de la versión antes de fijar el SHA del código; esta actualiza la salida de configuración regional de la interfaz de control cuando el bot en segundo plano aún no la ha incorporado y, a continuación, aplica la misma comprobación estricta de cero mecanismos de respaldo utilizada por el Pipeline de CI de la versión.

Fije la confirmación previa al registro de cambios con el producto completo como SHA del código 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 sistemas operativos y el turno integral del agente. El asistente infiere el perfil beta a partir de las versiones alfa/beta del paquete y stable en caso contrario. Pase entradas alternativas del flujo de trabajo con -f key=value; use -f release_profile=full únicamente para la revisión exhaustiva de avisos.

El asistente crea una referencia release-ci/* temporal 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 iniciado 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 una confirmación anterior del flujo de trabajo que aún sea accesible desde el origin/main actual. El flujo de trabajo nunca crea ni actualiza por sí mismo las referencias del repositorio.

Excepción para la versión estable ampliada

La publicación estable ampliada requiere una ejecución en la que tanto el flujo de trabajo como el destino sean la rama canónica:

gh workflow run full-release-validation.yml \  --ref extended-stable/YYYY.M.33 \  -f ref=extended-stable/YYYY.M.33 \  -f release_profile=stable

No use pnpm ci:full-release ni release-ci/*. La publicación vincula la rama, el SHA de cabecera/destino, el workflowRef del manifiesto, el ID y el intento de la ejecución con la rama canónica y la confirmación de la versión.

Aplique retroportaciones a los fallos del producto; realice la reparación más pequeña que preserve el comportamiento para las herramientas del destino fijado; vuelva a intentar los fallos del proveedor, de aprobación o del ejecutor sin cambiar el código fuente. Cualquier cambio de rama requiere una ejecución nueva completa. No omita comportamientos obligatorios del paquete, instalador, actualización, canal o entorno real porque el destino sea antiguo.

Para una versión normal, cuando el SHA del código esté en verde, genere y confirme únicamente CHANGELOG.md. Esta nueva confirmación es el SHA de la versión. Ejecute el mismo asistente para el SHA de la versión. Las pruebas del producto solo se reutilizan cuando GitHub demuestra que el SHA de la versión desciende del SHA del código y que el conjunto completo de rutas modificadas es exactamente CHANGELOG.md; la comprobación preliminar de npm y la aceptación del paquete/instalación siguen ejecutándose en el SHA de la versión.

release_profile=stable y release_profile=full siempre ejecutan la prueba exhaustiva prolongada en entorno real/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 que no contenga esta prueba prolongada ni pruebas bloqueantes del rendimiento del producto.

La aceptación del paquete normalmente compila el archivo tar candidato a partir de la ref resuelta, incluidas las ejecuciones con SHA completo iniciadas mediante 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 npm publicado en las comprobaciones de la versión, la aceptación del paquete, las pruebas entre sistemas operativos, la ruta de versión de Docker y el paquete de Telegram. Use package_acceptance_package_spec únicamente cuando la aceptación del paquete deba demostrar intencionadamente un paquete diferente. La vía del paquete en entorno real del Plugin de Codex sigue el mismo estado: los valores release_package_spec publicados derivan codex_plugin_spec=npm:@openclaw/codex@<version>; las ejecuciones de 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 la CLI de Codex requerida por ese Plugin y, a continuación, ejecuta la comprobación preliminar de la CLI de Codex y turnos del agente de OpenAI en la misma sesión. Su turno final sin reintentos y con razonamiento medio envía progreso visible con final de Codex omitido, lee entradas aleatorias del espacio de trabajo, escribe su artefacto exacto y envía una finalización explícita. Esto detecta la regresión de v2026.7.1 en la que un envío normal de progreso finalizaba el turno.

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 cuyo delta completo 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 confirmaciones de GitHub, el artefacto principal inmutable, las ejecuciones secundarias y los registros de inicio. Cualquier otro cambio en el destino requiere una validación nueva del SHA del código. Pase reuse_evidence=false para forzar una ejecución completa nueva. La reutilización de pruebas solo se ejecuta desde main o una referencia release-ci/* canónica fijada a un SHA cuya confirmación del flujo de trabajo permanezca en el linaje de confianza main; otras referencias del flujo de trabajo ejecutan desde cero las vías seleccionadas.

La validación nueva orientada a paquetes prepara un archivo tar inmutable y un artefacto de imagen Docker antes de iniciar la versión preliminar de plugins y las comprobaciones de versión de OpenClaw. Ambos flujos secundarios verifican el mismo SHA del paquete, los ID de artefactos, los resúmenes de servicio, el intento de ejecución del productor y el resumen del archivo de Docker antes de usarlos. La capa básica de Docker, independiente del paquete, utiliza una caché GHCR direccionada por contenido; las imágenes específicas del candidato siguen siendo artefactos inmutables de GitHub. Las ejecuciones específicas con una especificación explícita de paquete publicado conservan en su lugar la ruta del paquete existente.

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 que se complete; las vías ya no esperan a que termine antes de iniciarse. Un rerun_group más limitado omite esta comprobación preliminar.

El marco general siempre inicia el rendimiento del producto en modo de solo artefactos. OpenClaw Performance permite publicar informes únicamente en ejecuciones programadas o en un inicio manual que establezca explícitamente publish_reports=true. La protección de solo artefactos debe completarse correctamente, lo que demuestra que el trabajo del publicador permaneció omitido. Las pruebas nuevas y reutilizadas registran controls.performanceReportPublication=artifact-only; el verificador y el selector de reutilización rechazan las pruebas que no contengan la demostración 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 el ID del artefacto, el resumen, la ejecución productora y el intento antes de descargar ese ID de artefacto exacto. Limitan el ZIP descargado, verifican sus bytes con respecto al resumen sha256: de REST y transmiten la única entrada de manifiesto acotada permitida sin extraer el archivo. Se mantiene temporalmente un alias de nombre estable para los consumidores de publicación más antiguos. El verificador siempre prefiere el artefacto calificado por intento; como transición, acepta el nombre estable únicamente para un productor de manifiesto v2 del 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 general más reciente sustituye a una anterior con la misma referencia y el mismo grupo de reejecución. Cuando se cancela la ejecución principal, su monitor cancela cualquier flujo de trabajo secundario que ya haya lanzado. 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 objetivo una vez y valida el artefacto de paquete compartido de la ejecución general cuando está disponible. Un lanzamiento directo o específico prepara su propio artefacto release-package-under-test cuando lo necesitan las etapas relacionadas con paquetes o Docker.

Fragmentos de la ruta de lanzamiento de Docker

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

Use 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 del lanzamiento incluyen comandos de reejecución por carril con entradas para reutilizar el artefacto del paquete y la imagen cuando estén disponibles.

Perfiles de lanzamiento

release_profile controla principalmente la amplitud de las pruebas en vivo/de proveedores dentro de las comprobaciones de lanzamiento. No elimina la CI completa normal, la versión preliminar de Plugins, las pruebas de humo 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 habilitarla con run_release_soak=true. La aceptación de paquetes proporciona la prueba E2E canónica del paquete en Telegram para cada candidato completo, por lo que el flujo general no duplica ese sondeador en vivo.

Adiciones exclusivas del perfil completo

stable omite estas suites y full las incluye:

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

Reejecuciones específicas

Use rerun_group para evitar repetir entornos de lanzamiento 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.

Para una reejecución específica de un transporte de QA, establezca rerun_group=qa-live y use el selector canónico qa-live-matrix, qa-live-telegram, qa-live-discord, qa-live-whatsapp o qa-live-slack.

El identificador live-gateway-advisory-docker es un identificador agregado de reejecución 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 un carril entre sistemas operativos. El filtro acepta un identificador de sistema operativo, un identificador de suite o un par sistema operativo/suite, por ejemplo, windows/packaged-upgrade, windows o packaged-fresh. Los resúmenes entre sistemas operativos incluyen tiempos por fase para los carriles de actualización de paquetes, y los comandos de larga duración imprimen líneas de Heartbeat para que una actualización bloqueada sea visible antes del tiempo de espera del trabajo.

Los fallos de las comprobaciones de lanzamiento de QA bloquean la validación normal del lanzamiento solo para los carriles seleccionados de cobertura de herramientas de Matrix, Telegram y el entorno de ejecución de QA. La paridad de QA, la paridad del entorno de ejecución y los carriles condicionados en vivo de Discord, WhatsApp y Slack son consultivos y publican artefactos de estado sin bloquear el verificador del lanzamiento. Las ejecuciones alfa de Tideclaw aún pueden tratar como consultivos los carriles de comprobación del lanzamiento que no afectan a 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 un lanzamiento, por lo que beta presenta sus fallos como advertencias, mientras que los perfiles estable y completo los mantienen como bloqueantes. Cuando live_suite_filter solicita explícitamente un carril de QA en vivo condicionado, como Discord, WhatsApp o Slack, debe habilitarse la variable de repositorio OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED correspondiente; de lo contrario, la captura de entradas falla en lugar de omitir el carril silenciosamente. Vuelva a ejecutar rerun_group=qa, qa-parity o qa-live cuando se necesite evidencia de QA actualizada.

Evidencia que se debe conservar

Conserve el resumen Full Release Validation como índice del lanzamiento. Incluye enlaces a los identificadores de las ejecuciones secundarias y 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 correspondiente más específico de los anteriores.

Para un lanzamiento normal, registre tanto el SHA del código como el SHA del lanzamiento, 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 del lanzamiento. Para extended-stable, registre la rama canónica, el SHA exacto del lanzamiento, el identificador y el intento de la nueva ejecución principal, la referencia del flujo de trabajo, cada ejecución secundaria y cualquier reparación de compatibilidad del destino congelado u omisión intencionada.

Artefactos útiles:

• release-package-under-test de OpenClaw Release Checks
• Artefactos de la ruta de lanzamiento de Docker en .artifacts/docker-tests/
• Artefactos de aceptación de paquetes package-under-test y de aceptación de Docker
• Artefactos de comprobación del lanzamiento entre sistemas operativos para cada sistema operativo y suite
• Artefactos de paridad de QA, paridad del entorno de ejecución y los seleccionados de Matrix, Telegram, Discord, WhatsApp o Slack

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