Automação e CI com a CLI

Visão geral

Provisione uma instalação Linux verificada e execute o trabalho de projeto como um usuário comum de jobs em espaços de trabalho novos. Mantenha os privilégios de instalação separados do processamento de código-fonte. Esta página usa o contrato de instalação da CLI 0.1.9; selecione uma versão efetivamente disponível em Downloads.

Critérios de preparação

1. Fixe a versão exata, o nome do arquivo e o catálogo assinado que seu fluxo aceita.

2. Siga Verificar downloads para autenticar a âncora DER da chave pública, o manifesto de checksums assinado, a assinatura do arquivo e a assinatura do catálogo antes de executar qualquer binário baixado.

3. Use Instalar no Linux. O bootstrap integrado cria o layout assinado e o componente Tcl fixo sem checkout de repositório, compilação ou acesso à rede. Instale somente durante a etapa controlada pelo administrador.

4. Execute o PREFIX/bin/alti instalado exato e guarde sua versão e o relatório de recursos. Não substitua por um binário de desenvolvimento nem por um runner PATH não verificado.

A presença do arquivo e a saída de ajuda não comprovam que a instalação está pronta. Confira alti capabilities e a resposta de recursos da operação que você pretende executar. Uma verificação que falha deve interromper essa operação em vez de habilitar uma alternativa.

Receita de CI offline

Prepare job.json e seu código-fonte acessível apenas ao proprietário usando Primeiro resultado com a CLI. Defina ALTI_BIN como a instalação exata verificada e ALTI_WORKSPACE como o espaço de trabalho preparado para este 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

Isso verifica a etapa preliminar, e não a execução de RTL. Adicione uma avaliação explícita de XLS na CPU ou outra operação local limitada de engine quando seu fluxo precisar de um resultado de execução. Não são necessárias credenciais da Cloud para essas verificações locais.

Regras de recursos e saídas

• Confira o código de saída do processo antes de interpretar o esquema esperado específico do comando.

• Mantenha stdout e stderr separados. Com --json, interprete a saída do engine a partir de stdout do envelope; para encadear plan/apply do DDS, salve o resultado nativo bruto.

• Use um novo diretório de espaço de trabalho/execução. Revise um plano completo de criação antes de aplicá-lo e gere-o novamente após um conflito em vez de substituir seus hashes.

• Use políticas explícitas cpu/cuda ou Evolve cpu-reference/cuda. XLS e RTL empacotado não recorrem silenciosamente a alternativas. PX auto é uma política separada de adesão explícita cujo backend e fallback efetivos devem ser lidos no comprovante.

• Agende a qualificação de GPU separadamente com o driver e as ferramentas Icarus necessários. Exija trabalho CUDA efetivamente aceito e proveniência de hardware armazenada; apenas a descoberta é insuficiente. Não deduza desempenho a partir de testes funcionais.

• Gravações na Cloud exigem permissão de conta/projeto e consentimento explícito de upload da operação. A substituição HTTP legada exige um hash novo desse serviço; um 409 é um conflito, e não uma permissão para tentar novamente com verificações mais fracas.

Preservar evidências

Guarde o catálogo e as assinaturas verificados, os digests dos binários instalados, a versão da CLI, os argumentos com dados sensíveis ocultados, os digests de entrada, o código de saída e os fluxos limitados de resultados/diagnósticos. Registros de GPU também precisam das identidades efetivas do dispositivo/driver e das ferramentas externas. Trate as evidências de desenvolvimento/depuração separadamente da qualificação do pacote assinado. Evite reter credenciais ou código-fonte do projeto sem necessidade.

Manter a CI repetível

1. Fixe a versão verificada do lançamento e das cadeias de ferramentas externas no provisionamento do runner.

2. Use um novo diretório de código-fonte pertencente ao usuário e novos caminhos de saída para cada job.

3. Execute verificações de recursos e uma pequena execução real adequada à operação solicitada.

4. Faça o pipeline falhar diante de saída diferente de zero, saída malformada, identidade de código-fonte desatualizada ou ausência de artefatos obrigatórios.

5. Guarde diagnósticos e digests limitados; rotacione credenciais pelo armazenamento de segredos da CI, e não por logs salvos.

Armazene em cache entradas de instalação verificadas ou cadeias de ferramentas imutáveis por versão e digest. Mantenha resultados de projetos, arquivos de sessão e credenciais de provedores fora de caches compartilhados. Trabalho remoto precisa de autorização explícita e acompanhamento de jobs próprios; passar na CI local não significa que o trabalho na Cloud foi executado.