CLI-Automatisierung und CI

Überblick

Stellen Sie eine überprüfte Linux-Installation bereit und führen Sie danach Designarbeit als normaler Jobbenutzer auf neuen Arbeitsbereichen aus. Trennen Sie Installationsprivilegien von Quellverarbeitung. Diese Seite verwendet den Installationsvertrag der CLI 0.1.9; wählen Sie über Downloads ein tatsächlich verfügbares Release.

Vorbereitungsvoraussetzungen

1. Legen Sie genaue Version, Archivname und signierten Katalog fest, die Ihr Workflow akzeptiert.

2. Folgen Sie Downloads überprüfen, um DER-Vertrauensbindung des öffentlichen Schlüssels, signiertes Prüfsummenmanifest, Archivsignatur und Katalogsignatur vor Ausführung einer heruntergeladenen Binärdatei zu authentifizieren.

3. Verwenden Sie Installation unter Linux. Der eingebettete Bootstrap erstellt die signierte Anordnung und feste Tcl-Komponente ohne Repository-Checkout, Build oder Netzwerkzugriff. Installieren Sie nur während des vom Administrator kontrollierten Schritts.

4. Führen Sie die genau installierte PREFIX/bin/alti aus und bewahren Sie Version und Fähigkeitsbericht auf. Ersetzen Sie sie nicht durch eine Entwicklungsbinärdatei oder einen ungeprüften PATH-Runner.

Archivvorhandensein und Hilfeausgabe belegen keine Installationsbereitschaft. Prüfen Sie alti capabilities und die Fähigkeitsantwort für die beabsichtigte Operation. Eine fehlgeschlagene Prüfung sollte die Operation stoppen, statt einen Fallback zu aktivieren.

Offline-CI-Ablauf

Bereiten Sie job.json und dessen nur dem Besitzer zugängliche Quelle mithilfe von Erster CLI-Erfolg vor. Setzen Sie ALTI_BIN auf die genaue überprüfte Installation und ALTI_WORKSPACE auf den vorbereiteten Arbeitsbereich dieses Jobs:

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

Dies prüft die Vorprüfung, keine RTL-Ausführung. Ergänzen Sie eine ausdrückliche CPU-XLS-Auswertung oder eine andere begrenzte lokale Engine-Operation, wenn Ihr Workflow ein Ausführungsergebnis benötigt. Für diese lokalen Prüfungen sind keine Cloud-Zugangsdaten erforderlich.

Fähigkeits- und Ausgaberegeln

• Prüfen Sie den Prozess-Exitstatus, bevor Sie das erwartete befehlsspezifische Schema parsen.

• Halten Sie stdout und stderr getrennt. Bei --json parsen Sie Engine-Ausgabe aus stdout des Umschlags; speichern Sie für DDS-plan/apply-Piping das rohe native Ergebnis.

• Verwenden Sie ein neues Arbeitsbereichs-/Laufverzeichnis. Prüfen Sie einen vollständigen Erstellungsplan vor Anwendung und generieren Sie nach einem Konflikt neu, statt seine Hashes zu ersetzen.

• Verwenden Sie ausdrückliche cpu/cuda- oder Evolve-cpu-reference/cuda-Richtlinien. XLS und gepacktes RTL fallen nicht stillschweigend zurück. PX auto ist eine separate Opt-in-Richtlinie, deren tatsächliches Backend und Fallback aus dem Beleg gelesen werden müssen.

• Planen Sie GPU-Qualifikation separat mit erforderlichem Treiber und Icarus-Werkzeugen. Verlangen Sie tatsächlich akzeptierte CUDA-Arbeit und gespeicherte Hardwareherkunft; Erkennung allein reicht nicht. Leiten Sie Leistung nicht aus Funktionstests ab.

• Cloud-Schreibvorgänge benötigen Konto-/Projektberechtigung und ausdrückliche Upload-Einwilligung der Operation. Ältere HTTP-Ersetzung benötigt einen neuen Hash dieses Dienstes; ein 409 ist ein Konflikt, keine Erlaubnis für eine Wiederholung mit schwächeren Prüfungen.

Nachweise erhalten

Bewahren Sie überprüften Katalog/Signaturen, installierte Binärdigests, CLI-Version, redigierte Argumente, Eingabedigests, Exitstatus und begrenzte Ergebnis-/Diagnosestreams auf. GPU-Datensätze benötigen auch tatsächliches Gerät/Treiber und Identitäten externer Werkzeuge. Behandeln Sie Entwicklungs-/Debug-Nachweise separat von der Qualifikation signierter Pakete. Bewahren Sie Zugangsdaten oder Projektquellen nicht unnötig auf.

CI reproduzierbar halten

1. Legen Sie überprüftes Release und externe Toolchain-Versionen bei der Runnerbereitstellung fest.

2. Verwenden Sie je Job ein neues benutzereigenes Quellverzeichnis und neue Ausgabepfade.

3. Führen Sie Fähigkeitsprüfungen und eine kleine tatsächliche, für die angeforderte Operation geeignete Ausführung durch.

4. Lassen Sie die Pipeline bei Exitstatus ungleich null, fehlerhafter Ausgabe, veralteter Quellidentität oder fehlenden erforderlichen Artefakten fehlschlagen.

5. Bewahren Sie begrenzte Diagnosen und Digests auf; rotieren Sie Zugangsdaten über den CI-Geheimnisspeicher statt gespeicherte Protokolle.

Cachen Sie überprüfte Installationseingaben oder unveränderliche Toolchains nach Version und Digest. Halten Sie Projektergebnisse, Sitzungsdateien und Providerzugangsdaten aus gemeinsamen Caches heraus. Entfernte Arbeit benötigt eigene ausdrückliche Autorisierung und Jobverfolgung; bestandene lokale CI bedeutet nicht, dass Cloud-Arbeit lief.