lanzamiento-openclaw-mac

Lanzamiento de OpenClaw para Mac

Usar con $release-openclaw-maintainer, $release-openclaw-ci, $one-password y $release-private si existe cuando haya activos estables de macOS, pre-vuelo de release-ops de Mac, notarización, promoción de appcast o recuperación del lanzamiento de Mac.

Esta es una habilidad de lanzamiento estable regular. No invocarla para lanzamientos de soporte extendido; el lanzamiento de GitHub de esa rama lleva evidencia de validación compartida pero no hereda activos de macOS ni promoción de appcast.

Autorización del lanzamiento

Una solicitud explícita de lanzamiento estable o completo incluye la publicación de macOS a menos que el operador limite su alcance. Continuar con la validación, firma, notarización, promoción y verificación sin pedir consentimiento separado para macOS. Mantener la identidad exacta del lanzamiento y todas las comprobaciones de artefactos. La publicación de macOS se ejecuta en paralelo con npm y nunca lo bloquea; un fallo de macOS no detiene el lanzamiento de npm/ClawHub, la finalización del lanzamiento de GitHub ni el cierre principal. Arreglarlo en paralelo.

Seguir la política de entorno configurada por el propietario actual. No inventar un requisito adicional de revisor ni recrear uno obsoleto. Si GitHub aún aplica una aprobación, informar la regla real y resolverla a través de su propietario; los cambios de política requieren instrucciones explícitas del propietario de la organización y membresía de administrador activa verificada. Nunca suplantar a un revisor, falsificar una aprobación ni usar otra ruta de firma para eludir una regla aplicada.

Credenciales

• Resolver referencias de elementos ASC propiedad de Peter, IDs de clave, IDs de emisor y procedencia del token de servicio desde $release-private.
• Campos: private_key_p8, key_id, issuer_id.
• Síntoma de clave caducada/revocada: xcrun notarytool submit falla con HTTP status code: 401. Unauthenticated.
• Validar credenciales ASC candidatas con xcrun notarytool history antes de establecer los secretos de GitHub.

1Password

• Usar $one-password: todo el trabajo de op dentro de una sola sesión persistente de tmux, sin salida secreta.
• Usar la guía de token de servicio de $release-private cuando esté disponible.
• Si un token de servicio falla, ejecutar comprobaciones solo de estado: token presente/longitud y op whoami; nunca imprimir valores de token.
• Si se necesita autenticación de la aplicación de escritorio pero Touch ID no está disponible, establecer OP_BIOMETRIC_UNLOCK_ENABLED=false para la ruta manual de op account add --signin.

Secretos de GitHub

Entorno del repositorio de destino de release-ops: openclaw/releases, entorno mac-release.

Establecer solo después de la validación local de autenticación de notaría:

• APP_STORE_CONNECT_API_KEY_P8
• APP_STORE_CONNECT_KEY_ID
• APP_STORE_CONNECT_ISSUER_ID

No actualizar estos desde fuentes mixtas. Los tres campos ASC deben provenir del mismo elemento de 1Password.

Forma del flujo de trabajo

• openclaw/openclaw es el repositorio de producto público. Su página de Lanzamientos de GitHub es donde se adjuntan finalmente los activos de macOS.
• openclaw/openclaw macos-release.yml es solo validación de entrega pública. Nunca firma, notariza ni sube activos de macOS, independientemente de preflight_only.
• openclaw/releases es el repositorio restringido de release-ops. Sus flujos de trabajo de macOS firman, notarizan, validan y promocionan activos en el lanzamiento de GitHub de openclaw/openclaw.
• La rama de lanzamiento público puede llevar correcciones de empaquetado solo de Mac después de que la etiqueta estable/npm ya estén activos.
• Usar source_ref=release/YYYY.M.PATCH para el pre-vuelo/validación de Mac de release-ops al construir esa variación de rama.
• Mantener tag=vYYYY.M.PATCH apuntando al commit original del lanzamiento estable.
• La publicación real de Mac debe reutilizar:
  • una ejecución exitosa de pre-vuelo de Mac de release-ops para la misma etiqueta/SHA de fuente
  • una ejecución exitosa de validación de Mac de release-ops para la misma etiqueta/SHA de fuente
• El pre-vuelo de release-ops y la publicación real usan el entorno mac-release para secretos de firma y promoción y su política de implementación solo en main. El operador de lanzamiento autorizado continúa bajo las reglas actuales de ese entorno.
• Si el SHA de la fuente del pre-vuelo difiere del SHA de la etiqueta, la validación también debe usar la misma source_ref; la promoción rechaza pruebas no coincidentes.

Notarización

• OpenClaw usa scripts/notarize-mac-artifact.sh.
• xcrun notarytool submit debe usar --no-s3-acceleration; la subida acelerada puede mostrar errores 401 engañosos incluso cuando notarytool history tiene éxito.
• Si la firma tiene éxito pero la notarización falla inmediatamente con 401, comprobar primero la frescura de la clave ASC.
• Si la notarización permanece en progreso durante varios minutos después de la escritura del archivo de clave, ese es el tiempo de espera normal de Apple; no editar ciegamente.

Despacho

El flujo de trabajo de entrega pública valida la etiqueta, fuente, compilación y metadatos del paquete antes de la publicación. No requiere una página de lanzamiento de GitHub porque no sube activos. Mantener esta validación antes del flujo de trabajo de publicación real. El publicador principal es dueño de la finalización del lanzamiento de GitHub; la promoción de macOS adjunta sus activos verificados a ese lanzamiento ya sea que aún sea un borrador o ya público, por lo que nunca espera el cambio de npm.

Validación de entrega pública:

gh workflow run macos-release.yml --repo openclaw/openclaw \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH \
  -f preflight_only=true \
  -f public_release_branch=release/YYYY.M.PATCH

• Usar la rama de lanzamiento público como ref del flujo de trabajo para que la lista de Actions muestre release/YYYY.M.PATCH, coincidiendo con ejecuciones anteriores de entrega de macOS estable.
• No usar --ref main ni --ref vYYYY.M.PATCH para esta validación de entrega pública. El flujo de trabajo consulta la etiqueta desde la entrada tag internamente.

Pre-vuelo de release-ops:

gh workflow run openclaw-macos-publish.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f source_ref=release/YYYY.M.PATCH \
  -f preflight_only=true \
  -f smoke_test_only=false \
  -f allow_late_calver_recovery=false \
  -f public_release_branch=release/YYYY.M.PATCH

Seguir la ejecución a través de la firma y notarización bajo la política de entorno configurada. Registrar el id de ejecución de pre-vuelo exitoso; una pausa de aprobación no es un pre-vuelo exitoso.

Reanudar es el valor predeterminado. Re-despachar el mismo comando de pre-vuelo después de un fallo (corte de notaría, empaquetado DMG, collector) reanuda cada variante desde el punto de control más reciente dejado por un despacho fallido o cancelado de main para la misma etiqueta y SHA de fuente; solo las variantes sin un punto de control se reconstruyen. El registro de ejecución imprime Resumiendo <variante> desde ejecución <id> intento <n> o Construyendo <variante>. ignore_checkpoints=true fuerza compilaciones nuevas. Pasar resume_notarization_run_id, resume_notarization_run_attempt y resume_notarization_variant solo para fijar una ejecución específica, o para puntos de control hechos antes de que existiera el índice de reanudación (macos-resume-<tag>-<variant>-<sha> artefactos). Preferir gh run rerun <run-id> --failed --repo openclaw/releases cuando el trabajo fallido aún está en la ejecución actual.

Validación de release-ops para un pre-vuelo de variación de rama:

gh workflow run openclaw-macos-validate.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f source_ref=release/YYYY.M.PATCH

Registrar el id de ejecución de validación exitosa.

Publicación real:

gh workflow run openclaw-macos-publish.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f preflight_only=false \
  -f smoke_test_only=false \
  -f preflight_run_id=<id-ejecucion-pre-vuelo-exitoso> \
  -f validate_run_id=<id-ejecucion-validacion-exitosa> \
  -f allow_late_calver_recovery=false \
  -f public_release_branch=release/YYYY.M.PATCH

Seguir la promoción a través de la subida de activos y la publicación de appcast bajo la misma autorización de lanzamiento y política de entorno actual.

• Los flujos de trabajo de publicación/validación de release-ops openclaw/releases se ejecutan desde su propia ref de flujo de trabajo main de confianza. La publicación real tiene una protección que rechaza cualquier otra ref de flujo de trabajo. Esa ref main mostrada es esperada; la fuente pública de OpenClaw se selecciona por tag y source_ref opcional.

Verificar

• gh release view vYYYY.M.PATCH --repo openclaw/openclaw muestra zip, dmg, zip dSYM; una vez que el publicador de npm lo ha cambiado: no borrador, no pre-lanzamiento.
• El appcast.xml público de main apunta a OpenClaw-YYYY.M.PATCH.zip.
• La entrada de appcast tiene sparkle:version, sparkle:shortVersionString, tamaño y sparkle:edSignature.