Automazione CLI e CI

Panoramica

Prepara un'installazione Linux verificata, poi esegui il lavoro di progettazione come utente ordinario dei job su workspace nuovi. Mantieni i privilegi di installazione separati dall'elaborazione dei sorgenti. Questa pagina usa il contratto di installazione CLI 0.1.9; seleziona una release effettivamente disponibile tramite Download.

Verifica dei prerequisiti

1. Fissa versione esatta, nome dell'archivio e catalogo firmato accettati dal tuo flusso di lavoro.

2. Segui Verifica dei download per autenticare vincolo DER della chiave pubblica, manifesto firmato dei checksum, firma dell'archivio e firma del catalogo prima di eseguire qualsiasi binario scaricato.

3. Usa Installazione su Linux. Il bootstrap incorporato crea il layout firmato e il componente Tcl fisso senza checkout del repository, build o accesso alla rete. Installa solo nel passo controllato dall'amministratore.

4. Esegui l'esatto PREFIX/bin/alti installato e conserva versione e rapporto delle funzionalità. Non sostituirlo con un binario di sviluppo o un runner PATH non verificato.

Presenza dell'archivio e output della guida non provano che l'installazione sia pronta. Controlla alti capabilities e la risposta delle funzionalità per l'operazione prevista. Un controllo fallito deve fermare quell'operazione invece di abilitare un ripiego.

Procedura CI offline

Prepara job.json e il suo sorgente accessibile solo al proprietario usando Primo risultato con la CLI. Imposta ALTI_BIN sull'esatta installazione verificata e ALTI_WORKSPACE sul workspace preparato di questo job:

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

Questo controlla la verifica preliminare, non l'esecuzione RTL. Aggiungi una valutazione XLS esplicita su CPU o un'altra operazione locale limitata di un motore quando il flusso richiede un risultato di esecuzione. Per questi controlli locali non servono credenziali Cloud.

Regole per funzionalità e output

• Controlla lo stato di uscita del processo prima di analizzare lo schema specifico del comando previsto.

• Mantieni stdout e stderr separati. Con --json, analizza l'output del motore dal campo stdout dell'involucro; per la pipeline plan/apply DDS, salva il risultato nativo grezzo.

• Usa una nuova directory di workspace/esecuzione. Esamina un piano di creazione completo prima di applicarlo e rigeneralo dopo un conflitto invece di sostituirne gli hash.

• Usa politiche esplicite cpu/cuda oppure Evolve cpu-reference/cuda. XLS e RTL confezionato non ricorrono silenziosamente a un ripiego. PX auto è una politica separata facoltativa il cui backend effettivo e fallback devono essere letti dalla ricevuta.

• Pianifica separatamente la qualificazione GPU con driver richiesto e strumenti Icarus. Richiedi lavoro CUDA effettivo accettato e provenienza hardware archiviata; il solo rilevamento non basta. Non dedurre prestazioni da test funzionali.

• Le scritture Cloud richiedono autorizzazioni di account/progetto e consenso esplicito al caricamento per l'operazione. La sostituzione HTTP legacy richiede un nuovo hash di quel servizio; un 409 è un conflitto, non un'autorizzazione a ritentare con controlli più deboli.

Preserva le prove

Conserva catalogo/firme verificati, digest dei binari installati, versione CLI, argomenti con dati sensibili oscurati, digest degli input, stato di uscita e flussi limitati di risultati/diagnostica. I record GPU richiedono anche identità effettive di dispositivo/driver e strumenti esterni. Tratta le prove di sviluppo/debug separatamente dalla qualificazione del pacchetto firmato. Evita di conservare inutilmente credenziali o sorgenti del progetto.

Mantieni la CI ripetibile

1. Fissa release verificata e versioni della toolchain esterna nella preparazione del runner.

2. Usa una nuova directory sorgente dell'utente e nuovi percorsi di output per ogni job.

3. Esegui controlli delle funzionalità e una piccola esecuzione effettiva adatta all'operazione richiesta.

4. Fai fallire la pipeline in caso di uscita non zero, output malformato, identità sorgente obsoleta o artefatti richiesti mancanti.

5. Conserva diagnostica limitata e digest; ruota le credenziali tramite l'archivio segreti della CI invece di log salvati.

Memorizza nella cache input di installazione verificati o toolchain immutabili per versione e digest. Escludi risultati di progetto, file di sessione e credenziali dei provider dalle cache condivise. Il lavoro remoto richiede autorizzazione esplicita e tracciamento dei job propri; un controllo CI locale superato non significa che sia stato eseguito lavoro Cloud.