CLI の自動化と CI

検証済み CLI をインストールし、範囲を限定したローカル作業、受領記録、明示的なバックエンド確認を自動化します。

概要

検証済みの Linux インストールを用意し、新しいワークスペースに対して通常のジョブユーザーとして設計作業を実行します。インストール権限はソース処理から分離してください。このページは CLI 0.1.9 のインストール契約を使用します。実際に利用できるリリースは、ダウンロードから選択してください。

準備段階の確認

  1. ワークフローが受け入れる正確なバージョン、アーカイブ名、署名済みカタログを固定します。

  2. まず、ダウンロードの検証に従い、ダウンロードしたバイナリを実行する前に、公開鍵の DER ピン、署名済みチェックサムマニフェスト、アーカイブ署名、カタログ署名を認証します。

  3. インストール手順は、Linux へのインストールを参照してください。内蔵ブートストラップは、リポジトリのチェックアウト、ビルド、ネットワークアクセスを行わずに、署名済みの配置と固定 Tcl コンポーネントを作成します。インストールは管理者が制御する手順でのみ行ってください。

  4. インストール済みの正確な PREFIX/bin/alti を実行し、そのバージョンと機能レポートを保持します。開発用バイナリや、未検証の PATH ランナーで代用しないでください。

アーカイブの存在やヘルプの出力は、インストール済み環境の準備完了を証明しません。alti capabilities と、実行する操作に対する機能応答を確認します。確認に失敗した場合は、その操作を停止し、フォールバックを有効にしないでください。

オフライン CI の手順

事前確認のため、job.json と、所有者だけがアクセスできるそのソースを、CLI の初回実行に従って準備します。ALTI_BIN を正確な検証済みインストール先に、ALTI_WORKSPACE をこのジョブ用に準備したワークスペースに設定してください。

Bash
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

これは事前確認を行うものであり、RTL の実行ではありません。実行結果が必要なワークフローでは、明示的な CPU XLS 評価や、範囲を限定した別のローカルエンジン操作を追加してください。これらのローカル確認に Cloud の資格情報は不要です。

機能と出力の規則

  • 期待するコマンド固有のスキーマを解析する前に、プロセスの終了ステータスを確認します。

  • stdout と stderr を分けて保存します。--json の場合、エンジン出力はエンベロープの stdout から解析します。DDS の plan/apply のパイプ処理では、生のネイティブ結果を保存してください。

  • 新しいワークスペース・実行ディレクトリを使用します。作成・編集計画全体を確認してから適用し、競合後はハッシュを書き換えるのではなく、再生成してください。

  • 明示的な cpu/cuda、または Evolve の cpu-reference/cuda ポリシーを使用します。XLS と packed RTL は、通知なくフォールバックしません。PX の auto は別の明示的な選択を必要とするポリシーです。実際のバックエンドとフォールバックは、その受領記録から読み取る必要があります。

  • GPU の適合確認は、必要なドライバーと Icarus ツールを用いて別途計画します。実際に受け入れられた CUDA 作業と、保存されたハードウェアの来歴を必須としてください。検出だけでは十分ではありません。機能テストから性能を推測しないでください。

  • Cloud の書き込みには、アカウント・プロジェクト権限と、その操作の明示的なアップロード同意が必要です。従来の HTTP による置換には、そのサービスから取得した新しいハッシュが必要です。409 は競合であり、確認を弱めて再試行してよいという許可ではありません。

証拠を保持する

検証済みのカタログ・署名、インストール済みバイナリのダイジェスト、CLI バージョン、機密情報を削除した引数、入力ダイジェスト、終了ステータス、範囲を限定した結果・診断ストリームを保持します。GPU 記録には、実際のデバイス・ドライバーと外部ツールの識別情報も必要です。開発・デバッグの証拠は署名済みパッケージの適合確認とは分けて扱ってください。資格情報やプロジェクトソースを不必要に保持しないでください。

CI の再現性を保つ

  1. ランナーの準備で、検証済みリリースと外部ツールチェーンのバージョンを固定します。

  2. ジョブごとに、ユーザーが所有する新しいソースディレクトリと新しい出力パスを使用します。

  3. 機能確認と、要求された操作に適した小規模な実際の実行を行います。

  4. 終了ステータスが 0 以外、不正な出力、古いソース識別情報、必要な成果物の不足があれば、パイプラインを失敗させます。

  5. 範囲を限定した診断とダイジェストを保持します。資格情報の更新は、保存済みログではなく CI のシークレットストアを通じて行います。

検証済みのインストール入力や変更不能なツールチェーンは、バージョンとダイジェストごとにキャッシュします。プロジェクト結果、セッションファイル、プロバイダーの資格情報は共有キャッシュに入れないでください。リモート作業には、それ専用の明示的な認可とジョブ追跡が必要です。ローカル CI の合格は、Cloud で作業が実行されたことを意味しません。