Автоматизация 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; для конвейера plan/apply DDS сохраняйте сырой нативный результат.

  • Используйте новый каталог рабочей области/запуска. Проверяйте полный план создания перед применением и генерируйте заново после конфликта вместо замены хешей.

  • Используйте явные политики cpu/cuda или Evolve cpu-reference/cuda. XLS и упакованный RTL не переходят молча к резервному варианту. PX auto — отдельная добровольно включаемая политика, фактический бэкенд и резервный вариант которой нужно читать из квитанции.

  • Планируйте квалификацию GPU отдельно с нужным драйвером и инструментами Icarus. Требуйте фактическую принятую работу CUDA и сохранённое происхождение оборудования; одного обнаружения недостаточно. Не выводите производительность из функциональных тестов.

  • Запись Cloud требует разрешений аккаунта/проекта и явного согласия операции на загрузку. Прежняя замена HTTP требует свежего хеша того сервиса; 409 — конфликт, а не разрешение повторить с ослабленными проверками.

Сохранение доказательств

Сохраните проверенные каталог/подписи, дайджесты установленного бинарного файла, версию CLI, очищенные аргументы, дайджесты ввода, код выхода и ограниченные потоки результатов/диагностики. Записи GPU также требуют фактические идентичности устройства/драйвера и внешних инструментов. Рассматривайте доказательства разработки/отладки отдельно от квалификации подписанного пакета. Не храните учётные данные или исходники проекта без необходимости.

Повторяемость CI

  1. Фиксируйте проверенный выпуск и версии внешней цепочки инструментов при подготовке исполнителя.

  2. Используйте новый каталог исходников пользователя и новые пути вывода для каждого задания.

  3. Выполняйте проверки возможностей и небольшое реальное выполнение, подходящее запрошенной операции.

  4. Завершайте конвейер ошибкой при ненулевом выходе, неверном формате вывода, устаревшей идентичности исходника или отсутствии требуемых артефактов.

  5. Храните ограниченную диагностику и дайджесты; меняйте учётные данные через хранилище секретов CI, а не сохранённые журналы.

Кешируйте проверенные входы установки или неизменяемые цепочки инструментов по версии и дайджесту. Не помещайте результаты проектов, файлы сеансов и учётные данные провайдера в общие кеши. Удалённая работа требует собственной явной авторизации и отслеживания задания; локальный успех CI не означает выполнения работы Cloud.