Esta página foi traduzida pela API Cloud Translation.

Como depurar ocorrências do cache remoto para execução remota

Nesta página, descrevemos como verificar a taxa de ocorrência em cache e como investigar falhas de cache no contexto da execução remota.

Nesta página, presume-se que você tem uma versão e/ou teste que utiliza a execução remota com êxito e quer garantir que você esteja efetivamente usando o cache remoto.

Como verificar a taxa de ocorrência em cache

Na saída padrão da execução do Bazel, observe a linha INFO que lista os processos, que correspondem aproximadamente às ações do Bazel. Essa linha detalha onde a ação foi executada. Procure o rótulo remote, que indica uma ação executada remotamente, linux-sandbox para ações executadas em um sandbox local e outros valores para outras estratégias de execução. Uma ação com resultado proveniente de um cache remoto é exibida como remote cache hit.

Por exemplo:

INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.

Neste exemplo, havia seis ocorrências remotas em cache, e duas ações não tinham ocorrências em cache e eram executadas remotamente. As três partes internas podem ser ignoradas. Normalmente, são ações internas muito pequenas, como criar links simbólicos. As ocorrências em cache local não estão incluídas neste resumo. Se você não estiver recebendo nenhum processo (ou um número menor que o esperado), execute bazel clean seguido pelo comando de criação/teste.

Solução de problemas de ocorrência em cache

Se você não estiver recebendo a taxa de ocorrência em cache esperada, faça o seguinte:

Executar novamente o mesmo comando build/test gera ocorrências em cache

Execute as compilações e/ou os testes que devem preencher o cache. Na primeira vez que um novo build é executado em uma determinada pilha, não há ocorrências em cache remoto. Como parte da execução remota, os resultados da ação são armazenados no cache e uma execução subsequente precisa selecioná-los.
Execute bazel clean. Esse comando limpa o cache local, o que permite investigar ocorrências remotas de cache sem que os resultados sejam mascarados por ocorrências em cache local.
Execute as compilações e os testes que você está investigando novamente (na mesma máquina).
Verifique a linha INFO para a taxa de ocorrência em cache. Se não houver processos, exceto remote cache hit e internal, isso significa que seu cache está sendo preenchido e acessado corretamente. Nesse caso, pule para a próxima seção.
Uma provável fonte de discrepância é algo não hermético no build que faz com que as ações recebam chaves de ação diferentes nas duas execuções. Para encontrar essas ações, faça o seguinte:

a. Execute novamente as versões ou os testes em questão para receber os registros de execução:
```
  bazel clean
  bazel --optional-flags build //your:target --execution_log_binary_file=/tmp/exec1.log
```
b. Compare os registros de execução entre as duas execuções. Verifique se as ações são idênticas nos dois arquivos de registro. As discrepâncias fornecem uma dica sobre as alterações que ocorreram entre as execuções. Atualize seu build para eliminar essas discrepâncias.

Se você conseguir resolver os problemas de armazenamento em cache e agora a execução repetida produzir todas as ocorrências em cache, pule para a próxima seção.

Se os IDs de ação são idênticos, mas não há ocorrências em cache, algo na sua configuração está impedindo o armazenamento em cache. Continue nesta seção para verificar problemas comuns.

Se você não precisar diferenciar os registros de execução, use a sinalização --execution_log_json_file legível. Ela não pode ser usada para diferenciação estável, porque contém tempo de execução e não garante a ordenação.
Verifique se todas as ações no registro de execução têm cacheable definido como verdadeiro. Se cacheable não aparecer no registro de execução de uma ação de dar, isso significa que a regra correspondente pode ter uma tag no-cache em sua definição no arquivo BUILD. Observe o campo legível progress_message no registro de execução para ajudar a determinar a origem da ação.
Se as ações forem idênticas e cacheable, mas não houver ocorrências em cache, é possível que sua linha de comando inclua --noremote_accept_cached, o que desativaria as pesquisas de cache de um build.

Se for difícil descobrir a linha de comando real, use a linha de comando canônica do Build Event Protocol da seguinte maneira:

a. Adicione --build_event_text_file=/tmp/bep.txt ao seu comando Bazel para receber a versão em texto do registro.

b. Abra a versão em texto do registro e procure a mensagem structured_command_line com command_line_label: "canonical". Ele lista todas as opções após a expansão.

c. Pesquise remote_accept_cached e verifique se ele está definido como false.

d. Se remote_accept_cached for false, determine onde está sendo definido como false: na linha de comando ou em um arquivo bazelrc.

Garantir o armazenamento em cache entre as máquinas

Depois que as ocorrências em cache estiverem acontecendo conforme o esperado na mesma máquina, execute as mesmas versões/testes em outra máquina. Se você suspeitar que o armazenamento em cache não está acontecendo em máquinas, faça o seguinte:

Faça uma pequena modificação na sua compilação para evitar atingir os caches existentes.

Execute a compilação na primeira máquina:

 bazel clean
 bazel ... build ... --execution_log_binary_file=/tmp/exec1.log

Execute a versão na segunda máquina, garantindo que a modificação da etapa 1 esteja incluída:
```
 bazel clean
 bazel ... build ... --execution_log_binary_file=/tmp/exec2.log
```
Compare os registros de execução das duas execuções. Se os registros não forem idênticos, investigue as configurações do build em busca de discrepâncias e de propriedades do ambiente do host que vazem para um dos builds.

Como comparar os registros de execução

Os registros de execução contêm registros de todas as ações executadas durante a versão. Para cada ação, há um elemento SpawnExec que contém todas as informações da chave de ação. Portanto, se os registros forem idênticos, as chaves de cache de ação serão também.

Para comparar os registros de duas versões que não estão compartilhando ocorrências do cache conforme esperado, faça o seguinte:

Acesse os registros de execução de cada versão e armazene-os como /tmp/exec1.log e /tmp/exec2.log.
Faça o download do código-fonte do Bazel e vá para a pasta do Bazel usando o comando abaixo. Você precisa do código-fonte para analisar os registros de execução com o analisador de execlog.
```
git clone https://github.com/bazelbuild/bazel.git
cd bazel
```
Use o analisador de registros de execução para converter os registros em texto. A invocação a seguir também classifica as ações no segundo registro para corresponder à ordem no primeiro registro para facilitar a comparação.
```
bazel build src/tools/execlog:parser
bazel-bin/src/tools/execlog/parser \
  --log_path=/tmp/exec1.log \
  --log_path=/tmp/exec2.log \
  --output_path=/tmp/exec1.log.txt \
  --output_path=/tmp/exec2.log.txt
```
Use seu texto favorito para diferir /tmp/exec1.log.txt e /tmp/exec2.log.txt.