Automatización y CI con la CLI

Descripción general

Prepare una instalación verificada de Linux y después ejecute el trabajo de diseño como usuario habitual de trabajos sobre espacios de trabajo nuevos. Mantenga los privilegios de instalación separados del procesamiento del código fuente. Esta página utiliza el contrato de instalación de la CLI 0.1.9; seleccione una versión realmente disponible en Descargas.

Comprobaciones previas de preparación

1. Fije la versión exacta, el nombre del archivo comprimido y el catálogo firmado que acepta su flujo de trabajo.

2. Siga Verificar descargas para autenticar la referencia DER fijada de la clave pública, el manifiesto firmado de sumas de comprobación, la firma del archivo comprimido y la firma del catálogo antes de ejecutar cualquier binario descargado.

3. Utilice Instalación en Linux. El programa de instalación inicial integrado crea la estructura firmada y el componente Tcl de ubicación fija sin extraer un repositorio, compilar ni acceder a la red. Instale únicamente durante el paso controlado por el administrador.

4. Ejecute el PREFIX/bin/alti instalado exacto y conserve su versión y el informe de capacidades. No lo sustituya por un binario de desarrollo ni un ejecutor PATH sin verificar.

La presencia del archivo comprimido y la salida de ayuda no demuestran que la instalación esté lista. Compruebe alti capabilities y la respuesta de capacidades para la operación que pretende ejecutar. Una comprobación fallida debe detener esa operación, en lugar de habilitar una alternativa.

Receta de CI sin conexión

Prepare job.json y su código fuente accesible solo por el propietario mediante Primer resultado satisfactorio con la CLI. Establezca ALTI_BIN en la instalación verificada exacta y ALTI_WORKSPACE en el espacio de trabajo preparado para este trabajo:

set -euo pipefail
ALTI_BIN="${ALTI_BIN:?set the verified absolute installed alti path}"
ALTI_WORKSPACE="${ALTI_WORKSPACE:?set the private prepared workspace}"
case "$ALTI_BIN" in /*) ;; *) exit 1 ;; esac
EVIDENCE="$(mktemp -d)"

"$ALTI_BIN" version > "$EVIDENCE/version.txt"
"$ALTI_BIN" capabilities > "$EVIDENCE/capabilities.json"
"$ALTI_BIN" commands > "$EVIDENCE/commands.json"
"$ALTI_BIN" --json job validate \
  --job "$ALTI_WORKSPACE/job.json" \
  --workspace-root "$ALTI_WORKSPACE" \
  --source rtl/top.sv \
  > "$EVIDENCE/preflight.json" 2> "$EVIDENCE/preflight-error.json"

jq -e 'length == 25' "$EVIDENCE/commands.json" >/dev/null
jq -e '
  .receipt_schema == "altifigence.cli.engine-job-preflight.v1" and
  .status == "client_preflight_valid" and
  .submitted == false and
  .server_authority_verified == false
' "$EVIDENCE/preflight.json" >/dev/null

Esto comprueba la validación preliminar, no la ejecución RTL. Añada una evaluación explícita de XLS en CPU u otra operación acotada de motor local cuando su flujo necesite un resultado de ejecución. Estas comprobaciones locales no necesitan credenciales de Cloud.

Reglas de capacidades y salida

• Compruebe el estado de salida del proceso antes de analizar el esquema específico del comando esperado.

• Mantenga stdout y stderr separados. Con --json, analice la salida del motor desde stdout del sobre; para canalizaciones plan/apply de DDS, guarde el resultado nativo sin procesar.

• Utilice un directorio nuevo de espacio de trabajo o ejecución. Revise un plan completo de creación antes de aplicarlo y vuelva a generarlo tras un conflicto en lugar de sustituir sus hashes.

• Utilice políticas explícitas de cpu/cuda o de Evolve cpu-reference/cuda. XLS y RTL empaquetado no recurren silenciosamente a alternativas. PX auto es una política separada de aceptación explícita cuyo backend y alternativa reales deben leerse en su comprobante.

• Programe por separado la cualificación de GPU con el controlador y las herramientas Icarus necesarios. Exija trabajo CUDA real aceptado y procedencia del hardware almacenada; el descubrimiento por sí solo no basta. No deduzca el rendimiento a partir de pruebas funcionales.

• Las escrituras de Cloud necesitan permiso de cuenta y proyecto y el consentimiento explícito de subida de la operación. Una sustitución mediante HTTP heredado necesita un hash nuevo de ese servicio; un 409 es un conflicto, no un permiso para reintentar con comprobaciones más débiles.

Preservar evidencia

Conserve el catálogo y las firmas verificados, los resúmenes criptográficos de los binarios instalados, la versión de la CLI, los argumentos con datos sensibles ocultos, los resúmenes de entradas, el estado de salida y los flujos acotados de resultados y diagnósticos. Los registros de GPU también necesitan la identidad real del dispositivo, del controlador y de las herramientas externas. Distinga la evidencia de desarrollo y depuración de la cualificación del paquete firmado. Evite conservar credenciales o código fuente del proyecto innecesariamente.

Mantener la CI reproducible

1. Fije la versión verificada y las versiones de las cadenas de herramientas externas al preparar el ejecutor.

2. Utilice un directorio nuevo de código fuente propiedad del usuario y rutas de salida nuevas para cada trabajo.

3. Ejecute comprobaciones de capacidades y una ejecución real pequeña adecuada para la operación solicitada.

4. Haga fallar la canalización si el proceso devuelve un estado distinto de cero, la salida está mal formada, la identidad del código fuente está desactualizada o faltan artefactos necesarios.

5. Conserve diagnósticos acotados y resúmenes criptográficos; rote las credenciales mediante el almacén de secretos de CI en lugar de registros guardados.

Almacene en caché las entradas verificadas de instalación o cadenas de herramientas inmutables por versión y resumen criptográfico. Mantenga los resultados del proyecto, los archivos de sesión y las credenciales del proveedor fuera de las cachés compartidas. El trabajo remoto necesita su propia autorización explícita y seguimiento de trabajos; superar la CI local no significa que se haya ejecutado trabajo en Cloud.