Automatisation CLI et CI

Présentation

Préparez une installation Linux vérifiée, puis exécutez les opérations de conception en tant qu’utilisateur de tâche ordinaire dans de nouveaux espaces de travail. Séparez les privilèges d’installation du traitement des sources. Cette page utilise le contrat d’installation CLI 0.1.9 ; sélectionnez une version réellement disponible via Téléchargements.

Contrôle préalable à la préparation

1. Fixez la version exacte, le nom de l’archive et le catalogue signé acceptés par votre flux de travail.

2. Suivez Vérifier les téléchargements pour authentifier l’empreinte DER de la clé publique, le manifeste signé de sommes de contrôle, la signature de l’archive et celle du catalogue avant d’exécuter tout binaire téléchargé.

3. Utilisez Installer sous Linux. L’amorçage intégré crée l’organisation signée et le composant Tcl fixe sans copie de dépôt, compilation ou accès réseau. Installez uniquement pendant l’étape contrôlée par l’administrateur.

4. Exécutez le PREFIX/bin/alti installé exact et conservez sa version et son rapport de capacités. Ne le remplacez pas par un binaire de développement ou un runner PATH non vérifié.

La présence de l’archive et la sortie d’aide ne prouvent pas que l’installation est prête. Vérifiez alti capabilities et la réponse de capacités pour l’opération que vous souhaitez exécuter. Un contrôle en échec doit arrêter cette opération plutôt qu’activer un repli.

Procédure CI hors ligne

Préparez job.json et sa source accessible uniquement au propriétaire avec Premier résultat réussi avec la CLI. Définissez ALTI_BIN sur l’installation exacte vérifiée et ALTI_WORKSPACE sur l’espace de travail préparé de cette tâche :

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

Cela vérifie le contrôle préalable, pas l’exécution RTL. Ajoutez une évaluation CPU XLS explicite ou une autre opération de moteur local bornée lorsque votre flux de travail nécessite un résultat d’exécution. Aucun identifiant Cloud n’est nécessaire pour ces vérifications locales.

Règles de capacités et de sortie

• Vérifiez le statut de sortie du processus avant d’analyser le schéma attendu propre à la commande.

• Conservez stdout et stderr séparément. Avec --json, analysez la sortie du moteur depuis le stdout de l’enveloppe ; pour les pipelines DDS plan/apply, enregistrez le résultat natif brut.

• Utilisez un nouveau répertoire d’espace de travail/d’exécution. Examinez un plan de création complet avant de l’appliquer et régénérez-le après un conflit au lieu de remplacer ses empreintes.

• Utilisez des politiques explicites cpu/cuda ou Evolve cpu-reference/cuda. XLS et le RTL empaqueté ne se replient pas silencieusement. PX auto est une politique facultative distincte dont le backend et le repli réels doivent être lus dans son reçu.

• Planifiez séparément la qualification GPU avec le pilote requis et les outils Icarus. Exigez une véritable opération CUDA acceptée et une provenance matérielle stockée ; la découverte seule est insuffisante. Ne déduisez pas les performances des tests fonctionnels.

• Les écritures Cloud nécessitent une autorisation de compte/projet et le consentement explicite de téléversement de l’opération. Le remplacement HTTP hérité nécessite une nouvelle empreinte de ce service ; un 409 est un conflit, pas une autorisation de réessayer avec des contrôles plus faibles.

Préserver les preuves

Conservez le catalogue/les signatures vérifiés, les empreintes des binaires installés, la version CLI, les arguments expurgés, les empreintes d’entrée, le statut de sortie et les flux bornés de résultats/diagnostics. Les enregistrements GPU nécessitent aussi l’appareil/le pilote réels et les identités des outils externes. Distinguez les preuves de développement/débogage de la qualification des packages signés. Évitez de conserver inutilement des identifiants ou des sources de projet.

Maintenir une CI reproductible

1. Fixez la version vérifiée et les versions des chaînes d’outils externes lors de la préparation des runners.

2. Utilisez un nouveau répertoire source détenu par l’utilisateur et de nouveaux chemins de sortie pour chaque tâche.

3. Exécutez des contrôles de capacités et une petite exécution réelle adaptée à l’opération demandée.

4. Faites échouer le pipeline en cas de sortie non nulle, de sortie mal formée, d’identité de source obsolète ou d’artefacts requis absents.

5. Conservez des diagnostics et des empreintes bornés ; faites tourner les identifiants via le stockage de secrets CI plutôt que dans des journaux enregistrés.

Mettez en cache les entrées d’installation vérifiées ou les chaînes d’outils immuables par version et empreinte. Excluez les résultats de projet, les fichiers de session et les identifiants de fournisseur des caches partagés. Les opérations distantes nécessitent leur propre autorisation explicite et suivi de tâches ; une réussite de CI locale ne signifie pas que des opérations Cloud ont été exécutées.