Folha de referência de sinalização do Bazel

Informar um problema Ver código-fonte

Nightly · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

Navegar pela extensa lista de flags de linha de comando do Bazel pode ser um desafio. Esta página se concentra nas flags mais importantes que você precisa conhecer.

Dica: selecione o nome da flag na tabela para navegar até a entrada dela na referência da linha de comando.

Opções gerais úteis

As flags a seguir precisam ser definidas explicitamente na linha de comando.

Sinalização	Descrição
--config	É possível organizar flags em um arquivo .bazelrc em configurações, como as de depuração ou versões de lançamento. Outros grupos de configuração podem ser selecionados com --config=<group>.
--keep_going	O Bazel precisa tentar ao máximo continuar com a execução de build e teste. Por padrão, o Bazel falha rapidamente.
--remote_download_outputs	Ao usar a execução ou o armazenamento em cache remoto (disco e remoto), é possível sinalizar ao Bazel que você quer baixar todos os artefatos de build (intermediários) da seguinte maneira: --remote_download_outputs=all Por padrão, o Bazel só baixa artefatos de nível superior, como o binário final, e artefatos intermediários necessários para ações locais.
--stamp	Adiciona informações de build (usuário, carimbo de data/hora) aos binários. Observação: como isso aumenta o tempo de build, ele só é destinado a builds de lançamento.

Descobrir problemas de build e teste

As flags a seguir podem ajudar você a entender melhor os erros de build ou teste do Bazel.

Sinalização	Descrição
--announce_rc	Mostra quais flags são definidas implicitamente por arquivos .bazelrc definidos pelo usuário, pela máquina ou pelo projeto.
--auto_output_filter	Por padrão, o Bazel tenta evitar spam de registro e só imprime avisos do compilador e saída de depuração do Starlark para pacotes e subpacotes solicitados na linha de comando. Para desativar toda a filtragem, defina --auto_output_filter=none.
--sandbox_debug	Permite analisar erros de sandbox. Para mais detalhes sobre por que o Bazel faz builds de sandbox por padrão e o que é colocado em sandbox, consulte nossa documentação de sandbox. Dica: se você acha que o erro pode ser causado pelo sandbox, tente desativá-lo temporariamente. Para fazer isso, adicione --spawn_strategy=standalone ao comando.
--subcommands (-s)	Mostra uma lista abrangente de todos os comandos que o Bazel executa durante um build, independentemente de ele ser bem-sucedido ou falhar.

Inicialização

Atenção: as flags de inicialização precisam ser transmitidas antes do comando e causar uma reinicialização do servidor. Alterne essas flags com cuidado.

Sinalização	Descrição
--bazelrc	É possível especificar as opções padrão do Bazel em .bazelrc arquivos. Se houver vários arquivos .bazelrc, selecione qual arquivo .bazelrc será usado adicionando --bazelrc=<path to the .bazelrc file>. Dica: --bazelrc=dev/null desativa a pesquisa de arquivos .bazelrc. Isso é ideal para cenários em que você quer garantir um ambiente de build limpo, como builds de lançamento, e evitar mudanças de configuração não intencionais de arquivos .bazelrc.
--host_jvm_args	Limita a quantidade de RAM usada pelo servidor do Bazel. Por exemplo, o seguinte limita o tamanho da heap do Bazel a 3GB: --host_jvm_args=-Xmx3g Observação: -Xmx é usado para definir o tamanho máximo da heap da máquina virtual Java (JVM). A heap é a área de memória em que os objetos são alocados. O formato correto para essa opção é -Xmx<size> , em que <size> é o tamanho máximo da heap, especificado com uma unidade como: m para megabytes g para gigabytes k para kilobytes
--output_base	Controla a árvore de saída do Bazel. O Bazel não armazena saídas de build, incluindo registros, na própria árvore de origem. Em vez disso, ele usa uma árvore de saída distinta para essa finalidade. Dica: usar várias bases de saída em um espaço de trabalho do Bazel permite executar vários servidores do Bazel simultaneamente. Isso pode ser útil ao tentar evitar a instabilidade da análise. Para mais informações, consulte Escolher a base de saída.

Testes do Bazel

As flags a seguir estão relacionadas ao teste do Bazel

Sinalização	Descrição
--java_debug	Faz com que os testes Java aguardem uma conexão do depurador antes de serem executados.
--runs_per_test	O número de vezes para executar testes. Por exemplo, para executar testes N vezes, adicione --runs_per_test=N. Isso pode ser útil para depurar testes instáveis e verificar se uma correção faz com que um teste seja aprovado de forma consistente.
--test_output	Especifica o modo de saída. Por padrão, o Bazel captura a saída de teste em arquivos de registro locais. Ao iterar em um teste com falha, geralmente é necessário usar --test_output=streamed para conferir a saída do teste em tempo real.

Execução do Bazel

As flags a seguir estão relacionadas à execução do Bazel.

Sinalização	Descrição
--run_under	Muda a forma como os executáveis são invocados. Por exemplo, --run_under="strace -c" é usado com frequência para depuração.

Opções de bazelrc específicas do usuário

As flags a seguir estão relacionadas a opções .bazelrc específicas do usuário.

Sinalização	Descrição
--disk_cache	Um caminho para um diretório em que o Bazel pode ler e gravar ações e saídas de ações. Se o diretório não existir, ele será criado. É possível compartilhar artefatos de build entre várias ramificações ou espaços de trabalho e acelerar os builds do Bazel adicionando --disk_cache=<path> ao comando.
--jobs	O número de jobs simultâneos a serem executados. Isso geralmente só é necessário ao usar a execução remota em que um cluster de build remoto executa mais jobs do que você tem núcleos localmente.
--local_resources	Limita a quantidade de CPU ou RAM consumida por ações executadas localmente. Observação: isso não afeta a quantidade de CPU ou RAM que o próprio servidor do Bazel consome para tarefas como análise e orquestração de build.
--sandbox_base	Permite que o sandbox crie os diretórios de sandbox abaixo desse caminho. Por padrão, o Bazel executa ações locais em sandbox, o que adiciona alguma sobrecarga ao build. Dica: especifique um caminho no tmpfs, por exemplo, /run/shm, para melhorar muito o desempenho quando o build ou os testes tiverem muitos arquivos de entrada.

Opções de bazelrc específicas do projeto

As flags a seguir estão relacionadas a opções .bazelrc específicas do projeto.

Sinalização	Descrição
--flaky_test_attempts	Repita cada teste até o número especificado de vezes em caso de qualquer falha. Isso é especialmente útil na integração contínua. Os testes que exigem mais de uma tentativa para serem aprovados são marcados como FLAKY em o resumo do teste.
--remote_cache	Um URI de um endpoint de armazenamento em cache. Configurar o armazenamento em cache remoto pode ser uma ótima maneira de acelerar os builds do Bazel. Ele pode ser combinado com um cache de disco local.
--remote_download_regex	Força o download de saídas de build remoto cujo caminho corresponde a esse padrão, independentemente da configuração --remote_download_outputs. Vários padrões podem ser especificados repetindo essa flag.
--remote_executor	HOST ou HOST:PORT de um endpoint de execução remota. Transmita isso se estiver usando um serviço de execução remota. Muitas vezes, é necessário adicionar --remote_instance_name=<name>.
--remote_instance_name	O valor a ser transmitido como instance_name na API de execução remota.
--show-timestamps	Se especificado, um carimbo de data/hora será adicionado a cada mensagem gerada pelo Bazel, especificando o horário em que a mensagem foi exibida. Isso é útil em sistemas de CI para entender rapidamente qual etapa levou quanto tempo.
--spawn_strategy	Mesmo com a execução remota, a execução de algumas ações de build localmente pode ser mais rápida. Isso depende de fatores como a capacidade do cluster de build, a velocidade da rede e atrasos de rede. Dica: para executar ações local e remotamente e aceitar o resultado mais rápido, adicione --spawn_strategy=dynamic ao comando de build.